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]> > @@ -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? > * > - * @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.
