Re: -current tar(1) breakage

[RVP <rvp%SDF.ORG@localhost>]

On Thu, 1 Apr 2021, Christos Zoulas wrote:

> RVP  <rvp%SDF.ORG@localhost> wrote:
> > Indeed. Bug #56083 is caused by the wrong function being called:
> >
> > diff -u /usr/src/sys/fs/puffs/puffs_vfsops.c{.orig,}
> > --- /usr/src/sys/fs/puffs/puffs_vfsops.c.orig   2020-02-27
> > 22:12:53.000000000 +0000
> > +++ /usr/src/sys/fs/puffs/puffs_vfsops.c        2021-03-30
> > 12:02:35.402544154 +0000
> > @@ -503,7 +503,7 @@
> >          */
> >         copy_statvfs_info(sbp, mp);
> >         if (!error) {
> > -               statvfs_to_puffs_statvfs(sbp, &statvfs_msg->pvfsr_sb);
> > +               puffs_statvfs_to_statvfs(&statvfs_msg->pvfsr_sb, sbp);
> >         }
>
> This is not exactly right either, I fixed it.

Yes. What I did above is wrong. copy_statvfs_info() should come after
puffs_statvfs_to_statvfs(). Otherwise, you end up with a mount with
empty to and from names--yeesh.

But, there is a problem here, though: copy_statvfs_info() overrides
the FUSE-supplied f_namemax (EXT2_NAME_LEN = 255):

$ ./a.out /mnt/work/dmesg.txt 
svfs.f_frsize: 4096
svfs.f_iosize: 512
svfs.f_bsize: 4096
svfs.f_namemax: 511     <-- not EXT2_NAME_LEN

> > The statvfs-filling sequence starting at line 219 doesn't look right
> > either:
> >
> >     219         struct statvfs *sb = STATVFSBUF_GET();
> >     220         puffs_statvfs_to_statvfs(&args->pa_svfsb, sb);
> >     221         copy_statvfs_info(sb, mp);
> >     222         STATVFSBUF_PUT(sb);
> >     223
> >     224         statvfs_to_puffs_statvfs(&mp->mnt_stat, &args->pa_svfsb);
>
> Why?

Well, because, it seems to me, that the values copied into `sb'
are just discarded. This confused me when I saw it first because
the puffs statvfs copy functions reverse the usual convention of
having a (dest, src) argument order--they have (src, dest).
copy_statvfs_info() has it the usual way.

> The question is where does NFS return a 0 namelen...

No idea--didn't look too deeply into this. Are you able to
reproduce this issue?

-RVP