Re: [Crash-utility] [PATCH] Fix mount command to appropriately display the mount dumps

Thank you for the comment, Kazu. On Wed, Dec 21, 2022 at 1:48 PM HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt; wrote: > > On 2022/12/21 14:22, HAGIO KAZUHITO(萩尾 一仁) wrote: >> On 2022/12/20 12:16, Lianbo Jiang wrote: >>> Recently the following failure has been observed on some vmcores when >>> using the mount command: >>> >>> crash> mount >>> MOUNT SUPERBLK TYPE DEVNAME DIRNAME >>> ffff97a4818a3480 ffff979500013800 rootfs none / >>> ffff97e4846ca700 ffff97e484653000 sysfs sysfs /sys >>> ... >>> ffff97b484753420 0 mount: invalid kernel virtual address: 0 type: "super_block buffer" >> >> Thank you for the fix. >> >> Just out of curiosity, do you see why the vfsmount.mnt_sb is zero? >> That panic occurred during mounting or unmounting? > I didn't reproduce this issue, but I got several vmcores from customers and did the debugging. Maybe the super block has been released, but the data has not been completely synced. I guess.

> I think, it might be more helpful to print the MOUNT and SUPERBLK values > in the list even if it's zero or invalid, rather than skip it completely. > What do you think? e.g. continue here: > Sounds good. > @@ -1500,6 +1500,11 @@ show_mounts(ulong one_vfsmount, int flags, struct task_context *namespace_contex > mkstring(buf2, VADDR_PRLEN, RJUST|LONG_HEX, > MKSTR(sbp))); > > + if (!IS_KVADDR(sbp)) { > + error(INFO, "cannot get super_block\n"); + error(INFO, "cannot get super_block from vfsmnt: 0x%lx\n", *vfsmnt); If we would like to print the information, also try to output the vfs mount address, looks better?

>>> crash> mount >>> MOUNT SUPERBLK TYPE DEVNAME DIRNAME >>> ffff97a4818a3480 ffff979500013800 rootfs none / >>> ffff97e4846ca700 ffff97e484653000 sysfs sysfs /sys >>> ... >>> ffff97b484753420 0 mount: invalid kernel virtual address: 0 type: "super_block buffer"