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: <20080304140604.GG32383@elte.hu>
Date:	Tue, 4 Mar 2008 15:06:04 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Rick van Rein <rick@...rein.org>
Cc:	devzero@....de, pavel@....cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

* Rick van Rein <rick@...rein.org> wrote:

> > 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.

feel free to extend the "excludemem=" mechanism to support the full 
range of "badram=" configuration methods. As long as you are able to 
feed it into an e820 table (which is not trivial at all), it's the right 
thing to do and it would be mainstream acceptable.

and i wouldnt mind the "badmem=" option either - because you already 
have users of that facility and it's intuitively named as well - as long 
as it's cleanly fed into the e820 space. I.e. it would all look and 
behave the same way towards users as the BadMem patch does - with a 
different internal approach.

	Ingo
--
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/