Message-ID: <3E0336AF.6060607@BitWagon.com>
Date: Fri, 20 Dec 2002 07:26:39 -0800
From: John Reiser <jreiser@BitWagon.com>
Organization: -
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
MIME-Version: 1.0
To: Jeff Dike <jdike@karaya.com>
CC: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
       Julian Seward <jseward@acm.org>
Subject: Re: Valgrind meets UML
References: <200212200241.VAA04202@ccure.karaya.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1468
Lines: 29

Jeff Dike wrote:
> I would also appreciate suggestions on what sort of memory access state table
> to implement, and where best to put the declarations.  What I'm not clear
> on is what sort of access a buffer should have when it's in the care of
> the allocator (i.e. it's free).  If the allocator sticks information 
> temporarily in the buffer, then that needs to be stated.

Probably there will be some benefits, at least for a while, if valgrind for UML
"knows" the kernel allocators like valgrind for applications "knows" malloc+free.
Implementors of allocators can have bugs in the valgrind declarations they add.
An "independent" check based on documented externally-visible behavior can help.

Nested allocators (inner allocator grabs a large region, outer allocator performs
sub-allocations of small pieces from the large region) can be troublesome.

Implementing a four-state status {-, W, RW, RO} might be much more work,
because some accounting schemes are oriented naturally towards only three states
{-, W, RW}.  Also, there are contenders for two additional states: watchpoints
for READ and WRITE, such as "any read of a back-pointer of this doubly-linked
list", etc.

-- 
John Reiser, jreiser@BitWagon.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/