On Thu, 4 Feb 2021 15:03:40 -0800 Arjun Roy wrote: > But, if it's an IN or IN-OUT field, it seems like mandating that the > application set it to 0 could break the case where a future > application sets it to some non-zero value and runs on an older > kernel.
That usually works fine in practice, 0 means "do what old kernels did / feature not requested", then if newer userspace sets the field to non-0 that means it requires a feature the kernel doesn't support. So -EINVAL / -EOPNOTSUPP is right. BPF syscall has been successfully doing this since day 1, I'm not aware of any major snags. > And allowing it to be non-zero can maybe yield an unexpected > outcome if an old application that did not zero it runs on a newer > kernel. Could you refresh our memory as to why we can't require the application to pass zero-ed memory to TCP ZC? In practice is there are max reasonable length of the argument that such legacy application may pass so that we can start checking at a certain offset? > So: maybe the right move is to mark it as reserved, not care what the > input value is, always set it to 0 before returning to the user, and > explicitly mandate that any future use of the field must be as an > OUT-only parameter?
