[PATCH v2 0/3] landlock: Refactor layer masks
Günther Noack
gnoack3000 at gmail.com
Fri Feb 6 07:49:39 UTC 2026
On Fri, Feb 06, 2026 at 08:32:06AM +0100, Günther Noack wrote:
> On Wed, Jan 28, 2026 at 10:31:07PM +0100, Mickaël Salaün wrote:
> > On Sun, Jan 25, 2026 at 08:58:50PM +0100, Günther Noack wrote:
> > > P.S.: I am open to suggestions on what the "layer masks" variables
> > > should be called, because the name "layer masks" might be less
> > > appropriate after this change. I have not fixed up the name
> > > everywhere because fixing up the code took priority for now.
> >
> > Could you please clarify your thoughts and explain why this name might
> > not be appropriate anymore? Any list of name proposals?
> >
> > If we rename the variables, this should be done in the same refactoring
> > patch.
>
> When this was an array of layer_mask_t, the name layer_masks was a
> description of that underlying data type. Now that we have removed
> the layer_mask_t datatype, it is not as obviously true any more.
>
> When trying to name these variables after the "role" that they have in
> their declaration context, I think of them as "unfulfilled per-layer
> access requests", but that strikes me as a bit long.
>
> For the upcoming patch set, I'm leaning towards naming these variables
> just "masks", to keep it short.
OK, staring at the code a bit longer, I realize that since the type is
now named "struct layer_access_masks", "layer_masks" is actually still
a reasonable shorthand. I have abbreviated that to "masks" in some
places where it is anyway clear from the context that those are the
layer access masks, but left it as "layer_masks" in places where we
also use other access masks, for disambiguation.
–Günther
More information about the Linux-security-module-archive
mailing list