[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whb9anXdo4odpP-ybYbmQs0UaPp1fmDjsWFiGxV5aOmig@mail.gmail.com>
Date: Tue, 9 Jan 2024 13:07:59 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Paul Moore <paul@...l-moore.com>
Cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] lsm/lsm-pr-20240105
On Fri, 5 Jan 2024 at 15:21, Paul Moore <paul@...l-moore.com> wrote:
>
> The hightlights of the LSM pull
> request are below, but before we get to that I want to mention that I
> expect you will hit merge conflicts in the arch-specific syscall
> tables as well as in the doc userspace-api documentation index. Some
> of these conflicts exist in your tree now (syscall tables), with some
> others likely depending on what is submitted from linux-next and the
> order in which you merge things. All of the conflicts that I've seen
> have been rather trivial and easily resolved, but I wanted to give you
> a heads-up; if you want me to resolve any of these let me know.
The tooling header file updates by the LSM tree were particularly annoying.
Not because the conflicts were hard per se, but because you had done
the header files wrong in the first place.
Your version of the tooling header files just didn't match the real
ones, as you had added your new system calls at the end mindlessly,
without noticing that others had *not* done so, so all your tooling
header system call number additions were just the wrong numbers
entirely.
I fixed it up, but it added an extra layer of "this is just annoying".
You'd have been better off not touching the tooling headers at all,
rather than touch them incorrectly.
Linus
Powered by blists - more mailing lists