On Wed, Dec 21, 2022 at 3:06 PM HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab@nec.com> wrote:
>
> On 2022/12/21 15:14, lijiang wrote:
> > Thank you for the comment, Kazu.
> >
> > On Wed, Dec 21, 2022 at 1:48 PM HAGIO KAZUHITO(萩尾　一仁)
> > <k-hagio-ab@nec.com> 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.
>
> OK.
>
> >
> >> 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?
>
> ah, your example already has it and mnt_sb, so I didn't put them in the
> error message.
>
> >>>>      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"
>            ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
>
> but printing it again may be better, and WARNING may be better
> in this case.  Please play around for good output and can I have
> an example output?
>