This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]