From: Kirill Smelkov <kirr@nexedi.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Al Viro <viro@zeniv.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
Christoph Hellwig <hch@lst.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock
Date: Sat, 13 Apr 2019 16:54:40 +0000 [thread overview]
Message-ID: <20190413165116.GB10314@deco.navytux.spb.ru> (raw)
In-Reply-To: <20190412124144.GA22786@deco.navytux.spb.ru>
On Fri, Apr 12, 2019 at 03:41:44PM +0300, Kirill Smelkov wrote:
> On Thu, Apr 11, 2019 at 09:22:56AM -0700, Linus Torvalds wrote:
> > On Thu, Apr 11, 2019 at 5:38 AM Kirill Smelkov <kirr@nexedi.com> wrote:
> > >
> > > However file->f_pos writing is still there and it will bug under race
> > > detector, e.g. under KTSAN because read and write can be running
> > > simultaneously. Maybe it is not only race bug, but also a bit of
> > > slowdown as read and write code paths write to the same memory thus
> > > needing inter-cpu synchronization if read and write handlers are on
> > > different cpus. However for this I'm not sure.
> >
> > I doubt it's noticeable, but it would probably be good to simply not
> > do the write for streams.
> >
> > That *could* be done somewhat similarly, with just changing th address
> > to be updated, or course.
> >
> > In fact, we *used* to (long ago) pass in the address of "file->f_pos"
> > itself to the low-level read/write routines. We then changed it to do
> > that indirection through a local copy of pos (and
> > file_pos_read/file_pos_write) because we didn't do the proper locking,
> > so different read/write versions could mess with each other (and with
> > lseek).
> >
> > But one of the things that commit 9c225f2655e36 ("vfs: atomic f_pos
> > accesses as per POSIX") did was to add the proper locking at least for
> > the cases that we care about deeply, so we *could* say that we have
> > three cases:
> >
> > - FMODE_ATOMIC_POS: properly locked,
> > - FMODE_STREAM: no pos at all
> > - otherwise a "mostly don't care - don't mix!"
> >
> > and so we could go back to not copying the pos at all, and instead do
> > something like
> >
> > loff_t *ppos = f.file->f_mode & FMODE_STREAM ? NULL : &file->f_pos;
> > ret = vfs_write(f.file, buf, count, ppos);
> >
> > and perhaps have a long-term plan to try to get rid of the "don't mix"
> > case entirely (ie "if you use f_pos, then we'll do the proper
> > locking")
> >
> > (The above is obviously surrounded by the fdget_pos()/fdput_pos() that
> > implements the locking decision).
>
> Ok Linus, thanks for feedback. Please consider applying or queueing the
> following patches.
Resending those patches one by one in separate emails, if maybe 2
patches inline was problematic to handle...
next prev parent reply other threads:[~2019-04-13 17:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 22:20 [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock Kirill Smelkov
2019-03-26 23:22 ` [PATCH 3/3] fuse: Add FOPEN_STREAM and use stream_open() if filesystem returned that from open handler Kirill Smelkov
2019-04-24 7:13 ` [RESEND, PATCH " Kirill Smelkov
[not found] ` <20190424160611.2A71321900@mail.kernel.org>
2019-04-24 19:16 ` Kirill Smelkov
[not found] ` <8794193f3040b798010970228d978c05ad56ec52.1553637462.git.kirr@nexedi.com>
2019-03-27 6:54 ` [PATCH 2/3] *: convert stream-like files from nonseekable_open -> stream_open Lubomir Rintel
2019-03-27 16:58 ` [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock Juergen Gross
2019-04-06 17:07 ` Linus Torvalds
2019-04-07 20:04 ` Kirill Smelkov
2019-04-08 0:09 ` Linus Torvalds
2019-04-14 7:11 ` Kirill Smelkov
[not found] ` <4c4651e2-167e-bfcc-7b3e-cda118f98a69@rasmusvillemoes.dk>
[not found] ` <20190409203807.GA13855@deco.navytux.spb.ru>
[not found] ` <d8c23d05-8810-13a2-cc50-7a47ff35e90b@rasmusvillemoes.dk>
2019-04-11 12:38 ` Kirill Smelkov
2019-04-11 16:22 ` Linus Torvalds
2019-04-12 12:42 ` Kirill Smelkov
2019-04-13 16:54 ` Kirill Smelkov [this message]
2019-04-13 16:54 ` [PATCH 1/2] vfs: pass ppos=NULL to .read()/.write() of FMODE_STREAM files Kirill Smelkov
2019-04-13 17:27 ` Linus Torvalds
2019-04-13 17:38 ` Al Viro
2019-04-13 18:44 ` Kirill Smelkov
2019-04-13 16:55 ` [PATCH 2/2] vfs: use &file->f_pos directly on files that have position Kirill Smelkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190413165116.GB10314@deco.navytux.spb.ru \
--to=kirr@nexedi.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).