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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ