Date: Mon, 28 Jul 2003 14:53:12 -0700 From: Kris Kennaway <kris@obsecurity.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: Another LOR with filedesc structure and Giant Message-ID: <20030728215312.GA89925@rot13.obsecurity.org> In-Reply-To: <Pine.NEB.3.96L.1030728110437.57321A-100000@fledge.watson.org> References: <20030727233351.GB80934@rot13.obsecurity.org> <Pine.NEB.3.96L.1030728110437.57321A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote:
>=20
> On Sun, 27 Jul 2003, Kris Kennaway wrote:
>=20
> > After upgrading last night, one of the package machines found this:
>=20
> I've bumped into some similar problems -- it's a property of how we
> current lock select(). We hold the file descriptor lock for the duration
> of polling each object being "selected", and if any of those objects has
> to grab a lock for any reason, it has to implicitly fall after the file
> descriptor lock. I actually run into this in some of our MAC code,
> because I need to grab a vnode lock to authorize polling the vnode using
> VOP_POLL(), and since the vnode lock is a sleep lock, this generates a
> WITNESS warning. Unfortunately, it's not immediately clear what a better
> locking scheme would look like without going overboard on the fine-grained
> side. We probably need to grab Giant before entering the select code
> since it's highly likely something in there will require Giant -- it
> reaches down into VFS, the device stuff, socket code, tc.
Also
lock order reversal
1st 0xc6a69634 filedesc structure (filedesc structure) @ /a/asami/portbuil=
d/i386/src-client/sys/kern/sys_generic.c:1071
2nd 0xc04aa120 Giant (Giant) @ /a/asami/portbuild/i386/src-client/sys/fs/s=
pecfs/spec_vnops.c:372
Stack backtrace:
backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17
witness_lock(c04aa120,8,c0434e3d,174,246) at witness_lock+0x672
_mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba
spec_poll(d8dfcb44,d8dfcb64,c02d119c,d8dfcb44,c04939a0) at spec_poll+0x134
spec_vnoperate(d8dfcb44,c04939a0,c52cfa44,41,c6cfd280) at spec_vnoperate+0x=
18
vn_poll(c45dc880,41,c6cfd280,c5f7a4c0,c6cfd280) at vn_poll+0x3c
pollscan(c5f7a4c0,d8dfcbd4,2,3e7,10) at pollscan+0xb0
poll(c5f7a4c0,d8dfcd10,c0455899,3ee,3) at poll+0x252
syscall(2f,2f,2f,0,2) at syscall+0x273
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (209), eip =3D 0x281c4934, esp =3D 0xbfbfeee4, ebp =3D 0xbfbfef=
20 ---
Debugger("witness_lock")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db>
Kris
--liOOAslEiF7prFVr
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/JZtIWry0BWjoQKURAnQbAJ9qZ80mnAhT9KQbKyE8T5U5QKYYRgCfVMQ9
EmJdTFP2+AqDmIe1R6vk+Dk=
=LbJW
-----END PGP SIGNATURE-----
--liOOAslEiF7prFVr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030728215312.GA89925>