[PATCH v2 0/3] landlock: Refactor layer masks

[Mickaël Salaün]

On Fri, Feb 06, 2026 at 08:49:39AM +0100, Günther Noack wrote:
> 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.

Looks good