[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