Date: Fri, 1 Jan 2021 01:09:18 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Chris Johns <chrisj@rtems.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: sys/fs/nfsclient on RTEMS gets a bad seqid error with open Message-ID: <YQXPR0101MB096874499E40F220D359B919DDD50@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
>On 31/12/20 10:04 am, Rick Macklem wrote:=0A= >> Chris Johns wrote:=0A= >>> Hello,=0A= >>>=0A= >>> I am porting the kernel's nfsclient file system to the RTEMS port of Fr= eeBSD. I=0A= >>> have ported across the FreeBSD file descriptors, VFS and NFS code. I ha= ve a=0A= >>> custom pseudofs file system as my root file system and I can mount an N= FSv4=0A= >>> mount exported from a FreeBSD 12 box.=0A= >>>=0A= >>> When I open a file there are a some getattr RPC calls that are successf= ul=0A= >>> however the open call (PUTFH, OPEN, GETATTR) results in the server retu= rning the=0A= >>> bas seqid (10026) error code for the OPEN and I am not sure why this is= =0A= >>> happening. I suspect I am missing a step in the nfsclient set up.=0A= >> Well, for NFSv4.0 Opens, there is a field in the open_owner called a "se= qid',=0A= >> which is used to serialize Open calls. If that "seqid" gets screwed up, = you=0A= >> get a "bad seqid" (10026) from the server and your mount is broken.=0A= >=0A= >There is only one open call being made and the seq id in the packet is 0. = The=0A= >server code seems to consider ownership when returning this error and this= is an=0A= >area I am not sure about. RTEMS simulates a process and does not have a no= rmal=0A= >user/group model.=0A= Did you do a Setclientid, Setclientidconfirm to set up the clientid?=0A= =0A= The first Open should be fine with seqid=3D=3D0 and the reply will flag it= =0A= as "needs Openconfirm".=0A= --> 10026 means the server thinks it has already seen the open_owner=0A= string for that client.=0A= =0A= I'd suggest to capture a packet trace of a mount from the FreeBSD client=0A= and then look at it in wireshark, to see what should be happening.=0A= =0A= >> A couple of possibilities:=0A= >> - The FreeBSD client code depends on an exclusive lock on the vnode=0A= >> to serialize the Opens.=0A= >=0A= >There is only one open call active. This is something I can control.=0A= If all your Opens are serialized, you can use a single open_owner for=0A= everything. The open_owner string should always be the same to do=0A= this.=0A= The FreeBSD client can do this for NFSv4.1 by specifying "oneopenown"=0A= as a mount option.=0A= =0A= >> --> If what you are doing doesn't serialize them, then that will be a= =0A= >> problem.=0A= >> - If the VOP_OPEN() generates an unexpected error (I just ran into this= =0A= >> on FreeBSD head), then the client might not get things correct.=0A= >> --> The seqid is incremented for some errors, but not others.=0A= >=0A= >I am currently basing this work on the FreeBSD 12 branch we have. A master= port=0A= >is next.=0A= >=0A= > Btw, all this seqid stuff goes away when you use NFSv4.1 and there=0A= > are NFSv4.1 only clients out there. You might want to consider doing=0A= > this. If I was writing the code now, there would be no NFSv4.0.=0A= >=0A= >Ah OK. How do I make the FreeBSD nfsclient operate as NFSv4.1? I looked in= to=0A= >this but I could not figure out how.=0A= minorversion=3D1 mount option, which sets nm_minorvers to 1.=0A= =0A= rick=0A= =0A= > rick=0A= > ps: Getting this seqid stuff right was about the hardest part of=0A= > implementing NFSv4.0 and it could still be buggy.=0A= =0A= Hmm yes it seems a little tricky.=0A= =0A= Thanks=0A= Chris=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB096874499E40F220D359B919DDD50>