Re: Another LOR with filedesc structure and Giant

On Mon, Jul 28, 2003 at 02:53:12PM -0700, Kris Kennaway wrote:
> On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote:
> > 
> > On Sun, 27 Jul 2003, Kris Kennaway wrote:
> > 
> > > After upgrading last night, one of the package machines found this:
> > 
> > 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) _at_ /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1071
>  2nd 0xc04aa120 Giant (Giant) _at_ /a/asami/portbuild/i386/src-client/sys/fs/specfs/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+0x18
> 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

#8  0xc0290ed7 in witness_lock (lock=0xc04aa120, flags=8,
    file=0xc0434e3d "/a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c", line=372)
    at /a/asami/portbuild/i386/src-client/sys/kern/subr_witness.c:838
#9  0xc0261f4a in _mtx_lock_flags (m=0x0, opts=0, file=0xc04d1818 "", line=-1068850912)
    at /a/asami/portbuild/i386/src-client/sys/kern/kern_mutex.c:334
#10 0xc0231154 in spec_poll (ap=0xd8dfcb44)
    at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
#11 0xc0230648 in spec_vnoperate (ap=0x0)
    at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:122
#12 0xc02d119c in vn_poll (fp=0x0, events=0, active_cred=0xc6cfd280, td=0x0) at vnode_if.h:537
#13 0xc0294c50 in pollscan (td=0xc5f7a4c0, fds=0xd8dfcbdc, nfd=2)
    at /a/asami/portbuild/i386/src-client/sys/sys/file.h:272
#14 0xc02948a2 in poll (td=0xc5f7a4c0, uap=0xd8dfcd10)
    at /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:1001
#15 0xc03ef9b3 in syscall (frame=
      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 2, tf_ebp = -1077940448, tf_isp = -656421516, tf_ebx = 673224876, tf_edx = 139153408, tf_ecx = 137314336, tf_eax = 209, tf_trapno = 0, tf_err = 2, tf_eip = 672942388, tf_cs = 31, tf_eflags = 659, tf_esp = -1077940508, tf_ss = 47})
    at /a/asami/portbuild/i386/src-client/sys/i386/i386/trap.c:1008
#16 0xc03dfbed in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---

Kris