----- Original Message -----
> > $ git diff memory.c
> > diff --git a/memory.c b/memory.c
> > index 8cdab06..7161d9d 100644
> > --- a/memory.c
> > +++ b/memory.c
> > @@ -8722,6 +8722,11 @@ dump_vmap_area(struct meminfo *vi)
> > ld->list_head_offset = OFFSET(vmap_area_list);
> > ld->end = symbol_value("vmap_area_list");
> > cnt = do_list(ld);
> > + if (cnt < 0) {
> > + vi->retval = 0;
> > + FREEBUF(vmap_area_buf);
> > + return;
> > + }
> >
> > for (i = 0; i < cnt; i++) {
> > if (!(pc->curcmd_flags & HEADER_PRINTED) && (i
==
> > 0) &&
> >
> > --
>
> I was wondering how the search command would handle its call to
machdep->get_kvaddr_ranges()
> with the patch above -- which would return 0 as the vmalloc address range's
"end" address.
> But given your output above, apparently it seems to work around it.
>
> Thanks,
> Dave
>
>
As far as I could tell, the code properly checks for a non-zero
meminfo.retval before proceeding in all instances.
OK -- so I'll take your patch, but also add an additional vmap_area list
specific message to your patch so that the invalid list entry message
is not so cryptic as to what it's complaining about.
Thanks,
Dave