All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Dave Hansen <haveblue@us.ibm.com>, Josh Aas <josha@sgi.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	steiner@sgi.com
Subject: Re: bkl cleanup in do_sysctl
Date: Tue, 10 Aug 2004 12:46:02 -0700	[thread overview]
Message-ID: <411925FA.2000303@namesys.com> (raw)
In-Reply-To: <1092163919.782.54.camel@mindpipe>

Lee Revell wrote:

>On Tue, 2004-08-10 at 13:28, Dave Hansen wrote:
>
>  
>
>>Remember that the BKL isn't a plain-old spinlock.  You're allowed to
>>sleep while holding it and it can be recursively held, which isn't true
>>for other spinlocks.
>>
>>So, if you want to replace it with a spinlock, you'll need to do audits
>>looking for sysctl users that might_sleep() or get called recursively
>>somehow.  The might_sleep() debugging checks should help immensely for
>>the first part, but all you'll get are deadlocks at runtime for any
>>recursive holders.  But, those cases are increasingly rare, so you might
>>luck out and not have any.  
>>
>>Or, you could just make it a semaphore and forget about the no sleeping
>>requirement.  
>>
>>    
>>
>
>Someone once suggested that newbies who show up on LKML wanting to learn
>kernel hacking should be assigned to find one use of the BKL and replace
>it with proper locking.  Something similar worked very well with my
>previous employer, before giving someone root, new hires would first be
>assigned some task like writing a script to take the user account
>database and generate a report of old accounts on a bunch of machines,
>or rewrite the RADIUS accounting scripts, where the point was really to
>get them familiar with the system.
>
>This way, even if they come back with a totally botched fix, someone
>will probably just post a correct one.  We could get rid of the BKL very
>soon, I count only 247 files with lock_kernel in them.
>
>For example reiserfs uses the BKL for all write locking (!), but it
>probably would not be too hard to fix, because you can just look at
>another filesystem that has proper locking.
>  
>
Wrong. ;-)  Balancing makes it way hard.  Use reiser4.  That has very 
sophisticated locking that pushes the research envelope, if you want to 
read code to learn about locking.....

>Maybe this should be added to the FAQ:
>
>Q:  I want to hack the kernel, and I *think* I know what I am doing. 
>Where do I start?
>
>Lee
>
>-
>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/
>
>
>  
>


  parent reply	other threads:[~2004-08-10 19:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-10 16:58 bkl cleanup in do_sysctl Josh Aas
2004-08-10 17:28 ` Dave Hansen
2004-08-10 18:51   ` Lee Revell
2004-08-10 19:16     ` Roland Dreier
2004-08-10 19:21       ` Lee Revell
2004-08-10 19:46     ` Hans Reiser [this message]
2004-08-10 20:10       ` Lee Revell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=411925FA.2000303@namesys.com \
    --to=reiser@namesys.com \
    --cc=haveblue@us.ibm.com \
    --cc=josha@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    --cc=steiner@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.