Date: Tue, 1 Feb 2005 19:11:07 -0800 From: Kris Kennaway <kris@obsecurity.org> To: Kris Kennaway <kris@obsecurity.org> Cc: current@freebsd.org Subject: Re: Panic: Memory modified after free Message-ID: <20050202031107.GA67234@xor.obsecurity.org> In-Reply-To: <20050202023033.GA53440@xor.obsecurity.org> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> <20050202001230.GA21847@xor.obsecurity.org> <20050202011157.GA55803@technokratis.com> <20050202023033.GA53440@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 06:30:33PM -0800, Kris Kennaway wrote: > On Tue, Feb 01, 2005 at 08:11:57PM -0500, Bosko Milekic wrote: > >=20 > > I made the attached patch for scottl to allow for > PAGE_SIZE > > allocations, please feel free to try it as I don't think he has had a > > chance to yet. >=20 > I had to apply part of the patch by hand, and increase > MAX_PAGES_PER_ITEM to 128 to deal with M_INODEDEP allocations (well, > it was asking for at least 64 pages worth, so this may have been a > factor of 2 overkill). I don't know if this is correct - it seems > like a lot of memory to be allocating since all of the allocations I > could see seem to be for only a single copy of struct inodedep, which > is nowhere near that big. >=20 > Anyway, it panicked shortly after starting to exercise the FS, with: >=20 > login: panic: mutex not owned at ../../../vm/vm_page.c:301 > cpuid =3D 1 > KDB: enter: panic > [thread pid 717 tid 100147 ] > Stopped at kdb_enter+0x30: leave > db> tr > Tracing pid 717 tid 100147 td 0xc7f27a10 > kdb_enter(c06fbf7a,1,c06fb4a2,eeca0968,c7f27a10) at kdb_enter+0x30 > panic(c06fb4a2,c82cb120,c071204f,12d,c46bae28) at panic+0x13e =46rom another copy of the same panic: panic(c06fb4a2,c81a9c10,c071204f,12d,c46b8a28) at panic+0x13e > 0xc81a9c00: c81a9c10 c5acb000 deadc0de c073a160 > 0xc81a9c10: 0 c62df000 deadc0de c073c560 > 0xc81a9c20: c82cc110 c5acf000 deadc0de c073a160 > 0xc81a9c30: deadc0de deadc0de deadc0de c073c560 > 0xc81a9c40: deadc0de deadc0de deadc0de c073a160 It looks like the vm object has been freed? Kris > _mtx_assert(c07c4ac0,1,c071204f,12d,ffffffe2) at _mtx_assert+0x7c > vm_page_busy(c46bae28,0,c0710c9d,155,eeca0a2c) at vm_page_busy+0x2d > vm_fault(c1059000,c566a000,2,0,c7f27a10) at vm_fault+0x6c3 > trap_pfault(eeca0b04,0,c566a008,eeca0af4,c566a008) at trap_pfault+0x166 > trap(c0510018,c07c0010,10,c81c0800,c563638c) at trap+0x34c > calltrap() at calltrap+0x5 > --- trap 0xc, eip =3D 0xc063af4a, esp =3D 0xeeca0b44, ebp =3D 0xeeca0b60 = --- > inodedep_lookup(c81c0800,180803,1,eeca0b78,0) at inodedep_lookup+0x143 > softdep_change_linkcnt(c8c99000,e0ccd600,4600,eeca0b9c,eeca0ba0) at softd= ep_change_linkcnt+0x4f > ufs_dirremove(c8b0b4e0,c8c99000,100800c,0,0) at ufs_dirremove+0x153 > ufs_remove(eeca0c2c,c071c05e,2ac,c071c662,c8b0b4e0) at ufs_remove+0x60 > VOP_REMOVE_AP(eeca0c2c,eeca0c28,2,c06fdcb8,c81b7400) at VOP_REMOVE_AP+0x78 > kern_unlink(c7f27a10,80636a8,0,eeca0d40,c06b9eb6) at kern_unlink+0x186 > unlink(c7f27a10,eeca0d14,3a6,c07184c4,c7f27a10) at unlink+0x22 > syscall(2f,804002f,bfbf002f,1,804d000) at syscall+0x2c4 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (10, FreeBSD ELF32, unlink), eip =3D 0x280c5b63, esp =3D 0xbf= bfec2c, ebp =3D 0xbfbfec58 --- >=20 > I don't know if this is a memguard bug or a FreeBSD bug. >=20 > Kris --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAETLWry0BWjoQKURAjqIAKCVGyo7QriPvIUrj3a/OOK+y3j/jgCfdDaz 2vEVW/lm91ET9bAAD5l+ZCU= =oVBE -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050202031107.GA67234>