* Don Lewis <truckman_at_FreeBSD.org> [030617 12:00] wrote: > It's not legal to attempt to aquire Giant in fdrop_locked(), while > FILE_LOCK() is held. The problem is that FILE_LOCK uses the mutex pool, > which should only be used for leaf mutexes. > > It also looks like there is a potential for a lock order reversal if > some callers aquire Giant before FILE_LOCK() and fdrop_locked() does the > opposite. > > It also appears that witness ignores the mutex pool ... Yes, but I think the fix is as simple as just dropping the FILE_LOCK after the decrement as we're the last holders of it, can you try this: Index: kern_descrip.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.199 diff -u -r1.199 kern_descrip.c --- kern_descrip.c 11 Jun 2003 00:56:55 -0000 1.199 +++ kern_descrip.c 17 Jun 2003 19:07:01 -0000 _at__at_ -2003,6 +2003,7 _at__at_ FILE_UNLOCK(fp); return (0); } + FILE_UNLOCK(fp); mtx_lock(&Giant); if (fp->f_count < 0) panic("fdrop: count < 0"); _at__at_ -2012,10 +2013,8 _at__at_ lf.l_len = 0; lf.l_type = F_UNLCK; vp = fp->f_data; - FILE_UNLOCK(fp); (void) VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &lf, F_FLOCK); - } else - FILE_UNLOCK(fp); + } if (fp->f_ops != &badfileops) error = fo_close(fp, td); elseReceived on Tue Jun 17 2003 - 10:07:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:12 UTC