Re: [PATCH v2 01/17] landlock: Prepare ruleset and domain type split

On Sun, Apr 12, 2026 at 05:29:24PM +0100, Tingmao Wang wrote:
> On 4/6/26 15:36, Mickaël Salaün wrote:
> > [...]
> 
> Hi Mickaël,
> 
> I like this approach, as I basically ended up doing similar refactoring
> previously for the hashtable / array-based domain changes, and having this
> done first should make it easier to adopt the domain data structure
> changes in the future.
> 
> I assume it's fine for me to add:
> Reviewed-by: Tingmao Wang <[email protected]>

I couldn't keep your tag because of the refactoring, but I'll appreciate
a new review.

> 
> > @@ -175,19 +163,24 @@ static void free_rule(struct landlock_rule *const rule,
> >  
> >  static void build_check_ruleset(void)
> >  {
> > -	const struct landlock_ruleset ruleset = {
> > +	const struct landlock_rules rules = {
> >  		.num_rules = ~0,
> > +	};
> > +	const struct landlock_ruleset ruleset = {
> >  		.num_layers = ~0,
> >  	};
> >  
> > -	BUILD_BUG_ON(ruleset.num_rules < LANDLOCK_MAX_NUM_RULES);
> > +	BUILD_BUG_ON(rules.num_rules < LANDLOCK_MAX_NUM_RULES);
> >  	BUILD_BUG_ON(ruleset.num_layers < LANDLOCK_MAX_NUM_LAYERS);
> >  }
> >  
> >  /**
> > - * insert_rule - Create and insert a rule in a ruleset
> > + * insert_rule - Create and insert a rule in a rule set
>                                                   ^^^^^^^^
> 
> Should this be rule storage to be consistent with the next 2 lines?
> 
> Alternatively maybe we can just say "struct landlock_rules" to avoid
> inventing new names?

I realized I didn't replied here, but the v3 now uses "rule storage" to
be future-proof.

> 
> >   *
> > - * @ruleset: The ruleset to be updated.
> > + * @rules: The rule storage to be updated.  The caller is responsible for
> > + *         any required locking.  For rulesets, this means holding
> > + *         landlock_ruleset.lock.  For domains under construction, no lock is
> > + *         needed because the domain is not yet visible to other tasks.
> >   * @id: The ID to build the new rule with.  The underlying kernel object, if
> >   *      any, must be held by the caller.
> >   * @layers: One or multiple layers to be copied into the new rule.
>