lkml.org 
[lkml]   [2002]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.175 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site