Messages in this thread |  | | Date | Thu, 22 Sep 2011 13:19:48 +0200 (CEST) | | From | Thomas Gleixner <> | | Subject | Re: [PATCH 4/4] posix-timers: turn it_signal into it_valid flag |
| |
On Wed, 21 Sep 2011, Thomas Gleixner wrote: > On Wed, 21 Sep 2011, Thomas Gleixner wrote: > > On Wed, 7 Sep 2011, Oleg Nesterov wrote: > > > On 09/06, Thomas Gleixner wrote: > > > > > > > > On Tue, 6 Sep 2011, Oleg Nesterov wrote: > > > > > > > > > But how this can help? Suppose that the task is preempted right > > > > > after dequeue_signal() drops ->siglock. We need rcu_read_lock() > > > > > before unlock then, no? > > > > > > > > Crap, you are right, but that's fortunately an easy to solve one :) > > > > > > Yes, this is solvable. But I think we can do something better. > > > > > > > > And. This breaks the accounting logic. I mean the patch from Andi > > > > > which adds the limits. > > > > > > > > That's a different problem and really, it does not break it by any > > > > means. When the timer is released, then the count is decreased and we > > > > can safely assume that the memory is going to be freed in the next > > > > grace period. > > > > > > Yes, but this means we need the counter which we do not have. > > > > > > I think we can avoid this problems. Although I am not sure, I am > > > already sleeping. > > > > > > - we add rcu_read_lock() into dequeueu_signal(). > > > > > > - we add the new "struct k_itimer *my_timer" member into > > > siginfo._timer. Like _sys_private it is not passed to > > > user, and perhaps we can kill _sys_private later. > > > > sys_private is ugly as hell and we should avoid to add another field > > to siginfo. > > > > I think we can embed the timer siginfo into k_itimer instead and > > That should be sigqeue of course, which has siginfo embedded.
Bah, dequeue_signal only gets the copy of the siginfo. So we need to do something about that in any case (*my_timer or embedded sigqueue).
Thanks,
tglx
|  |