On Sat, Jun 29, 2024 at 4:13 AM KP Singh <kpsingh@xxxxxxxxxx> wrote:
> On Tue, Jun 11, 2024 at 6:35 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On May 15, 2024 KP Singh <kpsingh@xxxxxxxxxx> wrote:
> > >
>
> [...]
>
> > > +/**
> > > + * security_toggle_hook - Toggle the state of the LSM hook.
> > > + * @hook_addr: The address of the hook to be toggled.
> > > + * @state: Whether to enable for disable the hook.
> > > + *
> > > + * Returns 0 on success, -EINVAL if the address is not found.
> > > + */
> > > +int security_toggle_hook(void *hook_addr, bool state)
> > > +{
> > > + struct lsm_static_call *scalls = ((void *)&static_calls_table);
> >
> > GCC (v14.1.1 if that matters) is complaining about casting randomized
> > structs. Looking quickly at the two structs, lsm_static_call and
> > lsm_static_calls_table, I suspect the cast is harmless even if the
> > randstruct case, but I would like to see some sort of fix for this so
> > I don't get spammed by GCC every time I do a build. On the other hand,
> > if this cast really is a problem in the randstruct case we obviously
> > need to fix that.
> >
>
> The cast is not a problem with rand struct, we are iterating through a
> 2 dimensional array and it does not matter in which order we iterate
> the first dimension.
That was my suspicion when I looked at it quickly after the gcc
complained, but if nothing else the compiler splat needed to be
resolved. Based on your comment it looks like you've fixed that in
v13, that's good. Please make sure to test with both gcc and clang in
the future.
In an effort to avoid the "merge this now!" shouts and any other
attempted maintainer manipulations using Linus' email as
justification, I want to make it clear that the earliest the v13 would
possibly be merged is after the upcoming merge window. See the
"Kernel Source Branches and Development Process" in the LSM guidance
document below:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git/tree/README.md
--
paul-moore.com
