archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <>
To: Linus Torvalds <>
Subject: Re: [GIT PULL] lsm/lsm-pr-20240105
Date: Wed, 10 Jan 2024 14:54:29 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Jan 9, 2024 at 4:08 PM Linus Torvalds
<> wrote:
> On Fri, 5 Jan 2024 at 15:21, Paul Moore <> 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.

Thanks for pulling the changes, I'm sorry the syscall table entries
for the LSM syscalls were not how you want to see them, but I'm more
than a little confused as to what exactly we did wrong here.  A more
detailed explanation would be helpful; if there is a doc somewhere
that explains the process, feel free to just drop a pointer.

I did provide a note in the pull request that based on linux-next
there were likely to be some conflicts in the syscall tables, but that
was evidently not sufficient, or we just added the syscall tables the
wrong way.  Your reply makes me believe we added the syscalls to the
arch tables the wrong way, but looking at your merge commit and the
files themselves (no helpful comments) I don't see anything obvious.
Quickly scanning the kernel docs doesn't reveal anything related
either, although I might be missing it.  The patches also didn't get
any comments regarding the syscall tables during review, and aside
from the numbering conflicts in linux-next, there were no comments
along the lines of "you need to do it this way" there either.

I want to do things The Right Way the next time around, but I need
some help to understand what that is ... ?


  reply	other threads:[~2024-01-10 19:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-05 23:21 [GIT PULL] lsm/lsm-pr-20240105 Paul Moore
2024-01-09 21:07 ` Linus Torvalds
2024-01-10 19:54   ` Paul Moore [this message]
2024-01-10 20:22     ` Linus Torvalds
2024-01-10 20:58       ` Paul Moore
2024-01-10 21:20         ` Casey Schaufler
2024-01-09 21:40 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).