From: Jeff Dike <jdike@addtoit.com>
To: John Reiser <jreiser@BitWagon.com>
Cc: valgrind-developers@lists.sourceforge.net,
user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] running UserModeLinux under Valgrind(memcheck)
Date: Mon, 31 Dec 2007 21:00:09 -0500 [thread overview]
Message-ID: <20080101020009.GB19579@c2.user-mode-linux.org> (raw)
In-Reply-To: <4773F11D.7060803@BitWagon.com>
On Thu, Dec 27, 2007 at 10:38:21AM -0800, John Reiser wrote:
> Patches have been developed which enable UserModeLinux for i686 to
> run under the memcheck tool of Valgrind on i686. Thus it is possible
> to check dynamically the memory accesses made by a running Linux kernel
> against memcheck's model of allowed behavior. This work was supported
> by Google Inc.
>
> The goods:
Nice!
Did you find anything needing fixing besides the ubd and random
drivers reading uninitialized stuff and the random bytes that UML uses
to communicate with itself being uninitialized?
I did a quick scan of the UML patch, and didn't see any unexpected
fixes there.
> On the UML side, there is a significant technical issue: the semantics
> of kmalloc+kfree do not match the semantics of malloc+free. The kernel
> slab allocator caches and re-issues identified objects, which accumulate
> state and retain it throughout execution, including from kfree to kmalloc.
> In contrast, a region that is passed to free() loses both its contents
> and its identity. Also, size is an important parameter to malloc,
> but is implicit to kmalloc. The initial patches finesse these issues
> (for instance: by supplying the size as trailing parameter to kmalloc,
> and by noticing that SLAB_POISON ==> free()), but there will be
> significant discussion and work in resolving the differences.
Any problem with supporting these sorts of allocation models in
valgrind? Not all the world is malloc and free (although maybe 99%
is).
Can we pass the allocation size through a valgrind annotation rather
than add the parameter to kmem_cache_alloc?
Jeff
--
Work email - jdike at linux dot intel dot com
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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-01-01 2:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-27 18:38 [uml-devel] running UserModeLinux under Valgrind(memcheck) John Reiser
2007-12-27 19:55 ` [uml-devel] [Valgrind-developers] " Michael Abshoff
2008-01-01 2:00 ` Jeff Dike [this message]
2008-01-01 21:24 ` [uml-devel] " John Reiser
2008-01-02 15:28 ` Jeff Dike
2008-01-02 22:42 ` John Reiser
2008-01-03 5:18 ` Jeff Dike
2008-01-03 16:08 ` Geert Uytterhoeven
2008-01-04 16:37 ` Jeff Dike
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=20080101020009.GB19579@c2.user-mode-linux.org \
--to=jdike@addtoit.com \
--cc=jreiser@BitWagon.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=valgrind-developers@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