On Thu, Jul 30, 2015 at 10:38:31AM +0200, Ingo Molnar wrote: > When the system call is extended in the future on the kernel side, with 'u64 > param_4', then the structure expands from an old size of 24 to a new size of > 32 > bytes. The following scenarios might occur: > > - the common case: new user-space calls the new kernel code, ->size is 32 on > both > sides. > > - old binaries might call the kernel with params->size == 24, in which case > the > kernel sets the new fields to 0. The new feature should be written > accordingly, so that a value of 0 means the old behavior. > > - new binaries might run on old kernels, with params->size == 32. In this > case > the old kernel will check that all the new fields it does not know about > are > set to 0 - if they are nonzero (if the new feature is used) it returns > with > -ENOSYS or -EINVAL.
Nit: it seems easier, rather than having the kernel check this, to have userspace only use the minimum version of the structure that contains the features they use, and then have older kernels reject sizes bigger than they understand. If you don't need param_4, don't use the version of the structure that has param_4. That also means the kernel doesn't need to copy and read those values. Either approach works, though. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
