Re: [PATCH 6.12.y 2/9] landlock: Fix handling of disconnected directories

["Mickaël Salaün" <mic@digikod.net>]

On Thu, Apr 02, 2026 at 12:31:13AM +0530, Harshit Mogalapalli wrote:
> Hi Mickaël,
> 
> On 01/04/26 20:54, Mickaël Salaün wrote:
> > Thanks Harshit.  BTW, the following commit should also be backported
> > (and it was specifically created to ease backports): 6803b6ebb816
> > ("landlock: Fix cosmetic change").
> > 
> 
> I did see this as an approach, but I felt like for CVE backports keep the
> cherry-picks minimal if they don't really help resolving conflicts. I had no
> conflicts while cherry-picking and its a cosmetic change so according to
> stable rules I didn't take it as cherry-picking the final fix is clean.

Ok, makes sense.

> 
> 
> > The current patch should be backported down to 5.15, but it needs to be
> > adapted.  Harshit, I can work on it, please let me know.
> > 
> 
> I agree and will give it a try, and if I can't do it I will let you know.
> (just was focusing on new branches first)

Great, thanks!

> 
> > I'm wondering why I didn't get notified that some Fixes patch couldn't
> > automatically be backported.  Greg, is there some way to register for
> > this kind of issue?  What are the rules to not automatically backport
> > patches?
> > 
> 
> Greg can answer this better probably but just sharing my learnings, Fixes
> tag is never an assurance for getting a patch backported to stable or
> getting a failed patch notification when it fails to apply, CC:stable is the
> only way to request backporting a patch to stable.

Ok, I couldn't figure out in which case a Fixes commit would not make
sense to backport, but I'll add CC:stable next times.

> 
> Commits with Fixes tag only(without stable tag) are not guaranteed to be
> backported and particularly if they have conflicts. So, for making sure
> these get to stable I suggest to use CC:stable that way you will also be
> notified if the patch fails to apply.

Good to know.

> 
> > I also noticed that other Fixes commits were not backported to stable
> > branches whereas they can be cleanly cherry-picked.  I'm also wondering
> > why they weren't pick.
> > 
> 
> They might be clean cherry-picks now but not when they appeared upstream,
> that is one case, and Fixes tag doesn't always ensure a patch is backported
> to stable.

I'm genuinely wondering in which case a backport would not be needed.

> 
> > FYI, here are the ones that can be backported without needing changes:
> > - 602acfb54119 ("landlock: Optimize stack usage when !CONFIG_AUDIT")
> > - 60207df2ebf3 ("landlock: Remove useless include")
> > - 7aa593d8fb64 ("selftests/landlock: Fix missing semicolon")
> > 
> 
> The first one doesn't apply on 6.12.y(6.12.77) , maybe that's the reason.
> 
> 
> > They should all be backported, even if they look like cosmetic fixes>
> (because they might be needed for other fixes/backports).
> > 
> > Here is the other one that needs to be adapted:
> > - e4d82cbce225 ("landlock: Fix TCP handling of short AF_UNSPEC addresses")
> > 
> 
> I think the way to get these to stable is include CC:stable along with Fixes
> tag. As documented in Option 1 of [1]
> 
> Now that we have missing fixes, I think the best way is to send backports to
> stable@vger.kernel.org

Yes, I'll do that.

> 
> I wonder if it would be helpful to make this explicitly stated: "Fixes tag
> alone is not a trigger for stable backports, CC:stable is needed if you want
> you patch to be backported to stable kernels(and also get notified if it
> fails to apply)" ?

I think yes. My understanding was that if there is a Fixes tag, it will
be backported.  The same for CC:stable, but in this case in a
best-effort way because the fixed commit wasn't specified.

> 
> [1] https://www.kernel.org/doc/html/v6.19/process/stable-kernel-rules.html
> 
> > Thanks,
> >   Mickaël
> >