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
next prev parent 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