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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you for the comment, Kazu.

On Wed, Dec 21, 2022 at 1:48 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab@xxxxxxx> 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?

Thanks.
Lianbo

> +                       continue;
> +               }
> +
>                   readmem(sbp, KVADDR, super_block_buf, SIZE(super_block),
>                           "super_block buffer", FAULT_ON_ERROR);
>                  type = ULONG(super_block_buf + OFFSET(super_block_s_type));
>
> Thanks,
> Kazu
>
> >
> > 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@xxxxxxxxxx>
> >> Signed-off-by: Lianbo Jiang <lijiang@xxxxxxxxxx>
> >> ---
> >>    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);
> > --
> > Crash-utility mailing list
> > Crash-utility@xxxxxxxxxx
> > https://listman.redhat.com/mailman/listinfo/crash-utility
> > Contribution Guidelines: https://github.com/crash-utility/crash/wiki

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux