[PATCH v4 4/6] linux: Add compatibility definitions to sys/prctl.h for MTE

Richard Earnshaw Richard.Earnshaw@foss.arm.com
Mon Dec 21 13:34:44 GMT 2020


On 21/12/2020 13:32, Siddhesh Poyarekar wrote:
> On 12/19/20 12:59 AM, Richard Earnshaw via Libc-alpha wrote:
>>
>> Older versions of the Linux kernel headers obviously lack support for
>> memory tagging, but we still want to be able to build in support when
>> using those (obviously it can't be enabled on such systems).
>>
>> The linux kernel extensions are made to the platform-independent
>> header (linux/prctl.h), so this patch takes a similar approach.
>> ---
>>   sysdeps/unix/sysv/linux/sys/prctl.h | 18 ++++++++++++++++++
>>   1 file changed, 18 insertions(+)
> 
> Please put the additions into an architecture-specific
> sysdeps/unix/sysv/linux/aarch64/sys/prctl.h and include_next this file
> from there.
> 
>>
>> diff --git a/sysdeps/unix/sysv/linux/sys/prctl.h
>> b/sysdeps/unix/sysv/linux/sys/prctl.h
>> index 7f748ebeeb..4d01379c23 100644
>> --- a/sysdeps/unix/sysv/linux/sys/prctl.h
>> +++ b/sysdeps/unix/sysv/linux/sys/prctl.h
>> @@ -21,6 +21,24 @@
>>  #include <features.h>
>>  #include <linux/prctl.h>  /*  The magic values come from here  */
>>  
>> +/* Recent extensions to linux which may post-date the kernel headers
>> +   we're picking up...  */
>> +
>> +/* Memory tagging control operations (for AArch64).  */
>> +#ifndef PR_TAGGED_ADDR_ENABLE
>> +# define PR_TAGGED_ADDR_ENABLE    (1UL << 8)
>> +#endif
>> +
>> +#ifndef PR_MTE_TCF_SHIFT
>> +# define PR_MTE_TCF_SHIFT    1
>> +# define PR_MTE_TCF_NONE    (0UL << PR_MTE_TCF_SHIFT)
>> +# define PR_MTE_TCF_SYNC    (1UL << PR_MTE_TCF_SHIFT)
>> +# define PR_MTE_TCF_ASYNC    (2UL << PR_MTE_TCF_SHIFT)
>> +# define PR_MTE_TCF_MASK    (3UL << PR_MTE_TCF_SHIFT)
>> +# define PR_MTE_TAG_SHIFT    3
>> +# define PR_MTE_TAG_MASK    (0xffffUL << PR_MTE_TAG_SHIFT)
>> +#endif
>> +
>>  __BEGIN_DECLS
>>  
>>  /* Control process execution.  */
> 
> 

The standard linux kernel headers have this in an architecture
independent file, so why should glibc need to do this differently?

R.


More information about the Libc-alpha mailing list