linux-kernel - Re: [PATCH] x86: memtest: fix compile warning

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:	Thu, 11 Jun 2009 23:05:12 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Yinghai Lu <yhlu.kernel@...il.com>
cc:	Andreas Herrmann <andreas.herrmann3@....com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: memtest: fix compile warning

On Thu, 11 Jun 2009, Yinghai Lu wrote:
> On Thu, Jun 11, 2009 at 7:21 AM, Thomas Gleixner<tglx@...utronix.de> wrote:
> > On Thu, 11 Jun 2009, Andreas Herrmann wrote:
> > But the reserve_bad_mem() semantics are even more scary:
> >
> > - if you hit flaky memory, which gives you bad and good results here
> >   and there, you call reserve_bad_mem() totally unbound which is
> >   likely to overflow the early reservation space and panics the
> >   machine. You need to keep track of those events somehow (e.g. in a
> >   bitmap) so you can detect such problems and mark the whole affected
> >   region bad in one go.
>
> if one pass found bad, it is reserved.
> second pass will use find_e820_area_size() to get new range, so bad
> one will not be used.

No, that's not about passes. Assume that you have flaky memory which
works halfways. So that code runs through a full memory region from 0
to 0x1000000.

      0-FF	OK
      100-1ff	BAD
      200-21f	OK
      220-23f	BAD
      ....
So there is no find_e820_area_size() between those OK/BAD steps, but
every new BAD hit calls reserve_early() and you run out of space in
the reserve array.

> > - you call reserve_early() which calls __reserve_early(....,
> >   overrun_ok = 0) so if you do the default multi pattern scan and each
> >   run sees the same region of broken memory you will trigger the
> >   "Overlapping early reservations" panic in __reserve_early() when you
> >   reserve that region the second time. Why do you run the test twice
> >   when the first one failed already ? Also there is no need to do the
> >   wipeout run in that case, which will trigger it as well!
 
Ok, here applies the find_e820_area_size() thing. I missed that
because the code is so well documented and obvious.

> current problem in that: we could run out of res_reserve array.
> solution will be make res_reserve array dynamically.
>   when can not find slot, need use find_e820_area to get double sized,
> and copy the old to new one.
>   then free the old one.

This applies to the first problem, which can be avoided by clever
coding.

Thanks,

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