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

[Dave Anderson]

----- Original Message -----
> 
> 
> ----- Original Message -----
> > Hello Dave,
> > 
> > New kernel has moved some elements of struct vfsmount to a new struct
> > mount. So crash will not act normally on new kernel. The patch is used
> > to fix the problem.
> > 
> > Please check.
> 
> Hi Qiao,
> 
> This patch-set is very much appreciated.  I saw Al Viro's original LKML patch
> posted back in December (?), and had been waiting to see an actual kernel with
> it in place.  The most recent in-house RHEL/Fedora test kernels I have on-hand
> are all 3.2.x-era kernels, which don't have the patch, so I'm presuming you're
> running on a 3.3.x kernel?
> 
> Anyway, I'll check this patch out for backwards-compatibility and try to
> get a more recent kernel to test with.  It looks good on paper...
> 
> And again, thanks for taking on this task.
> 
> Dave

I provisioned a system with a Fedora 3.3.0-0.rc6.git2.1.fc17 kernel, which
has the vfsmount->mount patch.  The session comes up cleanly, but the 
following commands fail:

  crash> mount
  ... [ cut ] ...
         mount: invalid structure member offset: vfsmount_mnt_list
  ...

  crash> files
  ... [cut] ...
         files: invalid structure member offset: dentry_d_covers
  ...

The "fuser" command generates the above error because it uses the
"files" command behind the scenes.

  crash> vm
  ... [cut] ...
  vm: invalid structure member offset: dentry_d_covers
  ...

  crash> swap
  ... [cut] ...
  swap: invalid structure member offset: dentry_d_covers
  ...

With your patch applied, "mount", "files", "fuser" and "vm" all
work OK.  

But "swap" now fails in a different manner:

  crash> swap
  FILENAME           TYPE         SIZE      USED   PCT  PRIORITY
  swap: invalid kernel virtual address: 1d8ec8  type: "fill_dentry_cache"
  crash>

It's failing in its call to get_pathname().  I haven't had a chance to
fully check into why it's getting a bogus parent dentry address
while walking through the swap file's "/dev/mapper/vg_dellpec610002-lv_swap"
pathname -- and I won't be able to until next week.  But presumably it's
related, and so if you (or anybody) gets a chance this weekend, please 
take a look.
  
Thanks,
  Dave