Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
MIME-Version: 1.0
References: <20231027163400.5764d549@canb.auug.org.au> <20231027.Soon0Gee4xul@digikod.net>
In-Reply-To: <20231027.Soon0Gee4xul@digikod.net>
From:   Paul Moore <paul@paul-moore.com>
Date:   Sat, 28 Oct 2023 11:34:48 -0400
Message-ID: <CAHC9VhTHVhgdBpSkMocmgWZgQzMcxMwC8Tp=Qr13Xvxaof82Pw@mail.gmail.com>
Subject: Re: linux-next: build failure after merge of the landlock tree
To:     =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= <mic@digikod.net>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Casey Schaufler <casey@schaufler-ca.com>,
        Kees Cook <keescook@chromium.org>,
        Konstantin Meskhidze <konstantin.meskhidze@huawei.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Oct 27, 2023 at 8:56=E2=80=AFAM Micka=C3=ABl Sala=C3=BCn <mic@digik=
od.net> wrote:
>
> Thanks Stephen, your patch is good! I tested it with the merge of my
> branch and LSM/dev-staging.
>
> The new Landlock changes (tested in -next for a few weeks) add a new
> call to security_add_hooks() which gets a new signature with commit
> 9b09f11320db ("LSM: Identify modules by more than name") from
> the LSM/dev-staging branch [1].
>
> I plan to send a PR with my branch in the next merge window (for
> v6.7-rc1).
>
> We should squash Stephen's patch in commit 9b09f11320db ("LSM:
> Identify modules by more than name") but it would not be possible
> without my branch. I see two solutions:
> * keep Stephen's patch in -next only, or
> * rebase LSM/dev-staging on my branch now, and rebase it later on
>   v6.7-rc1 once my branch is merged (which is the workflow described in
>   [1]).
>
> Paul, what do you think?

Thanks Stephen, Micka=C3=ABl.

Once the Landlock tree is pulled into Linus' tree during the next
merge window I'll update the LSM syscall patches currently living in
lsm/dev-staging and this conflict should go away.  FWIW, there are
other conflicts with the LSM syscall patchset, most notably in the
syscall registrations, that should also resolve themselves when I
rebase on top of v6.7-rc1.

--=20
paul-moore.com