On Wed, Apr 24, 2019 at 10:26:55AM -0700, Linus Torvalds wrote: > On Wed, Apr 24, 2019 at 10:19 AM Sasha Levin <sashal@xxxxxxxxxx> wrote: > > > > Hm, I might be confusing something here but I see a bunch of patches > > that convert existing callers mentioned in this patch to use > > stream_open() which was introduced here. > > The only use of stream_open() upstream right now is the xenbus > conversion, and that isn't actually a bugfix, because xenbus used to > manually do that > > filp->f_mode &= ~FMODE_ATOMIC_POS; /* cdev-style semantics */ > > that stream_open() does. > > So no, there isn't "a bunch of patches" anywhere. > > There are *future* cleanups for 5.2 that will happen, and that might > have hit linux-next. And there is at least one FUSE patch (again - > pending, not upstream) that may get marked for stable. > > But I see nothing right now that makes it stable material yet. Linus, thanks for explaining. Sasha, Greg, there is a FUSE patch that should be stable material that will need this stream_open() thing. That patch has just entered fuse.git#for-next today: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?id=bbd84f33652f and will hopefully enter 5.2 when merge window opens. I agree we should not blindly backport bulk stream_open conversions as performed by stream_open.cocci, at least unless there is a bug report indicating that it is actually required for a particular driver. On the other hand both Xen and FUSE deadlocks were hit for real which justifies stable propagation for their fixes. You can read about the deadlock regression and the plan to fix it in original "fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock" patch (the 59/66 patch that was send in this thread), or here: https://git.kernel.org/linus/10dce8af3422 Hope it clarifies things a bit, Kirill
