Hi,
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"...
> 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?
Is it really okay to "lock the whole kernel" because of one struct file?
This brings us back to spinlocks...
You're possibly right about this one. What did Greg K-H say?
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------- 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:18 EST