Messages in this thread | ![/](/images/icornerl.gif) | | From | Paul Moore <> | Date | Wed, 10 Jan 2024 14:54:29 -0500 | Subject | Re: [GIT PULL] lsm/lsm-pr-20240105 |
| |
On Tue, Jan 9, 2024 at 4:08 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, 5 Jan 2024 at 15:21, Paul Moore <paul@paul-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.
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 ... ?
-- paul-moore.com
| ![\](/images/icornerr.gif) |