From: Steve VanDeBogart <vandebo-lkml@NerdBox.Net>
To: Pekka Enberg <penberg@cs.helsinki.fi>
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 08:42:49 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.1.00.0809030833050.15543@abydos.NerdBox.Net> (raw)
In-Reply-To: <84144f020809030227jce7d3c2wab9e9c00b2fcdfe5@mail.gmail.com>
Hello Pekka,
On Wed, 3 Sep 2008, Pekka Enberg wrote:
> 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).
But which bits of a slab object should be marked as initialized at
kmem_cache_alloc() time? We can't mark all of them as initialized
because the constructor may not initialize all of them (in fact, I've
programmatically confirmed that there are constructors that don't
initialize all the bytes of an object). The only place to get the
information of interest is to mark all bytes uninitialized and then
run the constructor on the memory region.
>
> 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.
This question has the same answer as above.
--
Steve
-------------------------------------------------------------------------
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 15:42 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
2008-09-03 9:40 ` Pekka Enberg
2008-09-03 15:42 ` Steve VanDeBogart [this message]
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=alpine.DEB.1.00.0809030833050.15543@abydos.NerdBox.Net \
--to=vandebo-lkml@nerdbox.net \
--cc=dkegel@google.com \
--cc=jiayingz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@us.ibm.com \
--cc=penberg@cs.helsinki.fi \
--cc=user-mode-linux-devel@lists.sourceforge.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