All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.