[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQbxJ4-z4Hp7CSmtcTNOWGFeQF2eEyct9=nHCMN_89YXw@mail.gmail.com>
Date: Mon, 30 Oct 2023 12:52:50 -0400
From: Paul Moore <paul@...l-moore.com>
To: John Johansen <john.johansen@...onical.com>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Casey Schaufler <casey@...aufler-ca.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
linux-security-module@...r.kernel.org
Subject: Re: linux-next: manual merge of the apparmor tree with the security tree
On Sun, Oct 29, 2023 at 5:09 PM John Johansen
<john.johansen@...onical.com> wrote:
> On 10/28/23 08:32, Paul Moore wrote:
> > On Thu, Oct 26, 2023 at 10:03 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >>
> >> Hi all,
> >>
> >> Today's linux-next merge of the apparmor tree got a conflict in:
> >>
> >> security/apparmor/lsm.c
> >>
> >> between commit:
> >>
> >> 3c3bda37ca1d ("AppArmor: Add selfattr hooks")
> >>
> >> from the security tree and commits:
> >>
> >> bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data")
> >> d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label")
> >>
> >> from the apparmor tree.
> >>
> >> I fixed it up (see below) and can carry the fix as necessary. This
> >> is now fixed as far as linux-next is concerned, but any non trivial
> >> conflicts should be mentioned to your upstream maintainer when your tree
> >> is submitted for merging. You may also want to consider cooperating
> >> with the maintainer of the conflicting tree to minimise any particularly
> >> complex conflicts.
> >
> > Thanks Stephen.
> >
> > John, can you take a look and make sure this is correct (it looks okay to me)?
> >
> yes its good, thanks Stephan.
>
> Acked-by: John Johansen <john.johansen@...onical.com>
>
> Paul just to double check, to make sure we get ordering on this right
> 3c3bda37ca1d ("AppArmor: Add selfattr hooks")
>
> is part of the Three basic syscalls series, the plan is still to have that
> series bake in next for a full cycle?
Yes, that's still the plan. Once v6.7-rc1 is out I'll rebase the LSM
syscall patches and I expect the vast majority of these conflicts to
disappear, although I'm sure we'll pick up some new ones with the rest
of the v6.7-rcX cycle :)
--
paul-moore.com
Powered by blists - more mailing lists