On Sun, 7 Jul 2024 at 17:06, Julian Schindel <mail@xxxxxxxxxxxxxxxx> wrote: > > Hi, > > I hope this is the correct way to ask about this issue, I haven't used > the kernel mailing list before. > > Between different compilations of an AF_XDP project, I encountered > "random" EINVAL errors when calling setsockopt XDP_UMEM_REG with the > same parameter. > > I think this might be caused by this patch: > https://lore.kernel.org/all/20231127190319.1190813-2-sdf@xxxxxxxxxx/ > It added "tx_metadata_len" to the "xdp_umem_reg" struct. > In the "xsk_setsockopt" code in xdp/xsk.c, the provided "optlen" is > checked against the length of "xdp_umem_reg_v2" and "xdp_umem_reg" to > check which version of "xdp_umem_reg", the user supplied. > > At least on my machine (x86_64, Fedora 40, 6.9.7), these two structs > have the same size (32 bytes) due to the compiler adding padding to > "xdp_umem_reg_v2". This means if the user supplies "xdp_umem_reg_v2", it > is falsely treated as "xdp_umem_reg". > > I'm not sure whether there is some implicit struct packing happening or > whether this is indeed a bug. Thank you for reporting this Julian. This seems to be a bug. If I check the value of sizeof(struct xdp_umem_reg_v2), I get 32 bytes too on my system, compiling with gcc 11.4. I am not a compiler guy so do not know what the rules are for padding structs, but I read the following from [0]: "Pad the entire struct to a multiple of 64-bits if the structure contains 64-bit types - the structure size will otherwise differ on 32-bit versus 64-bit. Having a different structure size hurts when passing arrays of structures to the kernel, or if the kernel checks the structure size, which e.g. the drm core does." I compiled for 64-bits and I believe you did too, but we still get this padding. What is sizeof(struct xdp_umem_reg) for you before the patch that added tx_metadata_len? [0]: https://www.kernel.org/doc/html/v5.4/ioctl/botching-up-ioctls.html > Best regards, > Julian > >
