On Thu, 2012-02-09 at 11:06 -0500, Dave Anderson wrote:
> But your patch does this:
>
> @@ -8117,8 +8135,9 @@ kmem_cache_s_array_nodes:
> "array cache array", RETURN_ON_ERROR))
> goto bail_out;
>
> - for (i = max_limit = 0; (i < ARRAY_LENGTH(kmem_cache_s_array)) &&
> - cpudata[i]; i++) {
> + for (i = max_limit = 0; (i < kmem_cache_nr_cpu)
> + && (i < ARRAY_LENGTH(kmem_cache_s_array))
> + && cpudata[i]; i++) {
> if (!readmem(cpudata[i]+OFFSET(array_cache_limit),
> KVADDR, &limit, sizeof(int),
> "array cache limit", RETURN_ON_ERROR))
>
> On "old" slab systems, your new "kmem_cache_nr_cpu" variable remains at
> its initialized value of zero, and the loop never gets entered. So I don't
> think you wanted to keep the (i < kmem_cache_nr_cpu) there, right?
Of course you're right, sorry about that. I originally tried to fix the
problem by putting (i < kt->cpus) there before I fixed the array length,
then substituted instead of removing that clause.
>
> > 2) kmem_cache structs can be allocated near enough to the edge of a page
> > that the old incorrect length crosses the page boundary, even though the
> > real smaller structure fits in the page. That caused a readmem of the
> > structure to cross into a coincidentally missing page in the dump.
>
> Right -- that was the genesis of the kmem_cache_downsize() function.
>
> > This patch fixes both of those (after wrestling ARRAY_LENGTH to the
> > ground), but *does not* fix the similar page crossing problem when I try
> > to use a "struct kmem_cache" command on the particular structure at the
> > end of the page.
>
> Yeah, damn, I don't know what can be done for that, aside from some
> horrific kludge to gdb_readmem_callback() to return successfully even
> if the readmem() failed.
At least you won't see the problem on startup, only if you accidentally
ask for that particular struct.
Bob M.
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
