Re: BKL removal

[Dave Hansen]

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
[e-mail]