[GIT PULL] lsm/lsm-pr-20240911

[Tetsuo Handa]

On 2024/09/13 10:29, Paul Moore wrote:
> Linus,
> 
> We've got a reasonably large pull request for the LSM framework this
> time (at least it's large for us), here are the highlights:
> 
> * Move the LSM framework to static calls
> 
> Based on some of our exchanges over the summer, it sounds like you
> are already familiar with the effort to convert the LSM callbacks
> from function pointers to static calls.  This pull request includes
> that work and transitions the vast majority of the LSM callbacks into
> static calls.  Those callbacks which haven't been converted were
> left as-is due to the general ugliness of the changes required to
> support the static call conversion; we can revisit those callbacks
> at a future date.
> 
> It is worth mentioning that Tetsuo Handa is opposed to the static call
> patches, some even carry his NACK, as they make it more difficult to
> dynamically load out-of-tree LSMs, or unsupported LSMs on distro kernels.
> Many of us have tried to explain that out-of-tree LSMs are not a
> concern for the upstream LSM framework, or the Linux kernel in general,
> and that decisions around what LSMs are enabled in distro kernels is
> a distro issue, not an upstream issue, but unfortunately Tetsuo
> continues to disregard these arguments.

No, this is not only a distro issue but also an upstream issue!
Because the upstream cannot afford accepting whatever proposed LSMs
( https://lkml.kernel.org/r/8ac2731c-a1db-df7b-3690-dac2b371e431@I-love.SAKURA.ne.jp ).
That is, out-of-tree LSMs cannot become in-tree and obtain stable LSM ID is
partially due to upstream (e.g. out of resources for review, or failure to
pass patent examination because upstream does not think it adds a new value).
Making out-of-tree (or in-tree but not built-in) LSMs harder to use is a
penalty imposed by "Permanent members are exercising veto".
At least, assigning stable LSM ID to whatever proposed LSM has absolutely
zero cost. Current policy is a clear intention to lock out out-of-tree LSMs.
If you say "I don't have intention to lock out out-of-tree LSMs", please
don't go with just NACK added.