> On Apr 1, 2021, at 7:56 PM, RVP <rvp%SDF.ORG@localhost> wrote:
>
> 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):
Yes, puffs is special... Let me think what's the best way to fix that.
>
> $ ./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.
Yes, when I wrote them I was debating about the order of the arguments:
follow the function name order or destination first...
>> 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?
>
I am trying to follow the steps you described. I don't see the unmount
and remount though...
christos
Attachment:
signature.asc
Description: Message signed with OpenPGP