linux-kernel - Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

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: <20080304134322.GA19237@phantom.vanrein.org>
Date:	Tue, 4 Mar 2008 13:43:22 +0000
From:	Rick van Rein <rick@...rein.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	devzero@....de, pavel@....cz, linux-kernel@...r.kernel.org,
	rick@...rein.org
Subject: Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

Ingo,

> as i said it in another reply to this thread, it would be perfectly 
> acceptable for upstream to merge an easier to use boot option - be that 
> badmem=addr$size or excludemem=addr$size.

I'm not sure if that is an optimal replacement of BadRAM at all.

Broken memories usually manifest themselves as a column or row in a DIMM
that stopped working.  So there is a pattern in the memory that is to be
excluded, and I'm not wholly sure that combines well with the excludemem
mechanism.  (I will look into it to be sure.)  I hope to know after the
weekend if the patterns that I am talking about can be turned into to a
cosmetic boot option.

I've also read that people on this list say that it is a waste to throw
out a full page if only 5 bytes (say) are actually faulty.  Although it
is certainly interesting from an academic viewpoint to avoid this, it has
never, ever led to complaints.  I've been advertising the possibility of
using the pages for allocation slabs, and allow all slabs except for those
with an error contained, but nobody has ever taken that seriously.

> Please send a patch :-)

I've been reluctant to quickly mend things because it could lead to
unstable code.  The patch that I am presenting is mature code, with the
possible exception of the somewhat newer 64-bit code.  If this list has
a preference for less mature code that is hardly field-tested, I could
of course tailor to that.

Cheers,

Rick van Rein
--
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/