Re: System call munmap returning with the following locks held: Giant

On Thu, Jan 19, 2006 at 04:09:40PM -0500, John Baldwin wrote:
> On Thursday 19 January 2006 15:38, Alan Cox wrote:
> > On Thu, Jan 19, 2006 at 11:14:24AM -0500, John Baldwin wrote:
> > [snip]
> >
> > > Are you really sure the object's type can change or does the caller of
> > > vm_object_deallocate() hold some sort of reference or what not that
> > > prevents the type from changing?
> >
> > My recollection is that the object does not change type until all of
> > the references have been drained and it is about to be freed by
> > vm_object_terminate().  At the point where the type check is being
> > performed, the caller should hold a reference on the object.  Thus,
> > the type should not be changing.
> >
> > That said, an unexpected type change still strikes me as the most
> > plausible cause.
> >
> > Is there a test that easily reproduces this problem?
> 
> Kris Kenneway has one involving NFS.  My first patch was bogus in that I 
> missed the magic with vm_object_vndeallocate(), so I think the only way Kris 
> was seeing it was by the race of the type changing.  I've sent him an updated 
> patch like the one in my previous message that used a restart loop to lock 
> Giant if it was needed.

I don't think I saw that patch.

Here's the latest panic, with your previous patch in place:

panic: Assertion vfslocked == 0 failed at ../../../vm/vm_object.c:546
cpuid = 1
KDB: enter: panic
[thread pid 5508 tid 100171 ]
Stopped at      kdb_enter+0x30: leave
db> wh
Tracing pid 5508 tid 100171 td 0xcbc92780
kdb_enter(c071d14a,1,c0718fc7,f7c83af8,cbc92780) at kdb_enter+0x30
panic(c0718fc7,c07345b9,c0734406,222,138) at panic+0x13f
vm_object_deallocate(cbc4a1e0,0,c0733b0e,89a,cbb92840) at vm_object_deallocate+0x457
vm_map_entry_delete(cbb92840,c972bcc0,2816c000,f7c83b88,c067d921) at vm_map_entry_delete+0x17e
vm_map_delete(cbb92840,2816b000,2816c000,f7c83c64,0) at vm_map_delete+0x1dd
vm_map_remove(cbb92840,2816b000,2816c000,4e7,f7c83bf0) at vm_map_remove+0x55
vm_mmap(cbb92840,f7c83c64,1000,3,7) at vm_mmap+0x16c
mmap(cbc92780,f7c83d04,20,43c,cbc92780) at mmap+0x375
syscall(3b,3b,3b,2804ebb6,bfbfe8a8) at syscall+0x2e9
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (198, FreeBSD ELF32, nosys), eip = 0x2813dd4b, esp = 0xbfbfe7ac, ebp = 0xbfbfe7e8 ---