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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
