On Mon, Nov 23, 2020 at 05:38:02PM +0000, Frank van der Linden wrote: > It wouldn't be the end of the world to change LISTXATTRS (and GETXATTR) > to use preallocated pages. But, I didn't do that because I didn't want to > waste the max size (64k) every time, even though you usually just get > a few hundred bytes at most. So it seems like fixing XDRBUF_SPARSE_PAGES > is cleaner. Correcting myself here.. this is true of GETXATTR, since there is no maximum length argument for that call - so your only choice is to allocate the max of what you can handle, and SPARSE seems to be the best option fr that. For LISTXATTRS, there is a max length argument. It's a bit unusual, in that it specifies the maximum number of bytes of *XDR* data you want to receive. So you don't need to allocate the maximum number of pages. But, I decided to still use the SPARSE option, since the common 0 length argument to the listxattr syscall, used to probe the length of the buffer needed, would still require the maximum length (64k) to be allocated, because there is no 0 lengh 'probe' option for the RPC. So all you can do is ask for the maximum size you can handle, and see what you get back to determine the length. Olga's comment about caching: the code actually does cache the data for all valid replies, even if the system call only was a len == 0 probe call. That way, the followup system call that actually retrieves the data can normally just get it from the cache. In any case, I need to set up an RDMA environment to see if I can reproduce and fix the issue. I hope to do that today or tomorrow. - Frank
