[PATCH v6 4/4] Add system-wide tunables: Filters

[DJ Delorie]

Yury Khrustalev <yury.khrustalev@arm.com> writes:
> Let's do it step by step. What I propose will cover all possible
> scenarios: admin enforces a value (1), recommends a value (2), doesn't
> care (3).

Sure, I'm ok with only implementing the "overridable or not" feature at
first.  I'd like to leave the two-bit field to allow for two other
options later, though.  I think we can spare a bit for unseen future
needs, and I still think allowing an admin to permit bigger/smaller
values, has some value.

>> Consider:
>> 
>> * Admin limits the number of malloc heaps to 16 because glibc
>>   autodetects the number of CPUs wrong.
>
> This will complicate things and we would have to assess how useful this
> use case is going to be before we try to implement it.

I wasn't trying to justify the use case, just trying to demonstrate why
a bigger/smaller restriction might be useful to an admin.

> Plus, we probably should avoid making tunables.conf Turing-complete,

I offered to put a full LR(1) language in there with a byte code
interpreter, but Florian quickly stopped me ;-)

(I've done it before.  It's not that difficult.  Let me whip up a
patch... no?  are you sure?  well, ok...  ;)

> otherwise it will become a vulnerability of its own :) If you allow to
> narrow down the accepted range, you'd have to support both upper and
> lower boundary. This is doable, but I'd rather add this in another
> patch, but only if there is some need for this.

Later is OK.  Simple is good, I don't want to do a range, just
increase/decrease.

>> * User further limits it to 1 to avoid heap-related fragmentation.
>
> Also, as far as setting tunables is concerned, there is no notion of
> "limiting" anything: we set a value if we want to use a non-default one.

I was referring to the effect of the tunable.  That tunable
(malloc.arena_max) is a maximum, so it's action is to limit.