Date: Thu, 19 Jan 2006 19:52:06 -0500 From: Kris Kennaway <kris@obsecurity.org> To: John Baldwin <jhb@freebsd.org> Cc: alc@freebsd.org, Suleiman Souhlal <ssouhlal@freebsd.org>, freebsd-current@freebsd.org, Alan Cox <alc@cs.rice.edu>, Kris Kennaway <kris@obsecurity.org> Subject: Re: System call munmap returning with the following locks held: Giant Message-ID: <20060120005206.GA3062@xor.obsecurity.org> In-Reply-To: <200601191609.43529.jhb@freebsd.org> References: <20060118070549.GA617@xor.obsecurity.org> <200601191114.27075.jhb@freebsd.org> <20060119203833.GC7599@cs.rice.edu> <200601191609.43529.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? >=20 > Kris Kenneway has one involving NFS. My first patch was bogus in that I= =20 > missed the magic with vm_object_vndeallocate(), so I think the only way K= ris=20 > was seeing it was by the race of the type changing. I've sent him an upd= ated=20 > patch like the one in my previous message that used a restart loop to loc= k=20 > 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 =3D=3D 0 failed at ../../../vm/vm_object.c:546 cpuid =3D 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_dealloc= ate+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 =3D 0x2813dd4b, esp =3D 0xbfbf= e7ac, ebp =3D 0xbfbfe7e8 --- --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD0DQ2Wry0BWjoQKURAm8bAKDvQDCcTtdeeZnVgXPFOThBVpjf7wCg8HAx 3WdLd5hrv1svPgGKiEzUmis= =mmwk -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060120005206.GA3062>