System call munmap returning with the following locks
held: Giant
John Baldwin
jhb at freebsd.org
Fri Jan 20 13:05:37 PST 2006
On Thursday 19 January 2006 19:52, Kris Kennaway wrote:
> 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.
Ah, it's at the same place. http://www.freebsd.org/~jhb/patches/vm_obj.patch
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current
mailing list