linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: John Bradford <john@grabjohn.com>
Cc: davem@redhat.com, miller@techsource.com, anton@samba.org,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	lm@bitmover.com, mbligh@aracnet.com, phillips@arcor.de,
	piggin@cyberone.com.au
Subject: Re: Lock EVERYTHING (for testing) [was: Re: Scaling noise]
Date: Thu, 11 Sep 2003 09:37:46 -0700	[thread overview]
Message-ID: <1063298266.4412.41.camel@ixodes.goop.org> (raw)
In-Reply-To: <200309101547.h8AFl4Sl002463@81-2-122-30.bradfords.org.uk>

On Wed, 2003-09-10 at 08:47, John Bradford wrote:
> > The analogy for Linux is this:  At a machine level, we add a check to 
> > EVERY access.  The check is there to ensure that every memory access is 
> > properly locked.  So, if some access is made where there isn't a proper 
> > lock applied, then we can print a warning with the line number or drop 
> > out into kdb or something of that sort.
> >
> > I'm betting there's another solution to this, otherwise, I wouldn't 
> > suggest such an idea, because of the relative amount of work versus 
> > benefit.  But it may require massive modifications to GCC to add this 
> > code in at the machine level.
> 
> Couldn't Valgrind be modified to do this for the kernel?
> 
> http://developer.kde.org/~sewardj/

I have a UML-under-Valgrind project on the backburner.  Valgrind has an
instrumentation mode which checks to see every memory access is covered
by appropriate locks in an MT program.  I'm afraid it will generate a
lot of noise in the kernel though, since there's a lot of code which
does unlocked memory access (probably correctly).

	J


  reply	other threads:[~2003-09-11 16:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-10 15:47 Lock EVERYTHING (for testing) [was: Re: Scaling noise] John Bradford
2003-09-11 16:37 ` Jeremy Fitzhardinge [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-09-03  4:03 Scaling noise Larry McVoy
2003-09-03 15:50 ` Martin J. Bligh
2003-09-04  0:49   ` Larry McVoy
2003-09-04  2:21     ` Daniel Phillips
2003-09-04  2:46       ` Larry McVoy
2003-09-04  4:58         ` David S. Miller
2003-09-10 15:47           ` Lock EVERYTHING (for testing) [was: Re: Scaling noise] Timothy Miller

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=1063298266.4412.41.camel@ixodes.goop.org \
    --to=jeremy@goop.org \
    --cc=anton@samba.org \
    --cc=davem@redhat.com \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm@bitmover.com \
    --cc=mbligh@aracnet.com \
    --cc=miller@techsource.com \
    --cc=phillips@arcor.de \
    --cc=piggin@cyberone.com.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).