From: Yinghai Lu <yhlu.kernel@gmail•com>
To: Thomas Gleixner <tglx@linutronix•de>
Cc: Andreas Herrmann <andreas.herrmann3@amd•com>,
Stephen Rothwell <sfr@canb•auug.org.au>,
Ingo Molnar <mingo@elte•hu>, "H. Peter Anvin" <hpa@zytor•com>,
Peter Zijlstra <peterz@infradead•org>,
linux-next@vger•kernel.org, linux-kernel@vger•kernel.org
Subject: Re: [PATCH] x86: memtest: fix compile warning
Date: Thu, 11 Jun 2009 10:19:28 -0700 [thread overview]
Message-ID: <86802c440906111019o5829933fnfffcea5cd0e3c862@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0906111512400.3372@localhost.localdomain>
On Thu, Jun 11, 2009 at 7:21 AM, Thomas Gleixner<tglx@linutronix•de> wrote:
> On Thu, 11 Jun 2009, Andreas Herrmann wrote:
>
>> Commit c9690998ef48ffefeccb91c70a7739eebdea57f9
>> (x86: memtest: remove 64-bit division) introduced following compile warning:
>>
>> arch/x86/mm/memtest.c: In function 'memtest':
>> arch/x86/mm/memtest.c:56: warning: comparison of distinct pointer types lacks a cast
>> arch/x86/mm/memtest.c:58: warning: comparison of distinct pointer types lacks a cast
>>
>> Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd•com>
>> ---
>> arch/x86/mm/memtest.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> Sorry.
>> Please apply.
>
> I applied it already, but zapped it right away, as it is bad style to
> do the type casting in the loops. The proper fix is below.
>
> But aside of that this code is confusing.
>
> start_phys_aligned = ALIGN(start_phys, incr);
>
> Why do we have to fiddle with the alignment. Are you really seing e820
> entries which are not 8 byte aligned ?
>
> for (p = start; p < end; p++, start_phys_aligned += incr) {
> if (*p == pattern)
> continue;
> if (start_phys_aligned == last_bad + incr) {
> last_bad += incr;
> continue;
> }
> if (start_bad)
> reserve_bad_mem(pattern, start_bad, last_bad + incr);
> start_bad = last_bad = start_phys_aligned;
> }
> if (start_bad)
> reserve_bad_mem(pattern, start_bad, last_bad + incr);
>
> I really had to look more than once to understand what the heck
> start_phys_aligned and last_bad + incr are doing. Really non
> intuitive.
>
> 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.
>
> - 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!
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.
YH
next prev parent reply other threads:[~2009-06-11 17:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-11 1:27 linux-next: origin tree build warning Stephen Rothwell
2009-06-11 10:29 ` [PATCH] x86: memtest: fix compile warning Andreas Herrmann
2009-06-11 14:21 ` Thomas Gleixner
2009-06-11 14:30 ` H. Peter Anvin
2009-06-11 15:26 ` Andreas Herrmann
2009-06-12 13:11 ` Andreas Herrmann
2009-06-11 17:19 ` Yinghai Lu [this message]
2009-06-11 21:05 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86802c440906111019o5829933fnfffcea5cd0e3c862@mail.gmail.com \
--to=yhlu.kernel@gmail$(echo .)com \
--cc=andreas.herrmann3@amd$(echo .)com \
--cc=hpa@zytor$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=peterz@infradead$(echo .)org \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=tglx@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox