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

[Viresh Kumar]

On 11 March 2014 15:56, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> 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.

Ping!!
--
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/