linux-kernel - Re: [PATCH V2] security: fix typos and spelling errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhRbZLtBZ8dH-kASnkQUehG4Cu=zd23A6Jj9zfnyeGOTsA@mail.gmail.com>
Date: Sun, 12 Jan 2025 11:36:46 -0500
From: Paul Moore <paul@...l-moore.com>
To: Tanya Agarwal <tanyaagarwal25699@...il.com>
Cc: casey@...aufler-ca.com, takedakn@...data.co.jp, 
	penguin-kernel@...ove.sakura.ne.jp, john.johansen@...onical.com, 
	jmorris@...ei.org, serge@...lyn.com, zohar@...ux.ibm.com, 
	roberto.sassu@...wei.com, dmitry.kasatkin@...il.com, eric.snowberg@...cle.com, 
	mic@...ikod.net, gnoack@...gle.com, stephen.smalley.work@...il.com, 
	omosnace@...hat.com, linux-kernel@...r.kernel.org, apparmor@...ts.ubuntu.com, 
	linux-security-module@...r.kernel.org, linux-integrity@...r.kernel.org, 
	skhan@...uxfoundation.org, anupnewsmail@...il.com
Subject: Re: [PATCH V2] security: fix typos and spelling errors

On Sun, Jan 12, 2025 at 2:30 AM Tanya Agarwal
<tanyaagarwal25699@...il.com> wrote:
>
> From: Tanya Agarwal <tanyaagarwal25699@...il.com>
>
> Fix typos and spelling errors in security module comments that were
> identified using the codespell tool.
> No functional changes - documentation only.
>
> Signed-off-by: Tanya Agarwal <tanyaagarwal25699@...il.com>
> ---
> Thanks Günther, for catching this error.
> The irony of having a spelling mistake in a patch that fixes spelling
> mistakes is not lost on me :)
>
> I've fixed it in V2 of the patch. Thank you for the careful review!
>
> V2: fix spelling mistake - s/beeen/been/
>
>  security/apparmor/apparmorfs.c      | 6 +++---
>  security/apparmor/domain.c          | 4 ++--
>  security/apparmor/label.c           | 2 +-
>  security/apparmor/lsm.c             | 2 +-
>  security/apparmor/policy.c          | 4 ++--
>  security/integrity/evm/evm_crypto.c | 2 +-
>  security/integrity/evm/evm_main.c   | 2 +-
>  security/integrity/ima/ima_main.c   | 6 +++---
>  security/landlock/ruleset.c         | 2 +-
>  security/selinux/avc.c              | 2 +-
>  security/smack/smack.h              | 2 +-
>  security/smack/smack_access.c       | 4 ++--
>  security/smack/smack_lsm.c          | 6 +++---
>  security/smack/smackfs.c            | 2 +-
>  security/tomoyo/domain.c            | 2 +-
>  15 files changed, 24 insertions(+), 24 deletions(-)

Hi Tanya,

Ideally this patchset would be split into into seperate, independent
patches, one for AppArmor, one for IMA/EVM, one for Landlock, one for
SELinux, one for Smack, and one for TOMOYO.  This allows for each LSM
maintainer to review and merge these fixes individually as opposed to
requiring every LSM maintainer to ACK this patch before it can be
merged.  There is also a risk, as with any cross-subsystem patch, that
this patch will cause merge conflicts in the future as there is the
possibility of multiple development trees touching the same file
region, function, etc.

As a general rule, if you have a single patch that touches multiple
kernel subsystems, and the changes in each subsystem can be applied
independently, you really should split the patch into subsystem
specific patches.  You also should post these patches independently,
and not as a single patchset, as a single patchset crossing multiple
subsystems can sometimes cause some confusion among maintainers about
who is going to be responsible for handling the patchset (even if all
the patches are split properly).

--
paul-moore.com