lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080428193323.GA14990@parisc-linux.org>
Date:	Mon, 28 Apr 2008 13:33:23 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Russ Anderson <rja@....com>
Cc:	linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>,
	Christoph Lameter <clameter@....com>
Subject: Re: [PATCH 0/2] ia64: Migrate data off physical pages with correctable errors

On Mon, Apr 28, 2008 at 02:22:52PM -0500, Russ Anderson wrote:
> 	There is always an issue of how agressive the code should be on
> 	migrating pages.  Should it migrate on the first correctable error,
> 	or wait for some threshold?  Reasonable people may disagree on the
> 	threshold and the "right" answer may be hardware specific.  The 
> 	decision making is confined to the cpe_migrate.c code.  It is
> 	currently set to migrate on the first correctable error.

I think the kernel code should do the migration ASAP.  But I think we
should have a list of 'bad' pages.  We could then have a badram driver
that userspace can talk to to find out which pages are bad, map those
pages into a badram process, do various tests on them, and return the
pages to the pool if they're determined to be 'good'.

I could also see badramd having a list of pages found to be bad
in previous boots and asking the badram driver to take them out of
circulation early in boot before they've been allocated.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ