Re: [PATCH v2 2/3] security: Expand task_setscheduler LSM hook to include CPU affinity mask

[Aaron Tomlin]

On Mon, May 11, 2026 at 04:28:09PM -0400, Paul Moore wrote:
[ ... ]
> > Signed-off-by: Aaron Tomlin <atomlin@xxxxxxxxxxx>
> > ---
> >  arch/mips/kernel/mips-mt-fpaff.c | 30 +++++++++++++++++-------------
> >  fs/proc/base.c                   |  2 +-
> >  include/linux/lsm_hook_defs.h    |  3 ++-
> >  include/linux/security.h         | 11 +++++++----
> >  kernel/cgroup/cpuset.c           |  4 ++--
> >  kernel/sched/syscalls.c          |  4 ++--
> >  security/commoncap.c             |  7 +++++--
> >  security/security.c              | 11 ++++++-----
> >  security/selinux/hooks.c         |  3 ++-
> >  security/smack/smack_lsm.c       | 11 +++++++++--
> >  10 files changed, 53 insertions(+), 33 deletions(-)
> 
> I haven't looked too closely at this patch yet, but based on a quick
> glance, can you help me understand why it is included with the other
> two patches in one patchset?  The other two patches look like stable
> level kernel bug fixes, while this patch introduces functionality to
> an existing LSM hook; one of these is not like the others :)
> 
> Unless there is something critical that I'm missing here, I would
> suggest splitting this patch out from the other two bugfixes for
> separate handling.  If there is a patch dependency issue you can
> always mention that in the cover letter.

Hi Paul,

Thank you for taking the time to have a look.

You raise a perfectly valid point.

Please note, the cgroup-related BUG fix will be dropped from the next
iteration of this series. As per Waiman Long (on Cc), a solution for the
BUG was already proposed here [1].

However, I suspect the MIPS-related patch will need to remain coupled with
this feature patch. Because the first patch fundamentally alters the
signature of the security_task_setscheduler() hook, the MIPS FPU affinity
code must be updated concurrently to accommodate the new parameter.
Separating them into entirely different series would likely invite
bisection breakages or awkward merge conflicts, depending on the order in
which they are applied, no?

If this approach sounds sensible to you, I shall prepare a v2 series
reflecting this restructured grouping.

Please let me know your thoughts.

[1]: https://lore.kernel.org/lkml/20260509102031.97608-2-zhangguopeng@xxxxxxxxxx/

Kind regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature