On Tue 19-03-24 18:10:15, Amir Goldstein wrote: > On Tue, Mar 19, 2024 at 5:57 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > On Mar 19, 2024, at 11:32 AM, Sasha Levin <sashal@xxxxxxxxxx> wrote: > > > On Tue, Mar 19, 2024 at 04:26:34AM +0200, Amir Goldstein wrote: > > >> Sasha, > > >> Something is off. > > >> This is a new feature. > > >> Not sure how it got selected for stable and dragged a *lot* of > > >> infrastructure code changes with it. > > >> Can you explain why triggered this backports or is it just "AI"? > > > > > > Hey Amir, > > > > > > The patches you've pointed out are part of a series backported by Chuck > > > for the benefit of nfsd. > > > > > > In general, we don't object to new functionality as long as: > > > > > > 1. It helps reduce divergence of later fixes from upstream. > > > 2. It's well tested. > > > > Amir, this is why I asked you about how you test fanotify. > > > > The goal of my backport was to address issues with the NFSD > > filecache, and unfortunately, a lot of it depends on fixes > > and features in fs/notify. > > OK, I wonder which features filecache depends on? > I can't believe that it depends on any of the final > "wire up fanotify XXX" commits. > > Anyway, I do not have an objection to backporting those features, > just wanted to know if there was a reason. > In house, we are using the 5.15 LTS kernel with some of those > features backported. > > Jan, WDYT? So if somebody (Chuck in this case) actually consciously backported stuff and tested everything works then I have no objection... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
