[Crash-utility] [PATCH] fix command vm/files -d/mount on new kernel

[Dave Anderson]

----- Original Message -----
> At 2012-3-13 11:45, qiaonuohan wrote:
> > At 2012-3-13 3:27, Dave Anderson wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> At 2012-3-10 5:50, Dave Anderson wrote:
> >>>>
> >>>> It's failing in its call to get_pathname(). I haven't had a chance to
> >>>
> >>> You are right. I forgot to check every call to get_pathname. The new
> >>> patch has fixed the problem of swap.
> >>
> >> Although the patch appears to work in the simple cases that I have tested,
> >> I have a few issues with it.
> >>
> >> First, the get_pathname() function prototype is -- and has always been -- this:
> >>
> >>  void get_pathname(ulong dentry, char *pathname, int length, int full, ulong vfsmnt)
> >>
> >> where the "vfsmnt" argument has always been a struct vfsmount pointer.
> >> 
> >> With your patch, prior to making get_pathname() calls, you typically
> >> make a VALID_STRUCT(mount) call first, and if true, you modify the
> >> vfsmnt argument to be a struct mount pointer.
> >>
> >> It would make more sense maintenance-wise, and would simplify the patch,
> >> if the get_pathname() "vfsmnt" argument would continue to be a struct
> >> vfsmount pointer. And at the top of get_pathname(), you could make the
> >> adjustments for when it is embedded inside a struct mount.

... [ cut ] ...

> >> If we can continue to have get_pathname() receive a vfsmount pointer,
> >> it reduces the chance of introducing new bugs like the above, and future
> >> maintenance will be easier.
> >
> > It does reduce complication of the code. Still, places needing the
> > judgement of struct mount's existing remain. I will modify the patch,
> > and post later.
> >
> > About the function, OFFSET_OPTION(), thanks for your advice.
> >
> 
> The attachment is the modified patch.

I have reviewed and tested this patch, and it looks to be both complete
and simpler to maintain.  Queued for crash-6.0.5.

Thanks again for undertaking this task,
  Dave