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
[email protected]
Hi,
On Sun, 7 Jul 2002, Dave Hansen wrote:
> Nope. I missed that one. Something like "The Little Mainfraime that
> could?"
It was "The Y2K bug - the last day" by some Marc.
> > So the BKL isn't wrong here, but incorrectly used?
>
> Not even incorrect, but badly used. But, this was probably another
> VFS push.
The most correct would be to lock the struct file in any way so it can't
be used while I eat it. But I guess that's efficient locking vs. space,
isn't it? What would happen if we had a locking field on every struct?!
> > 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.
We should rename it to something that actually tells you what it does.
BTW, when was lock_kernel()? It must be really old if it still locked the
whole kernel.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
commence Thunder from the hill quotation:
> We should rename it to something that actually tells you what it does.
> BTW, when was lock_kernel()? It must be really old if it still locked the
> whole kernel.
It was added during the 1.3 development phase. Dave's paper in the
OLS proceedings (that was yours, wasn't it?) covers it pretty nicely
(at least to my kernel-ignorant eyes).
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <[email protected]> | answers a prison for oneself.
\ |