----- Original Message -----
----- Original Message -----
> ----- Original Message -----
> >
> > I'll take a look at these when I get the chance, but I'm really
> > not particularly excited unless they are actual bugs.
>
> Like this one:
>
> --- a/memory.c
> +++ b/memory.c
> @@ -17003,8 +17003,8 @@ valid_section(ulong addr)
>
> if ((mem_section = read_mem_section(addr)))
> return (ULONG(mem_section +
> - OFFSET(mem_section_section_mem_map)) &&
> - SECTION_MARKED_PRESENT);
> + OFFSET(mem_section_section_mem_map))
> + & SECTION_MARKED_PRESENT);
> return 0;
> }
>
> @@ -17016,7 +17016,7 @@ section_has_mem_map(ulong addr)
> if ((mem_section = read_mem_section(addr)))
> return (ULONG(mem_section +
> OFFSET(mem_section_section_mem_map))
> - && SECTION_HAS_MEM_MAP);
> + & SECTION_HAS_MEM_MAP);
> return 0;
> }
>
> This code has been like this since the original CONFIG_SPARSEMEM support
> patch was posted back in 2006. Interesting that this has never been a
> problem. Apparently nobody's ever bumped into mem_section that didn't
> have those flags.
Interestingly enough, this patch breaks RHEL5 and earlier kernels.
(try "kmem -n" with and without the patch). Probably a flag issue with
earlier CONFIG_SPARSEMEM kernels.
Dave
OK, mystery solved. Prior to 2.6.24, the SECTION_HAS_MEM_MAP bit existed,
but it was never set/used in the mem_section.section_mem_map combination
pointer/bitmask. So when run against the early kernels, the patched version
of section_has_mem_map() above would fail because only the SECTION_MARKED_PRESENT
bit was ever set.
However, for all practical purposes, if a mem_section exists, it is valid, so
even without the patch, things have always worked just fine with the coding
error in place.
Regardless, I fixed the patch to be based upon the kernel version, and queued
it for crash-7.1.2:
https://github.com/crash-utility/crash/commit/e81db08bc69fb1a7a7e48f892c2...
Dave