Messages in this thread | | | Date | Mon, 19 Nov 2012 13:59:27 -0500 | From | Sasha Levin <> | Subject | Re: yama: lockdep warning on yama_ptracer_del |
| |
On 11/19/2012 11:23 AM, Kees Cook wrote: > On Sun, Nov 18, 2012 at 8:05 PM, Sasha Levin <levinsasha928@gmail.com> wrote: >> Hi Kees, >> >> On Thu, Oct 18, 2012 at 6:39 PM, Kees Cook <keescook@chromium.org> wrote: >>> On Wed, Oct 17, 2012 at 8:10 PM, Sasha Levin <sasha.levin@oracle.com> wrote: >>>> Hi all, >>>> >>>> I was fuzzing with trinity within a KVM tools guest (lkvm) on a linux-next kernel, and got the >>>> following dump which I believe to be noise due to how the timers work - but I'm not 100% sure. >>>> ... >>>> [ 954.674123] Possible interrupt unsafe locking scenario: >>>> [ 954.674123] >>>> [ 954.674123] CPU0 CPU1 >>>> [ 954.674123] ---- ---- >>>> [ 954.674123] lock(ptracer_relations_lock); >>>> [ 954.674123] local_irq_disable(); >>>> [ 954.674123] lock(&(&new_timer->it_lock)->rlock); >>>> [ 954.674123] lock(ptracer_relations_lock); >>>> [ 954.674123] <Interrupt> >>>> [ 954.674123] lock(&(&new_timer->it_lock)->rlock); >>>> [ 954.674123] >>>> [ 954.674123] *** DEADLOCK *** >>> >>> I've been wanting to get rid of the Yama ptracer_relations_lock >>> anyway, so maybe I should do that now just to avoid this case at all? >> >> I still see this one in -rc6, is there anything to get rid of it >> before the release? > > I'm not sure about changes to the timer locks, but I haven't been able > to get rid of the locking on Yama's task_free path. I did send a patch > to get rid of locking during a read, though: > > https://lkml.org/lkml/2012/11/13/808
Aw, alrighty. It didn't make it to -next yet though.
I'll add the patch to my tree and test with it.
Thanks, Sasha
| |