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

HAGIO KAZUHITO(萩尾 一仁) k-hagio-ab at nec.com
Wed Dec 21 05:22:24 UTC 2022


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?

Thanks,
Kazu

> 
> The kernel virtual address of the super_block is zero when the mount
> command fails at the address 0xffff97b484753420. And the remaining
> dumping information will be discarded. That is not expected.
> 
> Check the address and skip it, if this is an invalid kernel virtual
> address, that can avoid truncating the remaining mount dumps.
> 
> Reported-by: Dave Wysochanski <dwysocha at redhat.com>
> Signed-off-by: Lianbo Jiang <lijiang at redhat.com>
> ---
>   filesys.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/filesys.c b/filesys.c
> index c2ea78de821d..8c2d4e316208 100644
> --- a/filesys.c
> +++ b/filesys.c
> @@ -1491,6 +1491,8 @@ show_mounts(ulong one_vfsmount, int flags, struct task_context *namespace_contex
>   		}
>   
>   		sbp = ULONG(vfsmount_buf + OFFSET(vfsmount_mnt_sb));
> +		if (!IS_KVADDR(sbp))
> +			continue;
>   
>   		if (flags)
>   			fprintf(fp, "%s", mount_hdr);


More information about the Crash-utility mailing list