Hi all,
Today's linux-next build (x86_64 allmodconfig) produced this 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
Introduced by commit c9690998ef48ffefeccb91c70a7739eebdea57f9 ("x86:
memtest: remove 64-bit division").
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
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 <[email protected]>
---
arch/x86/mm/memtest.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Sorry.
Please apply.
Thanks,
Andreas
diff --git a/arch/x86/mm/memtest.c b/arch/x86/mm/memtest.c
index c0bedcd..1a8b48f 100644
--- a/arch/x86/mm/memtest.c
+++ b/arch/x86/mm/memtest.c
@@ -53,9 +53,9 @@ static void __init memtest(u64 pattern, u64 start_phys, u64 size)
start_bad = 0;
last_bad = 0;
- for (p = start; p < end; p++)
+ for (p = start; (void *) p < end; p++)
*p = pattern;
- for (p = start; p < end; p++, start_phys_aligned += incr) {
+ for (p = start; (void *) p < end; p++, start_phys_aligned += incr) {
if (*p == pattern)
continue;
if (start_phys_aligned == last_bad + incr) {
--
1.6.3.1
Commit-ID: 47e64f3c8430d0410c8e83f3e503532491c863c3
Gitweb: http://git.kernel.org/tip/47e64f3c8430d0410c8e83f3e503532491c863c3
Author: Andreas Herrmann <[email protected]>
AuthorDate: Thu, 11 Jun 2009 12:29:27 +0200
Committer: Thomas Gleixner <[email protected]>
CommitDate: Thu, 11 Jun 2009 13:53:02 +0200
x86: memtest: add proper typecast for pointer comparison
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 <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
---
arch/x86/mm/memtest.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/memtest.c b/arch/x86/mm/memtest.c
index c0bedcd..1a8b48f 100644
--- a/arch/x86/mm/memtest.c
+++ b/arch/x86/mm/memtest.c
@@ -53,9 +53,9 @@ static void __init memtest(u64 pattern, u64 start_phys, u64 size)
start_bad = 0;
last_bad = 0;
- for (p = start; p < end; p++)
+ for (p = start; (void *) p < end; p++)
*p = pattern;
- for (p = start; p < end; p++, start_phys_aligned += incr) {
+ for (p = start; (void *) p < end; p++, start_phys_aligned += incr) {
if (*p == pattern)
continue;
if (start_phys_aligned == last_bad + incr) {
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 <[email protected]>
> ---
> 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.
- 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!
So in both cases you panic the machine w/o need.
Please fix ASAP.
Thanks,
tglx
---
diff --git a/arch/x86/mm/memtest.c b/arch/x86/mm/memtest.c
index d1c5cef..18d244f 100644
--- a/arch/x86/mm/memtest.c
+++ b/arch/x86/mm/memtest.c
@@ -40,16 +40,14 @@ static void __init reserve_bad_mem(u64 pattern, u64 start_bad, u64 end_bad)
static void __init memtest(u64 pattern, u64 start_phys, u64 size)
{
- u64 *p, *end;
- void *start;
+ u64 *p, *start, *end;
u64 start_bad, last_bad;
u64 start_phys_aligned;
- size_t incr;
+ const size_t incr = sizeof(pattern);
- incr = sizeof(pattern);
start_phys_aligned = ALIGN(start_phys, incr);
start = __va(start_phys_aligned);
- end = (u64 *) (start + size - (start_phys_aligned - start_phys));
+ end = start + (size - (start_phys_aligned - start_phys)) / incr;
start_bad = 0;
last_bad = 0;
On Thu, Jun 11, 2009 at 04:21:41PM +0200, Thomas Gleixner 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 <[email protected]>
> > ---
> > 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.
Doesn't your fix re-introduces the 64-bit division problem with old
gcc? I removed that division with the mentioned commit just forgot to
type-cast the pointer.
> 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 ?
CC-ing Yinghai who might know more about this.
See also http://marc.info/?l=linux-kernel&m=123490434528131
> 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.
Agreed, needs to be fixed.
> - 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!
Sure, needs to be fixed as well.
(Note: I think both problems exist in the memtest code right from the beginning.)
> So in both cases you panic the machine w/o need.
>
> Please fix ASAP.
> Thanks,
>
> tglx
> ---
> diff --git a/arch/x86/mm/memtest.c b/arch/x86/mm/memtest.c
> index d1c5cef..18d244f 100644
> --- a/arch/x86/mm/memtest.c
> +++ b/arch/x86/mm/memtest.c
> @@ -40,16 +40,14 @@ static void __init reserve_bad_mem(u64 pattern, u64 start_bad, u64 end_bad)
>
> static void __init memtest(u64 pattern, u64 start_phys, u64 size)
> {
> - u64 *p, *end;
> - void *start;
> + u64 *p, *start, *end;
> u64 start_bad, last_bad;
> u64 start_phys_aligned;
> - size_t incr;
> + const size_t incr = sizeof(pattern);
>
> - incr = sizeof(pattern);
> start_phys_aligned = ALIGN(start_phys, incr);
> start = __va(start_phys_aligned);
> - end = (u64 *) (start + size - (start_phys_aligned - start_phys));
> + end = start + (size - (start_phys_aligned - start_phys)) / incr;
> start_bad = 0;
> last_bad = 0;
>
Regards,
Andreas
On Thu, Jun 11, 2009 at 7:21 AM, Thomas Gleixner<[email protected]> 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 <[email protected]>
>> ---
>> ?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
Thomas Gleixner wrote:
>
> 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 ?
>
I have personally seen those on real systems.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Thu, 11 Jun 2009, Yinghai Lu wrote:
> On Thu, Jun 11, 2009 at 7:21 AM, Thomas Gleixner<[email protected]> 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
On Thu, Jun 11, 2009 at 05:26:58PM +0200, Andreas Herrmann wrote:
> On Thu, Jun 11, 2009 at 04:21:41PM +0200, Thomas Gleixner 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 <[email protected]>
> > > ---
> > > 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.
>
> Doesn't your fix re-introduces the 64-bit division problem with old
> gcc? I removed that division with the mentioned commit just forgot to
> type-cast the pointer.
It doesn't.
> > diff --git a/arch/x86/mm/memtest.c b/arch/x86/mm/memtest.c
> > index d1c5cef..18d244f 100644
> > --- a/arch/x86/mm/memtest.c
> > +++ b/arch/x86/mm/memtest.c
> > @@ -40,16 +40,14 @@ static void __init reserve_bad_mem(u64 pattern, u64 start_bad, u64 end_bad)
> >
> > static void __init memtest(u64 pattern, u64 start_phys, u64 size)
> > {
> > - u64 *p, *end;
> > - void *start;
> > + u64 *p, *start, *end;
> > u64 start_bad, last_bad;
> > u64 start_phys_aligned;
> > - size_t incr;
> > + const size_t incr = sizeof(pattern);
The const qualifier made the difference.
Thanks,
Andreas