sys/fs/nfsclient on RTEMS gets a bad seqid error with open

[Rick Macklem]

>On 31/12/20 10:04 am, Rick Macklem wrote:
>> Chris Johns wrote:
>>> Hello,
>>>
>>> I am porting the kernel's nfsclient file system to the RTEMS port of FreeBSD. I
>>> have ported across the FreeBSD file descriptors, VFS and NFS code. I have a
>>> custom pseudofs file system as my root file system and I can mount an NFSv4
>>> mount exported from a FreeBSD 12 box.
>>>
>>> When I open a file there are a some getattr RPC calls that are successful
>>> however the open call (PUTFH, OPEN, GETATTR) results in the server returning the
>>> bas seqid (10026) error code for the OPEN and I am not sure why this is
>>> happening. I suspect I am missing a step in the nfsclient set up.
>> Well, for NFSv4.0 Opens, there is a field in the open_owner called a "seqid',
>> which is used to serialize Open calls. If that "seqid" gets screwed up, you
>> get a "bad seqid" (10026) from the server and your mount is broken.
>
>There is only one open call being made and the seq id in the packet is 0. The
>server code seems to consider ownership when returning this error and this is an
>area I am not sure about. RTEMS simulates a process and does not have a normal
>user/group model.
Did you do a Setclientid, Setclientidconfirm to set up the clientid?

The first Open should be fine with seqid==0 and the reply will flag it
as "needs Openconfirm".
--> 10026 means the server thinks it has already seen the open_owner
string for that client.

I'd suggest to capture a packet trace of a mount from the FreeBSD client
and then look at it in wireshark, to see what should be happening.

>> A couple of possibilities:
>> - The FreeBSD client code depends on an exclusive lock on the vnode
>>    to serialize the Opens.
>
>There is only one open call active. This is something I can control.
If all your Opens are serialized, you can use a single open_owner for
everything. The open_owner string should always be the same to do
this.
The FreeBSD client can do this for NFSv4.1 by specifying "oneopenown"
as a mount option.

>>    --> If what you are doing doesn't serialize them, then that will be a
>>           problem.
>> - If the VOP_OPEN() generates an unexpected error (I just ran into this
>>   on FreeBSD head), then the client might not get things correct.
>>   --> The seqid is incremented for some errors, but not others.
>
>I am currently basing this work on the FreeBSD 12 branch we have. A master port
>is next.
>
> Btw, all this seqid stuff goes away when you use NFSv4.1 and there
> are NFSv4.1 only clients out there. You might want to consider doing
> this. If I was writing the code now, there would be no NFSv4.0.
>
>Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked into
>this but I could not figure out how.
minorversion=1 mount option, which sets nm_minorvers to 1.

rick

> rick
> ps: Getting this seqid stuff right was about the hardest part of
>     implementing NFSv4.0 and it could still be buggy.

Hmm yes it seems a little tricky.

Thanks
Chris