On Mon, Oct 02, 2023 at 07:04:27PM +0900, Tetsuo Handa wrote: > On 2023/10/02 0:44, Kees Cook wrote: > > On October 1, 2023 4:31:05 AM PDT, Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > >> Kees Cook said there is no problem if the policy of assigning LSM ID value were > >> > >> 1) author: "Hello, here is a new LSM I'd like to upstream, here it is. I assigned > >> it the next LSM ID." > >> maintainer(s): "Okay, sounds good. *review*" > >> > >> 2) author: "Hello, here is an LSM that has been in active use at $Place, > >> and we have $Xxx many userspace applications that we cannot easily > >> rebuild. We used LSM ID $Value that is far away from the sequential > >> list of LSM IDs, and we'd really prefer to keep that assignment." > >> maintainer(s): "Okay, sounds good. *review*" > >> > >> and I agreed at https://lkml.kernel.org/r/6e1c25f5-b78c-8b4e-ddc3-484129c4c0ec@xxxxxxxxxxxxxxxxxxx . > >> > >> But Paul Moore's response was > >> > >> No LSM ID value is guaranteed until it is present in a tagged release > >> from Linus' tree, and once a LSM ID is present in a tagged release > >> from Linus' tree it should not change. That's *the* policy. > >> > >> which means that the policy is not what Kees Cook has said. > > > > These don't conflict at all! Paul is saying an ID isn't guaranteed in upstream > > until it's in upstream. I'm saying the id space is large enough that you could > > make a new out of tree LSM every second for the next billion years. The upstream > > assignment process is likely sequential, but that out of sequence LSMs that show > > a need to be upstream could make a case for their existing value. > > Excuse me? If the LSM community wants the assignment sequential, the LSM community > cannot admit the LSM value assigned to a not-yet-in-tree LSM. > > If "Okay, sounds good." does not imply that the LSM community admits the LSM value > assigned to a not-yet-in-tree LSM, what did "Okay, sounds good." mean? I'm saying that if someone participates with upstream correctly, they'll get a sequential ID since that is the expected process. And if an LSM is out of tree for years and years in some large ecosystem that has deeply hard-coded the LSM ID but now wants the LSM to land upstream, then it's likely that an out-of-sequence ID would be accepted. My point is that there is nothing technical stopping an out-of-tree LSM from existing, and that the political issues for bringing a large out-of-tree LSM upstream are going to have plenty of other negotiations around maintaining operational behavior, of which and LSM ID is unlikely to be a sticking point. Every release that some code (LSM or not) is out of tree makes it that much harder to land upstream. (In other words, the challenges to upstreaming a long-time-out-of-tree codebase are much larger than dealing with an out-of-sequence LSM ID.) -Kees -- Kees Cook
