Messages in this thread | | | Date | Sun, 07 Jul 2002 16:23:31 -0700 | From | Dave Hansen <> | Subject | Re: BKL removal |
| |
Thunder from the hill wrote: > On Sun, 7 Jul 2002, Dave Hansen wrote: > >>Old Blue? 23 isn't _that_ old! > > Obviously, you never read that book about the IBM s/370 named > "Old Blue"...
Nope. I missed that one. Something like "The Little Mainfraime that could?"
>>BKL use isn't right or wrong -- it isn't a case of creating a deadlock >>or a race. I'm picking a relatively random function from "grep -r >>lock_kernel * | grep /usb/". I'll show what I think isn't optimal >>about it. >> >>"up" is a local variable. There is no point in protecting its >>allocation. If the goal is to protect data inside "up", there should >>probably be a subsystem-level lock for all "struct uhci_hcd"s or a >>lock contained inside of the structure itself. Is this the kind of >>example you're looking for? > > So the BKL isn't wrong here, but incorrectly used?
Not even incorrect, but badly used. But, this was probably another VFS push.
> Is it really okay to "lock the whole kernel" because of one struct file? > This brings us back to spinlocks...
Don't think of it as locking the kernel, that isn't really what it does anymore. You really need to think of it as a special spinlock.
> You're possibly right about this one. What did Greg K-H say?
Only time will tell...
-- Dave Hansen haveblue@us.ibm.com
- 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/
| |