This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/7] tunables: Add hooks to get and update tunables
On 17/05/2017 04:17, Siddhesh Poyarekar wrote:
> On Wednesday 17 May 2017 01:59 AM, Adhemerval Zanella wrote:
>> I would prefer to simplify a bit this macro to avoid use pointer and
>> use the value instead and specify the type directly (so we can add
>> some range/type check in the future). Something like:
>>
>> # define TUNABLE_UPDATE_VAL(__top, __ns, __id, __val, __type) \
>> ({ \
>> __tunable_update_val (TUNABLE_ENUM_NAME (__top, __ns, __id), \
>> &(__type) { __val }); \
>> })
>
> It already does the range check based on the type of the tunable using
> the TUNABLE_SET_VAL_IF_VALID_RANGE macro. Isn't that sufficient?
Indeed and I think it might be extensible enough for user-defined types
(for instance a tunable that might have a very strict value range). In
any case, I still think to use the value instead of a pointer would be
simpler, unless you plan to TUNABLE_UPDATE_VAL to return the previous
value (which seems to the case currently).
>
>>> Given that the tunable structure is now relro, this is only really
>>> possible from within the dynamic linker before it is relocated. In
>>> future the tunable list may get split into mutable and immutable
>>> tunables where mutable tunables can be modified by the library and
>>> userspace after relocation as well. However whenever we actually do
>>> that, we will have to ensure that the mutable tunables are protected
>>> with locks.
>>
>> This worries me a bit because I would like a compiler/linker warning
>> that updating a tunable in wrong place is not allowed. Is there a
>> way to make compiler/linker barf with an invalid update?
>
> The __tunable_update_val function is currently private to ld.so, so the
> likelihood of doing an update outside of the linker (and hence after
> relocation) is remote. The only possibility is for the possibility of
> the tunable being updated inside ld.so after relocation, but that is the
> case for GLRO(...) vars too.
>
> Maybe something for us to note in future is to ensure that if/when we
> introduce tunables that can be updated at runtime, we ensure that they
> have different accessors from the regular tunables that cannot touch the
> immutable tunables.
Fair enough.