linux-um archives
 help / color / mirror / Atom feed
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

  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