[PATCH v2 5/5] linux: Fix sys/mount.h usage with kernel headers
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Fri Aug 12 12:45:39 GMT 2022
On 11/08/22 18:57, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
>
>> Now that kernel exports linux/mount.h and includes it on linux/fs.h,
>> its definitions might clash with glibc exports sys/mount.h. To avoid
>> the need to rearrange the Linux header to be always after glibc one,
>> the glibc sys/mount.h is changed to:
>>
>> 1. Undefine the macros also used as enum constants. This covers prior
>> inclusion of <linux/mount.h> (for instance MS_RDONLY).
>>
>> 2. Include <linux/mount.h> based on the usual __has_include check
>> (needs to use __has_include ("linux/mount.h") to paper over GCC
>> bugs.
>>
>> 3. Define enum fsconfig_command only if FSOPEN_CLOEXEC is not defined.
>> (FSOPEN_CLOEXEC should be a very close proxy.)
>>
>> 4. Define struct mount_attr if MOUNT_ATTR_SIZE_VER0 is not defined.
>> (Added in the same commit on the Linux side.)
>>
>> This patch also adds some tests to check if including linux/fs.h and
>> linux/mount.h after and before sys/mount.h does work.
>>
>> Checked on x86_64-linux-gnu.
>
> Also built with build-many-glibcs.py. This version looks good.
>
> There is a gap with old compilers only (those that don't have
> __has_include), and if <linux/mount.h> is included after <sys/mount.h>,
> but I think that's an acceptable trade-off.
At least gcc 6 does have support for __has_include (or it was backported in
the release branches) which the minimum supported version to build glibc
itself. I am not sure how common is deployment with gcc version older
with newer glibc, so I agree with the trade-off.
>
> Reviewed-by: Florian Weimer <fweimer@redhat.com>
>
Thanks.
> Thanks,
> Florian
>
More information about the Libc-alpha
mailing list