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?
