On 17 Jun, Alfred Perlstein wrote:
> * Don Lewis <[EMAIL PROTECTED]> [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:
I like simple fixes, especially when the code shrinks ;-)
Unfortunately, I think your point about this only happening because this
process is the last holder of the file means that this doesn't explain
Peter's deadlock.
> 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
> @@ -2003,6 +2003,7 @@
> FILE_UNLOCK(fp);
> return (0);
> }
> + FILE_UNLOCK(fp);
> mtx_lock(&Giant);
> if (fp->f_count < 0)
> panic("fdrop: count < 0");
> @@ -2012,10 +2013,8 @@
> 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);
> else
>
>
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
