Re: [Xen-devel] [PATCH] [PVOPS] fix gntdev on PAE

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 1 Jun 2010, Jeremy Fitzhardinge wrote:
> On 06/01/2010 02:38 AM, Stefano Stabellini wrote:
> > On Fri, 28 May 2010, Jeremy Fitzhardinge wrote:
> >   
> >> I managed to catch a lockdep problem in gntdev, which may be the same as
> >> before:
> >>
> >> BUG: sleeping function called from invalid context at kernel/rwsem.c:21
> >> in_atomic(): 1, irqs_disabled(): 0, pid: 4091, name: qemu-dm
> >> 2 locks held by qemu-dm/4091:
> >>  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff810bb50f>] 
> >> sys_munmap+0x33/0x58
> >>  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff810cd63a>] 
> >> __mmu_notifier_invalidate_range_start+0x0/0xc7
> >> Pid: 4091, comm: qemu-dm Not tainted 2.6.32.13 #23
> >> Call Trace:
> >>  [<ffffffff8106705b>] ? __debug_show_held_locks+0x22/0x24
> >>  [<ffffffff81039522>] __might_sleep+0x123/0x127
> >>  [<ffffffff810a8536>] ? release_pages+0xd2/0x1e7
> >>  [<ffffffff81498849>] down_read+0x1f/0x57
> >>  [<ffffffff81010142>] ? check_events+0x12/0x20
> >>  [<ffffffff810a8536>] ? release_pages+0xd2/0x1e7
> >>  [<ffffffff810cd63a>] ? __mmu_notifier_invalidate_range_start+0x0/0xc7
> >>  [<ffffffff8123e069>] mn_invl_range_start+0x32/0x118
> >>  [<ffffffff810cd69c>] __mmu_notifier_invalidate_range_start+0x62/0xc7
> >>  [<ffffffff810cd63a>] ? __mmu_notifier_invalidate_range_start+0x0/0xc7
> >>  [<ffffffff810b54bc>] unmap_vmas+0x8c/0x91a
> >>  [<ffffffff810ba363>] unmap_region+0xda/0x178
> >>  [<ffffffff810bb472>] do_munmap+0x2ae/0x318
> >>  [<ffffffff810bb51d>] sys_munmap+0x41/0x58
> >>  [<ffffffff81013b82>] system_call_fastpath+0x16/0x1b
> >>
> >>
> >> The problem is that mn_invl_range_start does a down_read(), but it is
> >> called from __mmu_notifier_invalidate_range_start(), which does an
> >> rcu_read_lock, which has the side-effect of disabling preemption.
> >>
> >> The mmu notifier code seems to have always used rcu_read_lock this way,
> >> so I guess this bug has always been there.  It's not immediately obvious
> >> how to fix it.
> >>
> >> Thoughts?
> >>     
> > What about turning the semaphore into a rwlock?
> > Performances shouldn't matter in this case.
> > Something like this:
> >   
> 
> The problem is that the rcu lock disables preemption, so anything inside
> it must be non-scheduling.  So it would need to be a spinlock type
> thing, I think.

right, in fact rwlock is a rw spinlock if I am not mistaken


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel