From owner-cvs-src  Mon Mar 17 13:22:21 2003
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 283FA37B401; Mon, 17 Mar 2003 13:22:19 -0800 (PST)
Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4800443FAF; Mon, 17 Mar 2003 13:22:17 -0800 (PST)
	(envelope-from jroberson@chesapeake.net)
Received: from localhost (jroberson@localhost)
	by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h2HLM6Y51911;
	Mon, 17 Mar 2003 16:22:06 -0500 (EST)
	(envelope-from jroberson@chesapeake.net)
Date: Mon, 17 Mar 2003 16:22:05 -0500 (EST)
From: Jeff Roberson <jroberson@chesapeake.net>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Kirk McKusick <mckusick@McKusick.COM>, <dwmalone@FreeBSD.org>,
	El Vampiro <vampiro@rootshell.ru>,
	"Evgueni V. Gavrilov" <aquatique@rusunix.org>,
	Mike Makonnen <mtm@identd.net>, <src-committers@FreeBSD.org>,
	<cvs-src@FreeBSD.org>, <cvs-all@FreeBSD.org>
Subject: Re: kern/42277 
In-Reply-To: <49957.1047935677@critter.freebsd.dk>
Message-ID: <20030317162051.R66343-100000@mail.chesapeake.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-src@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-src.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-src>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-src>
X-Loop: FreeBSD.ORG

On Mon, 17 Mar 2003, Poul-Henning Kamp wrote:

> In message <200303171909.h2HJ9PFL013291@beastie.mckusick.com>, Kirk McKusick wr
> ites:
> >I had hoped that the above patch would solve the problem, but
> >alas it did not (though that fix should be MFC'ed into -stable
> >as it is a valid fix). Further investigation with the help of
> >Evgueni V. Gavrilov has determined that there is a memory
> >corruption problem in the 128-byte bucket space. Applying the
> >patch below makes the soft updates panics stop. It does so by
> >creating an "unused" field in the inodedep structure at the
> >64-byte offset. The printf showing that the "unused" field has
> >changed does occur, but at least soft updates continues to work.
>
> Kirk,
>
> How easy is this to reproduce ?
>
> The simple way to nail the culprint would be to move things out of
> the 128 bucket by adding to their malloc byte counts, but for such
> a strategy to work, we obviously need to be able to reproduce it
> fairly consistently.

UMA has a facility to track the previous owner of the memory.  Assuming
that is the problem I could give you a way to cache this information so we
can print it out when we detect corruption.  I can work on this tonight.
What is the repro?

Cheers,
Jeff


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-src" in the body of the message