linux-um archives
 help / color / mirror / Atom feed
From: "Pekka Enberg" <penberg@cs.helsinki.fi>
To: Steve VanDeBogart <vandebo-lkml@nerdbox.net>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@us.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	dkegel@google.com, jiayingz@google.com
Subject: Re: [uml-devel] [PATCH 5/6] slab: Annotate slab
Date: Wed, 3 Sep 2008 12:27:12 +0300	[thread overview]
Message-ID: <84144f020809030227jce7d3c2wab9e9c00b2fcdfe5@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0809022036560.15543@abydos.NerdBox.Net>

Hi Steve,

On Wed, Sep 3, 2008 at 8:08 AM, Steve VanDeBogart
<vandebo-lkml@nerdbox.net> wrote:
> Thank you for pointing out the location of the kmemcheck code.  I looked
> around briefly but didn't find the latest version.  It does seem that
> kmemcheck and Valgrind annotations want to live in the same places so it
> makes perfect sense to combine them where possible.  I'm not exactly sure
> what you find so ugly about the Valgrind annotations, please elaborate.

Upper case macros and littering #ifdefs in the code. See the kmemcheck
hooks how to do it in a clean way.

On Wed, Sep 3, 2008 at 8:08 AM, Steve VanDeBogart
<vandebo-lkml@nerdbox.net> wrote:
> It is true that code above the allocator should not be touching free'd
> slab objects.  However, it is also true that objects from slabs that
> have a constructor should retain their per byte un/initialized state
> through allocation and free cycles (just the semantic of slabs with
> constructors AFAICT).

Sorry for being unclear, sure, object should be marked as initialized
when they're returned from kmem_cache_alloc(). However, what I
disagree with is *where* you're marking them as initialized. Surely
they're not semantically initialized when the slabs are allocated
(although technically they are).

On Wed, Sep 3, 2008 at 8:08 AM, Steve VanDeBogart
<vandebo-lkml@nerdbox.net> wrote:
> Ideally, we'd tell Valgrind that the bytes of a free'd slab object are
> no longer accessible, but the initialized state should remain the same
> until the object is made accessible again by the next allocation of
> the object.  Unfortunately, the compression method for A & V bits in
> Valgrind doesn't allow a region to be inaccessible and retain validness
> bits.

I don't see why you should mark them initialized all the time. Just
mark them as uninitialized on kmem_cache_free() and again as
initialized when they're about to be returned from kmem_cache_alloc()
like we do in kmemcheck.

                              Pekka

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2008-09-03  9:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-29 23:12 [uml-devel] [PATCH 0/6] support valgrinding uml Steve VanDeBogart
2008-08-29 23:14 ` [uml-devel] [PATCH 1/6] base: Valgrind headers and Kconfig Steve VanDeBogart
2008-09-01  9:32   ` Andi Kleen
2008-09-01 14:06     ` Jeff Dike
2008-09-01 14:22       ` Andi Kleen
2008-09-01 15:47         ` Jeff Dike
2008-08-29 23:15 ` [uml-devel] [PATCH 2/6] UML: Don't valgrind userspace Steve VanDeBogart
2008-09-05 16:37   ` Jeff Dike
2008-09-06 20:55     ` John Reiser
2008-09-06 22:12       ` Jeff Dike
2008-08-29 23:16 ` [uml-devel] [PATCH 3/6] UML and sched: Annotate stacks Steve VanDeBogart
2008-08-29 23:16 ` [uml-devel] [PATCH 4/6] VM: Annotate pagealloc Steve VanDeBogart
2008-08-30 10:57   ` Pekka Enberg
2008-09-03  5:25     ` Steve VanDeBogart
2008-09-03  9:35       ` Pekka Enberg
2008-08-29 23:17 ` [uml-devel] [PATCH 5/6] slab: Annotate slab Steve VanDeBogart
2008-08-30 10:50   ` Pekka Enberg
2008-09-03  2:54     ` John Reiser
2008-09-03  9:39       ` Pekka J Enberg
2008-09-03  5:08     ` Steve VanDeBogart
2008-09-03  9:27       ` Pekka Enberg [this message]
2008-09-03  9:40         ` Pekka Enberg
2008-09-03 15:42         ` Steve VanDeBogart
2008-09-04  7:33           ` Pekka Enberg
2008-08-29 23:18 ` [uml-devel] [PATCH 6/6] VM: Annotate vmalloc Steve VanDeBogart

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=84144f020809030227jce7d3c2wab9e9c00b2fcdfe5@mail.gmail.com \
    --to=penberg@cs.helsinki.fi \
    --cc=dkegel@google.com \
    --cc=jiayingz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@us.ibm.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=vandebo-lkml@nerdbox.net \
    /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