Re: FAILED: patch "[PATCH] ima: Avoid blocking in RCU read-side critical section" failed to apply to 6.6-stable tree

[Mimi Zohar <zohar@linux.ibm.com>]

On Tue, 2024-06-25 at 11:10 -0400, Paul Moore wrote:
> On Mon, Jun 24, 2024 at 8:06 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Mon, 2024-06-24 at 18:47 +0200, gregkh@linuxfoundation.org wrote:
> > > The patch below does not apply to the 6.6-stable tree.
> > > If someone wants it applied there, or to any other stable or longterm
> > > tree, then please email the backport, including the original git commit
> > > id to <stable@vger.kernel.org>.
> > > 
> > > To reproduce the conflict and resubmit, you may use the following commands:
> > > 
> > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
> > > git checkout FETCH_HEAD
> > > git cherry-pick -x 9a95c5bfbf02a0a7f5983280fe284a0ff0836c34
> > > # <resolve conflicts, build, test, etc.>
> > > git commit -s
> > > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024062438-shaft-herbicide-4e7d@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
> > > 
> > > Possible dependencies:
> > > 
> > > 9a95c5bfbf02 ("ima: Avoid blocking in RCU read-side critical section")
> > > 260017f31a8c ("lsm: use default hook return value in call_int_hook()")
> > > 923831117611 ("evm: Move to LSM infrastructure")
> > > 84594c9ecdca ("ima: Move IMA-Appraisal to LSM infrastructure")
> > > cd3cec0a02c7 ("ima: Move to LSM infrastructure")
> > > 06cca5110774 ("integrity: Move integrity_kernel_module_request() to IMA")
> > > b8d997032a46 ("security: Introduce key_post_create_or_update hook")
> > > 2d705d802414 ("security: Introduce inode_post_remove_acl hook")
> > > 8b9d0b825c65 ("security: Introduce inode_post_set_acl hook")
> > > a7811e34d100 ("security: Introduce inode_post_create_tmpfile hook")
> > > f09068b5a114 ("security: Introduce file_release hook")
> > > 8f46ff5767b0 ("security: Introduce file_post_open hook")
> > > dae52cbf5887 ("security: Introduce inode_post_removexattr hook")
> > > 77fa6f314f03 ("security: Introduce inode_post_setattr hook")
> > > 314a8dc728d0 ("security: Align inode_setattr hook definition with EVM")
> > > 779cb1947e27 ("evm: Align evm_inode_post_setxattr() definition with LSM infrastructure")
> > > 2b6a4054f8c2 ("evm: Align evm_inode_setxattr() definition with LSM infrastructure")
> > > 784111d0093e ("evm: Align evm_inode_post_setattr() definition with LSM infrastructure")
> > > fec5f85e468d ("ima: Align ima_post_read_file() definition with LSM infrastructure")
> > > 526864dd2f60 ("ima: Align ima_inode_removexattr() definition with LSM infrastructure")
> > 
> > The patch doesn't apply cleanly due to the '0' in security_audit_rule_init():
> >         return call_int_hook(audit_rule_init, 0, field, op, rulestr, lsmrule);
> > 
> > Commit 260017f31a8c ("lsm: use default hook return value in call_int_hook()")
> > removed it.  Instead of backporting commit 260017f31a8c, adding the '0' would be
> > simpler.  This seems to be the only change needed for linux-6.8.y to 6.4.y.
> 
> Agreed.
> 
> > For linux-6.3.y to linux-6.2.y, commit b14faf9c94a6 ("lsm: move the audit hook
> > comments to security/security.c") also needs to be applied.
> > 
> > Paul, how do you normally handle backports?
> 
> Normally I just tag them accordingly and let the stable team handle
> it, with the understanding that the stable team only picks patches
> that have been explicitly marked for stable and not just anything with
> a 'Fixes:' tag.  I'm sure you remember when we discussed this
> recently, there shouldn't be anything new here.

Ok. This should have then been tagged for Stable.
> 
> The tricky part is what the patch fails to merge automatically.  It
> has been my experience that the stable team really doesn't try to do
> any manual merge fixups on the LSM, SELinux, or audit patches, so it
> is really up to me or someone else who cares enough to do the backport
> manually and resubmit.  See "option #3" in the stable kernel docs:
> 
> * https://docs.kernel.org/process/stable-kernel-rules.html#option-3
> 
> I've personally had some bad experiences working with the stable trees
> (YMMV) which combined with a chronic lack of time means that I rarely
> do a manual backport for the stable trees (the bug needs to be
> especially horrendous).  However, others are always free to submit
> backports, see the "option #3" link above.

Ok. Looks like option 3 is the way to go then.

Mimi