On Thu, May 30, 2024 at 10:05 PM Sasha Levin <sashal@xxxxxxxxxx> wrote: > > This is a note to let you know that I've just added the patch titled > > splice: remove permission hook from iter_file_splice_write() > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > The filename of the patch is: > splice-remove-permission-hook-from-iter_file_splice_.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable@xxxxxxxxxxxxxxx> know about it. > > > > commit 9519e9d1e625d4f01b3c8a1c32042e3f5da53b0b > Author: Amir Goldstein <amir73il@xxxxxxxxx> > Date: Thu Nov 23 18:51:44 2023 +0100 > > splice: remove permission hook from iter_file_splice_write() > > [ Upstream commit d53471ba6f7ae97a4e223539029528108b705af1 ] > > All the callers of ->splice_write(), (e.g. do_splice_direct() and > do_splice()) already check rw_verify_area() for the entire range > and perform all the other checks that are in vfs_write_iter(). > Alas, that is incorrect for 6.6.y, because it depends on prior commit ca7ab482401c ("ovl: add permission hooks outside of do_splice_direct()") And in any case, this commit is part of a pretty hairy shuffle in splice code. I'd feel much more comfortable with backporting the entire series 0db1d53937fa..6ae654392bb51 than just 3 individual commits in the middle of the series. I looked into it and ca7ab482401c does not apply cleanly to 6.6.y - it depends on the ovl changes 14ab6d425e8067..5b02bfc1e7e3. Not only for conflict, but also for correct locking order. That amounts to quite a few non trivial ovl and splice patches, so maybe you need to reconsider, but on the up side, all those ovl and splice patches are actually very subtle bug fixes, so I cannot say that they are not stable tree worthy. There is also a coda commit that depends on this for conflict: 581a4d003001 coda: convert to new timestamp accessors I did not check if it all compiles or works, only that it applies cleanly. > Instead of creating another tiny helper for special caller, just > open-code it. > > This is needed for fanotify "pre content" events. > > Suggested-by: Jan Kara <jack@xxxxxxx> > Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > Link: https://lore.kernel.org/r/20231122122715.2561213-6-amir73il@xxxxxxxxx > Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx> > Stable-dep-of: 7c98f7cb8fda ("remove call_{read,write}_iter() functions") Why would you want to backport this commit? It hinders backporting work - it does not assist it. Any new code that open codes call_{read,write}_iter() is not affected by the existence of the helpers in stable kernels and any old code that does use these helpers works as well. Thanks, Amir.
