On Wed, 2022-12-07 at 08:58 +0100, Roberto Sassu wrote:

On Tue, 2022-12-06 at 19:21 -0500, Paul Moore wrote:

quoted

On Mon, Nov 28, 2022 at 9:43 AM Roberto Sassu
[off-list ref] wrote:

quoted

From: Roberto Sassu <roberto.sassu@huawei.com>

Ensure that for non-void LSM hooks there is a description of the return
values.

Also, replace spaces with tab for indentation, remove empty lines between
the hook description and the list of parameters, adjust semicolons and add
the period at the end of the parameter description.

Finally, move the description of gfp parameter of the
xfrm_policy_alloc_security hook together with the others.

Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
---
 include/linux/lsm_hooks.h | 221 ++++++++++++++++++++++++--------------
 1 file changed, 138 insertions(+), 83 deletions(-)

Thanks Roberto, I've merged this into lsm/next with one small tweak (below).

quoted

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index c35e260efd8c..6502a1bea93a 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h

@@ -677,7 +695,7 @@
  *     indicates which of the set*uid system calls invoked this hook.  If
  *     @new is the set of credentials that will be installed.  Modifications
  *     should be made to this rather than to @current->cred.
- *     @old is the set of credentials that are being replaces
+ *     @old is the set of credentials that are being replaces.

Might as well change "replaces" to "replaced".  I'll go ahead and fix
that up during the merge.

Thanks a lot!

Ops, I found an issue for fs_context_parse_param. It seems that the
kernel doc and lsm_hooks.h provide different conventions for it.

+ David

Kernel doc:

It should return 0 to indicate that the parameter should be passed on
to the filesystem, 1 to indicate that the parameter should be discarded
or an error to indicate that the parameter should be rejected.

lsm_hooks.h:

The LSM may reject it with an error and may use it for itself, in which
case it should return 0; otherwise it should return -ENOPARAM to pass
it on to the filesystem.

Looking at the code, the latter seems the right one. I would send
another patch to fix the kernel doc.

For this patch, I saw it is already in lsm/next. Paul, should I do an
incremental patch or change the one in the repo and you force push it?
I would just remove the three lines after the parameters description.

Thanks

Roberto