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.
>
