This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement the mlock2 function
On 24/11/2017 17:20, Florian Weimer wrote:
> On 11/24/2017 06:24 PM, Adhemerval Zanella wrote:
>
>>> +int
>>> +mlock2 (const void *addr, size_t length, unsigned int flags)
>>> +{
>>> +#ifdef __ASSUME_MLOCK2
>>> + return INLINE_SYSCALL (mlock2, 3, addr, length, flags);
>>> +#else
>>> + if (flags == 0)
>>> + return INLINE_SYSCALL (mlock, 2, addr, length);
>>> +# ifdef __NR_mlock2
>>> + int ret = INLINE_SYSCALL (mlock2, 3, addr, length, flags);
>>> + if (ret == 0 || errno != ENOSYS)
>>> + return ret;
>>> +# endif /* __NR_mlock2 */
>>> + /* Treat the missing system call as an invalid (non-zero) flag
>>> + argument. */
>>> + __set_errno (EINVAL);
>>> + return -1;
>>> +#endif /* __ASSUME_MLOCK2 */
>>> +}
>>
>> We have the INLINE_SYSCALL_CALL to simplify and avoid issue with mismatch
>> input number and arguments (which is not this case).
>
> I'll switch to that, thanks.
>
>> I am not sure if it is better to advertise EINVAL for ENOSYS mainly
>> because it won't be transparent on a syscall trace. But I do not have
>> a strong opinion here.
>
> It's for consistency. If you specify a (yet unsupported) flag, you get EINVAL with the kernel implementation, but you would get ENOSYS with the userspace implementation. This matters if more flags are added. It would be just another error case for the application to check and a potential for application bugs (say because it is only tested on mlock2-with-new-flag and mlock2 kernels, not on mlock2-less kernels).
>
> In case this isn't obvious (and you're objecting on principle), I'll add a comment. 8-)
This is a reasonable approach and I am ok with this patch with the
INLINE_SYSCALL_CALL change. I wonder if it is worth to add a similar
change to p{read,write}v2 to return ENOSUP in the case of ENOSYS.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>