Re: [PATCH v2 0/3] cgroup/dmem: allow atomic irrestrictive writes to dmem.max

From: Maarten Lankhorst

Date: Wed Mar 25 2026 - 13:47:10 EST


Hey,

Den 2026-03-23 kl. 18:37, skrev Thadeu Lima de Souza Cascardo:
> On Mon, Mar 23, 2026 at 05:46:28PM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>>
>> Den 2026-03-21 kl. 20:27, skrev Tejun Heo:
>>> Hello,
>>>
>>> Generally looks okay to me. One comment on 3/3 — the naked xchg() in
>>> set_resource_max() needs a comment explaining why it's used instead of
>>> page_counter_set_max() and what the semantics are (unconditionally sets max
>>> regardless of current usage to prevent further allocations, since there's no
>>> eviction mechanism yet).
>>>
>>> Applied 1/3. Maarten, Michal, what do you think?
>>
>> Yeah probably drop 2/3 too since there is no longer a case where setting a limit may fail.
>>
>> Kind regards,
>> ~Maarten Lankhorst
>
> Actually, this can still happen if an invalid region name is given.
>
> So, one could write:
>
> echo -e 'region1 max\ninvalidregion2 max\n' > dmem.max
>
> And even though setting the value for region1 would be applied, the write
> would return -EINVAL.

Makes sense. It would be good to validate in advance then. If that's not possible we
should at least not error when we try to update 2 regions simultaneously. Likely the
best to do so anyway if we want to handle eviction, which may be handled in a blocking
fashion.

Kind regards,
~Maarten Lankhorst