Re: [PATCH 2/2] timer: Make sure TIMER_FLAG_MASK bits are free in allocated base

[Viresh Kumar]

Hi Thomas,

On 28 February 2014 18:52, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Fri, 28 Feb 2014, Viresh Kumar wrote:
>
>> Currently we are using two lowest bit of base for internal purpose and so they
>> both should be zero in the allocated address. The code was doing the right thing
>> before this patch came in:
>>
>> commit c5f66e99b7cb091e3d51ae8e8156892e8feb7fa3
>> Author: Tejun Heo <tj@xxxxxxxxxx>
>> Date:   Wed Aug 8 11:10:28 2012 -0700
>>
>>     timer: Implement TIMER_IRQSAFE
>>
>> Tejun probably forgot to update this piece of code which checks if the lowest
>> 'n' bits are zero or not and so wasn't updated according to the new flag. Lets
>> use TIMER_FLAG_MASK in the calculations here, so that this code wouldn't require
>> a change later on with another flag in.
>
> Are you planning to introduce more flag horror? Don't go there. The
> timer_list code is about to be rewritten completely and I'm not going
> to add new features to the existing code base.

Do you already have stuff prepared that can be shared on that? I am asking
because I am working on some CPU isolation stuff for Networking domain and
it looks like I need to add another of these flags :( .. I know its
just not acceptable
and so wanted your thoughts on how can I get things fixed.

Peter asked me to implement something like cpuset.quiesce to move away all
timers/workqueues/etc from a cpuset. It was proposed here:

https://lkml.org/lkml/2014/1/15/186

Now, I was looking to migrate away the timers first but I obviously
shouldn't migrate
the pinned timers. One way out to identify PINNED timers is to mark them PINNED
with the flag bits, which you wouldn't allow. Can you give some other idea with
which I can get this solved.

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/