Re: [PATCH] fanotify: fix copy_event_to_user() fid error clean up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue 15-06-21 11:41:53, Greg KH wrote:
> On Tue, Jun 15, 2021 at 07:24:32PM +1000, Matthew Bobrowski wrote:
> > On Mon, Jun 14, 2021 at 12:28:42PM +0200, Jan Kara wrote:
> > > On Fri 11-06-21 10:04:06, Amir Goldstein wrote:
> > > > On Fri, Jun 11, 2021 at 6:32 AM Matthew Bobrowski <repnop@xxxxxxxxxx> wrote:
> > > > Trick question.
> > > > There are two LTS kernels where those fixes are relevant 5.4.y and 5.10.y
> > > > (Patch would be picked up for latest stable anyway)
> > > > The first Fixes: suggests that the patch should be applied to 5.10+
> > > > and the second Fixes: suggests that the patch should be applied to 5.4+
> > > > 
> > > > In theory, you could have split this to two patches, one auto applied to 5.4+
> > > > and the other auto applied to +5.10.
> > > > 
> > > > In practice, this patch would not auto apply to 5.4.y cleanly even if you
> > > > split it and also, it's arguably not that critical to worth the effort,
> > > > so I would keep the first Fixes: tag and drop the second to avoid the
> > > > noise of the stable bots trying to apply the patch.
> > > 
> > > Actually I'd rather keep both Fixes tags. I agree this patch likely won't
> > > apply for older kernels but it still leaves the information which code is
> > > being fixed which is still valid and useful. E.g. we have an
> > > inftrastructure within SUSE that informs us about fixes that could be
> > > applicable to our released kernels (based on Fixes tags) and we then
> > > evaluate whether those fixes make sense for us and backport them.
> > >
> > > > > Should we also be CC'ing <stable@xxxxxxxxxxxxxxx> so this gets backported?
> > > > >
> > > > 
> > > > Yes and no.
> > > > Actually CC-ing the stable list is not needed, so don't do it.
> > > > Cc: tag in the commit message is somewhat redundant to Fixes: tag
> > > > these days, but it doesn't hurt to be explicit about intentions.
> > > > Specifying:
> > > >     Cc: <stable@xxxxxxxxxxxxxxx> # v5.10+
> > > > 
> > > > Could help as a hint in case the Fixes: tags is for an old commit, but
> > > > you know that the patch would not apply before 5.10 and you think it
> > > > is not worth the trouble (as in this case).
> > > 
> > > I agree that CC to stable is more or less made redundant by the Fixes tag
> > > these days.
> 
> No, it is NOT.
> 
> We have to pick up the "Fixes:" stuff because of maintainers and
> developers that forget to use Cc: stable like has been documented.
> 
> But we don't always do it as quickly as a cc: stable line will offer.
> And sometimes we don't get to those at all.
> 
> So if you know it needs to go to a stable kernel, ALWAYS put a cc:
> stable as the documentation says to do so.  This isn't a new
> requirement, it's been this way for 17 years now!

OK, as I said I do add cc: stable when I think the patch should go to
stable. But practically patches with the Fixes tag get to stable so
reliably that I was suspecting you actually have a bot processing Linus'
tree and forwarding all patches with Fixes tag to stable as well :) If
that's not the case, I'm sorry for misguiding Matthew.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux