lkml.org 
[lkml]   [2002]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: BKL removal
Date
>  > The BKL, unless used unbalanced, can never cause a bug. It could be
> > insufficient or superfluous, but never be really buggy in itself.
>
> Does incredibly high lock contention qualify as a bug?

Only if it occurs at a place that is used often. Even then it's
a minor bug, while a race is always a race.

> >> 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?
> >
> > I don't speak for Greg, but in this example it could be dropped
> > IMO. The spinlock protects the critical section anyway. As a rule,
> > if you do a kmalloc without GFP_ATOMIC under BKL you are doing
> > either insufficient locking (you may need a semaphore) or useless
> > locking.
>
> Don't forget that the BKL is released on sleep. It is OK to hold it

Exactly therefore it won't protect you from reentrance if you do
something that sleeps. If that's the case, you've found a race condition.

> over a schedule()able operation. If I remember right, there is no
> real protection needed for the file->private_data either because there
> is 1 and only 1 struct file per open, and the data is not shared among
> struct files.

But between threads. Anyway, this was an open, if you use struct file
before open returns even the BKL can't help you.

> > This should have been posted on linux-usb long ago.
>
> I just pulled it out of thin air 10 minutes ago!

Yes, I understand. But this is a symptom. We should have heard
about it.
You need to understand that people who run UP mostly won't
care about SMP beyond making sure that the drivers are SMP-safe.
This is not true for core kernel code, but for devices outside
the block layer and perhaps some network drivers, that's the case.

So you do the greps and question locking usage on the right lists.
It's quite important, you might uncover bugs and speed up the kernel.
And you need to be persistent about it. Take your time to find out why
the lock is used. Or why it makes no sense.
You should be able to improve the locking situation that way, with respect
to BKL contention and driver quality.

Regards
Oliver

-
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.105 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site