On Wed, Jul 24, 2024 at 2:24 AM Gabriel Krisman Bertazi <gabriel@xxxxxxxxxx> wrote: > > cel@xxxxxxxxxx writes: > > > From: Chuck Lever <chuck.lever@xxxxxxxxxx> > > > > Gabriel says: > >> 9709bd548f11 just enabled a new feature - > >> which seems against stable rules. Considering that "anything is > >> a CVE", we really need to be cautious about this kind of stuff in > >> stable kernels. > >> > >> Is it possible to drop 9709bd548f11 from stable instead? > > > > The revert wasn't clean, but adjusting it to fit was straightforward. > > This passes NFSD CI, and adds no new failures to the fanotify ltp > > tests. > > > > Reported-by: Gabriel Krisman Bertazi <gabriel@xxxxxxxxxx> > > Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > > --- > > fs/notify/fanotify/fanotify_user.c | 4 ---- > > include/linux/fanotify.h | 6 +----- > > 2 files changed, 1 insertion(+), 9 deletions(-) > > > > Gabriel, is this what you were thinking? > > Thanks Chuck. > > This looks good to me as a way to disable it in stable and prevent > userspace from trying to use it. Up to fanotify maintainers to decide > whether to bring the rest of the series or merge this, First of all, the "rest of the series" is already queued for 5.10.y. I too was a bit surprised from willingness of stable tree maintainers to allow backports of entire features along with Chuck's nfsd backports. I understand the logic, I was just not aware when this shift in stable ideology had happened. But having backported the entire fanotify 6.1 code as is to 5.15 and 5.10 I see no reason to make an exception for FAN_FS_ERROR. Certainly not because two patches were left out of 5.10.y (and are now queued). I think that the benefits of fanotify code parity across 6.1 5.15 5.10 outweigh the risk of regressions introduced by this specific feature. So please do not revert. Thanks, Amir.
