Messages in this thread | | | Subject | Re: lockdep trace from posix timers | From | Peter Zijlstra <> | Date | Mon, 20 Aug 2012 18:03:40 +0200 |
| |
On Mon, 2012-08-20 at 17:58 +0200, Oleg Nesterov wrote: > On 08/20, Peter Zijlstra wrote: > > > > On Mon, 2012-08-20 at 17:32 +0200, Oleg Nesterov wrote: > > > > > > I guess we could steal the entire list and requeue it afterwards and > > > > lift TIF_NOTIFY_RESUME along with it.. > > > > > > We can't. This can race with exit_task_work(). And this can break > > > fput(), the task can return to the userspace without __fput(). > > > > So we could put that spinlock back around cancel and run and leave add > > lockless. That'd solve my immediate problem but its not something I'm > > proud of. > > Which problem?
/me doing task_work_add() from under rq->lock..
> We can probably use bit_spin_lock() and avoid ->pi_lock.
tglx will kill us both for even thinking of bit-spinlocks.
> Of course, we can add the new lock into task_struct, but this is not nice.
If we can limit the lock to cancel/run I'm ok.
| |