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

[Paul Moore]

On Thu, Sep 10, 2026 at 4:12 AM Mickaël Salaün <mic at digikod.net> wrote:
> 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 at 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 at paul-moore.com> wrote:
> > > > > On Jul 26, 2026 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic at 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.

We discussed this already during an unrelated offline conversation,
but for the sake of others who might be wondering, that's not quite
how things work in the LSM tree.  As a refresher, here is how the LSM
is managed:

https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#kernel-source-branches-and-development-process

As a quick summary, the lsm/stable-X.Y branch (the current being
lsm/stable-7.3) contains patches that go up to Linus during the
v7.3-rcX cycle.  When relevant, patches in lsm/stable-X.Y are also
tagged for linux-stable.  New development targeting the upcoming merge
window is merged into the lsm/dev branch.

The lsm/next branch feeds into the daily linux-next tree and is
composed by cloning the latest lsm/stable-X.Y branch and merging the
lsm/dev branch on top.  This enables linux-next testing of patches
bound for both the current RC cycle as well as the upcoming merge
window.  During the normal RC cycle, the lsm/next branch is updated
whenever there is a change to either the latest lsm/stable-X.Y branch
or the lsm/dev branch.

While one might imagine merge conflicts in lsm/next requiring manual
intervention would be common, after years of experience I can say that
they are not. On the rare occasion when conflicts require manual
intervention, they haven't been very difficult to resolve.  If we do
arrive at such a situation we can work together to sort it out.

> 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.

As documented in the link above, lsm/dev should be a stable branch
that you can use as a base for patchsets.  It will move forward as
patches are added, but it is rebased only under extreme cases (e.g.
filesystem corruption, etc.), and rebases are typically communicated
to the list.

-- 
paul-moore.com