On 2022/12/21 18:09, 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"
>
> 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 with a warning, if this is an invalid
> kernel virtual address, that can avoid truncating the remaining mount
> dumps.
>
> Reported-by: Dave Wysochanski <dwysocha@xxxxxxxxxx>
> Signed-off-by: Lianbo Jiang <lijiang@xxxxxxxxxx>
> ---
> filesys.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/filesys.c b/filesys.c
> index c2ea78de821d..d64b54a9b822 100644
> --- a/filesys.c
> +++ b/filesys.c
> @@ -1491,6 +1491,10 @@ show_mounts(ulong one_vfsmount, int flags, struct task_context *namespace_contex
> }
>
> sbp = ULONG(vfsmount_buf + OFFSET(vfsmount_mnt_sb));
> + if (!IS_KVADDR(sbp)) {
> + error(WARNING, "cannot get super_block from vfsmnt: 0x%lx\n", *vfsmnt);
> + continue;
> + }
>
> if (flags)
> fprintf(fp, "%s", mount_hdr);
Thanks, applied with a few tweaks in the commit log.
https://github.com/crash-utility/crash/commit/88a4910d95d43a01151ad1d570035b96893bc7f1
Thanks,
Kazu
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
