On Sat, Apr 06, 2019 at 07:07:14AM -1000, Linus Torvalds wrote: > On Tue, Mar 26, 2019 at 12:20 PM Kirill Smelkov <kirr@xxxxxxxxxx> 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. Kirill
