On Wed, 3 Jul 2002, Dave Hansen wrote:
> I saw your talk about driverfs at OLS and it got my attention. When
> my BKL debugging patch showed some use of the BKL in driverfs, I was
> very dissapointed (you can blame Greg if you want).
I'm sorry to hear about your distress. Hopefully you've had a chance to
talk to someone about it and calm down a bit.
> text from dmesg after BKL debugging patch:
> release of recursive BKL hold, depth: 1
> [ 0]main:492
> [ 1]inode:149
>
> I see no reason to hold the BKL in your situation. I replaced it with
> i_sem in some places and just plain removed it in others. I believe
> that you get all of the protection that you need from dcache_lock in
> the dentry insert and activate. Can you prove me wrong?
No, and I'm not about to try very hard. It appears that the place you
removed it should be fine. In driverfs_unlink, you replace it with i_sem.
ramfs, which driverfs mimmicks, doesn't hold any lock during unlink. It
seems it could be removed altogether.
The other replacement happens in _lseek. That looks fine, though I
think that entire function can be replaced with one of the generic lseek
functions...
Patch applied. Thanks,
-pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:15 EST