On Wed, 04 Feb 2015 18:24:06 -0500 Sasha Levin <[email protected]> wrote:
> Hi all, > > I was fuzzing with trinity on a -next kernel with the KASan patchset, and > got what initially appeared to be a rather odd trace: > > ... > > > I now have a theory for why it happens: > > Thread A Thread B > ---------------------------------------------------------- > > [Enter function] > DECLARE_COMPLETION_ONSTACK(x) > wait_for_completion(x) > complete(x) > [In complete(x):] > spin_lock_irqsave(&x->wait.lock, flags); > x->done++; > __wake_up_locked(&x->wait, TASK_NORMAL, > 1); > [Done waiting, wakes up] > [Exit function] > spin_unlock_irqrestore(&x->wait.lock, > flags); > > > > So the spin_unlock_irqrestore() at the end of complete() would proceed to > corruption > the stack of thread A. But wait_for_completion() takes ->wait.lock as well, which should provide the needed synchronization (__wait_for_common, do_wait_for_common). I'm not seeing a hole in the logic, but it looks like there might be one. -- 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/
