Alright, looking through some git blame -w, I think this broke and then was restored in 2912fad98e. Jim had a diff in 2014 (823625c5da) to make the code compile, but crucially the buffer code no longer had a “max len” just a length. I think this broke the “clever” reuse of the input buffdesc as the argument to GetFH (which has been there since 2012 from 878f45493e). The input when mapped is a 16-byte thingy (sizeof nfs23_map_handle_t), and GetFH needs to expand the 16-byte mapped handle into an FH4. I assume the code when written had a FH4_SIZE as it’s max length, rather than the fh_desc buffer appearing to be trimmed to 16-bytes (that is, I think there was a length separate from max length at the time or something). IIRC, all the handle mapping code *actually* passes around a buffer that is large enough for the largest FH4 plus some padding. So the “resizing” done in handle_to_wire that needs to be undone in wire_to_host can actually happen in-place but the len field doesn’t know that. Ganesha experts, does that sound right, historically? On Mon, Jun 28, 2021 at 22:14 Frank Filz <ffilzlnx@mindspring.com> wrote:
Looks like the handle mapping code isn’t kicking in or isn’t doing what we think it should do.
Though we should also have space for a 55 byte wire handle…
Maybe that 16 byte space is wrong.
Frank
*From:* Nick Couchman [mailto:nick.e.couchman@gmail.com] *Sent:* Monday, June 28, 2021 8:45 PM *To:* Solomon Boulos <boulos@waymo.com> *Cc:* Frank Filz <ffilzlnx@mindspring.com>; Todd Pfaff < pfaff@rhpcs.mcmaster.ca>; support@lists.nfs-ganesha.org *Subject:* [NFS-Ganesha-Support] Re: Proxy FSAL - NFS4 -> 3
On Mon, Jun 28, 2021 at 11:41 PM Solomon Boulos <boulos@waymo.com> wrote:
Huh. Can you LogDebug those values? It seems to me like that check should be <= not strict less than.
As a matter of fact, yes:
28/06/2021 23:29:33 : epoch 60da938f : nfs-proxy.example.com : ganesha.nfsd-464682[svc_10] HandleMap_GetFH :FSAL :DEBUG :h->fh_len: 55, fsal_handle->len: 16
So, changing a strict < to <= won't help much...
-Nick