----- 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
