From: Kirill Smelkov <firstname.lastname@example.org>
To: Linus Torvalds <email@example.com>
Cc: Al Viro <firstname.lastname@example.org>,
Linux List Kernel Mailing <email@example.com>,
Michael Kerrisk <firstname.lastname@example.org>,
Yongzhi Pan <email@example.com>,
Jonathan Corbet <firstname.lastname@example.org>,
David Vrabel <email@example.com>,
Juergen Gross <firstname.lastname@example.org>,
Miklos Szeredi <email@example.com>, Tejun Heo <firstname.lastname@example.org>,
Kirill Tkhai <email@example.com>,
Arnd Bergmann <firstname.lastname@example.org>, Christoph Hellwig <email@example.com>,
Greg Kroah-Hartman <firstname.lastname@example.org>,
Julia Lawall <Julia.Lawall@lip6.fr>,
Nikolaus Rath <Nikolaus@rath.org>,
Han-Wen Nienhuys <email@example.com>
Subject: Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock
Date: Sun, 07 Apr 2019 20:04:32 +0000 [thread overview]
Message-ID: <20190407200423.GA2829@deco.navytux.spb.ru> (raw)
On Sat, Apr 06, 2019 at 07:07:14AM -1000, Linus Torvalds wrote:
> On Tue, Mar 26, 2019 at 12:20 PM Kirill Smelkov <firstname.lastname@example.org> wrote:
> > Commit 9c225f2655 (vfs: atomic f_pos accesses as per POSIX) added locking for
> > file.f_pos access and in particular made concurrent read and write not possible
> > [...]
> Ok, I have applied this patch - but this patch only - as a
> well-researched preparatory patch.
> The actual conversion patch looks fine to me too, and I see a few
> acks, but I think I'd like to see it during a merge window just
> because it's large and does significant changes, while this one is
> purely preparatory.
> Al, comments?
Linus, thanks a lot for feedback and for accepting the patch.
I agree that it is better to merge the bulk-conversion at the time of
next merge window. I hope Al will pick that patch up and send to you
when the next merge window time comes.
Could we please clarify one thing: is the general complete plan to deal
with this regression, as outlined in the merged patch, ok? I mean do we
agree to further proceed with fs/fuse/ FOPEN_STREAM (patch 3/3) and
backport it + stream_open to v3.14+ stable kernels? Unfortunately it
requires a bit of cooperation from userspace, but this scheme to fix the
regression is the best I could come up with.
If FUSE bits are ok, how should we go? Are we ok to merge that patch
now, or should we wait for the next merge window? I understand that
generally it should be merge window from one side, but since we are
trying to fix regression here and if the plan for regression fix is
accepted it should be merge now. If we merge now, what should be the way
for that patch to get merged?
Fixing regression on FUSE side is my reason to do this whole work -
that's why I care about it the most and ask.
> One small note: please don't use lkml.org references since they tend
> to be slow and flaky - use lore.kernel.org instead. Also, fix your git
> config to use 12-character git hashes (best done by just removing the
> explicit hash size entirely, and letting modern git shorten hashes
> appropriately automatically).
Thanks for pointing to lore.kernel.org - I'm not very keen to kernel
development and did not knew it exists. I was seeing lkml.org being
referenced here and there and that's why I used it. I will use
lore.kernel.org from now.
Short hashes were not due to git config, but due to me trimming them to
10 characters in vim manually. I will use longer hashes as you ask.
next prev parent reply other threads:[~2019-04-07 20:19 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] ` <email@example.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 [this message]
2019-04-08 0:09 ` Linus Torvalds
2019-04-14 7:11 ` Kirill Smelkov
[not found] ` <firstname.lastname@example.org>
[not found] ` <20190409203807.GA13855@deco.navytux.spb.ru>
[not found] ` <email@example.com>
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
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).