Re: [PATCH v3 3/12] security: Add LSM_AUDIT_DATA_NS for namespace audit records

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

On Wed, Sep 09, 2026 at 03:49:11PM -0400, Paul Moore wrote:
> On Wed, Sep 9, 2026 at 2:35 PM Mickaël Salaün <mic@digikod.net> wrote:
> > On Mon, Aug 31, 2026 at 05:26:20PM -0400, Paul Moore wrote:
> > > On Tue, Aug 11, 2026 at 4:16 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Jul 26, 2026 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic@digikod.net> wrote:
> 
> ...
> 
> > > Mickaël, if you would like me to merge the remaining patches in this
> > > patchset into the lsm/dev branch just let me know.
> >
> > I'll send a new patch series soon because this v3 would not apply
> > anymore.
> 
> Okay.
> 
> > I'll include your lsm/dev patches to keep a consistent patch
> > series.
> 
> Please don't as those are already merged.  If you want to stick with
> the same patch series, which is fine, just note that the first three
> patches have already been merged into the LSM tree.  It's not uncommon
> for patchsets to add or drop patches over time as both the patchset
> and the surrounding environment progress.

Yeah, I know, but at the same time are there (merged) users of these
hooks?  Anyway, we should of course avoid to have two commits for the
same patch in different branches (even if that would not be an issue for
Git), but having to handle several origins (e.g. the lsm/dev branch for
new hooks and the master branch for fixes) might lead to an unpleasant
gymnastic.

Another concern is to ease review (for both humans and bots), which
might require a well-known base commit, instead of a (transient?)
merge commit.  That's the reason why I wanted to keep the complete
series, even if when we'll apply it, we can drop the first (already
applied) patches.

My understanding is also that Linus prefers consistent pull requests,
and I'm wondering if that would be ok to send a PR with the lsm/dev (in
flight to be merged in master, but not yet) as origin.  That could still
lead to merge conflicts though...

At least, I think it would help to have these three commits rebased on a
(recent) Linux tag (without other commits in between, like the cred's
one).