[LTP] [PATCH 1/2] configure: Fix build on kernel 6.14 headers

[Li Wang]

On Wed, Jun 4, 2025 at 12:12 AM Petr Vorel <pvorel@suse.cz> wrote:

> Hi all,
>
> > Hi!
> > Let's push this now, it's simple enough and fixes the CI.
>
> I'm sorry, it did not fix the problem due the old problem of indirect
> include
> <linux/mount.h> by <linux/fs.h> on Alpine v3.22 (the default Alpine
> version in
> GitHub action), which uses 6.14.2 kernel headers:
>
>     In file included from /usr/include/linux/fs.h:19,
>                      from /usr/include/linux/btrfs.h:29,
>                      from statmount02.c:23:
>     /usr/include/linux/mount.h:155:8: error: redefinition of 'struct
> statmount'
>       155 | struct statmount {
>           |        ^~~~~~~~~
>     In file included from statmount.h:12,
>                      from statmount02.c:20:
>     ../../../../include/lapi/mount.h:58:8: note: originally defined here
>        58 | struct statmount {
>           |        ^~~~~~~~~
>     /usr/include/linux/mount.h:193:8: error: redefinition of 'struct
> mnt_id_req'
>       193 | struct mnt_id_req {
>           |        ^~~~~~~~~~
>     ../../../../include/lapi/mount.h:49:8: note: originally defined here
>        49 | struct mnt_id_req {
>           |        ^~~~~~~~~~
>
> But we still support old Leap 42 (glibc 2.22 based), which requires for
> statmount04.c old fallbacks for <sys/mount.h> but also new mount API
> defined in <linux/mount.h>, otherwise it fails:
>
>     statmount03.c:62:4: error: 'MS_PRIVATE' undeclared here (not in a
> function)
>       { MS_PRIVATE, TST_TO_STR_(MS_PRIVATE) },
>         ^
>     statmount03.c:63:4: error: 'MS_SHARED' undeclared here (not in a
> function)
>       { MS_SHARED, TST_TO_STR_(MS_SHARED) },
>         ^
>     statmount03.c:64:4: error: 'MS_SLAVE' undeclared here (not in a
> function)
>       { MS_SLAVE, TST_TO_STR_(MS_SLAVE) },
>         ^
>     In file included from ../../../../include/tst_test.h:185:0,
>                      from statmount.h:11,
>                      from statmount04.c:21:
>     statmount04.c: In function 'setup':
>     statmount03.c:65:4: error: 'MS_UNBINDABLE' undeclared here (not in a
> function)
>       { MS_UNBINDABLE, TST_TO_STR_(MS_UNBINDABLE) },
>         ^
>     statmount04.c:57:35: error: 'MS_BIND' undeclared (first use in this
> function)
>       SAFE_MOUNT(DIR_A, DIR_A, "none", MS_BIND, NULL);
>                                        ^
>     ../../../../include/tst_safe_macros.h:244:25: note: in definition of
> macro 'SAFE_MOUNT'
>           (filesystemtype), (mountflags), (data))
>                              ^
>     In file included from ../../../../include/tst_test.h:185:0,
>                      from statmount.h:11,
>                      from statmount03.c:21:
>     statmount03.c: In function 'run':
>     statmount04.c:57:35: note: each undeclared identifier is reported only
> once for each function it appears in
>       SAFE_MOUNT(DIR_A, DIR_A, "none", MS_BIND, NULL);
>                                        ^
>     ../../../../include/tst_safe_macros.h:244:25: note: in definition of
> macro 'SAFE_MOUNT'
>           (filesystemtype), (mountflags), (data))
>                              ^
>     statmount03.c:74:35: error: 'MS_BIND' undeclared (first use in this
> function)
>       SAFE_MOUNT(DIR_B, DIR_A, "none", MS_BIND, NULL);
>
> I suppose we should have 2 or 3 lapi files:
>
> 1) lapi/mount.h
> mount definitions (guarded by #ifndef) - the old ones from <sys/mount.h>
> e.g.
> MS_REC, MS_PRIVATE and probably the new ones from <linux/mount.h>, e.g.
> MNT_ID_REQ_SIZE_VER0. None of <sys/mount.h> <linux/mount.h> should be
> included
> in it.
>
> 2) lapi/linux_mount.h
> mount structs (nowadays vast majority if not all from <linux/mount.h>
> only).
> This header can include <linux/mount.h> and lapi/mount.h.
> That allows to have configure.ac to safely use <linux/mount.h> for
> detection.
>
> 3) lapi/sys_mount.h
> Optional helper header which would include lapi/mount.h and <sys/mount.h>
> (to keep the current approach that lapi headers include system headers so
> that
> tests does not need to do it.
>
> WDYT?
>

Sounds reasonable to me, we could have a try.


-- 
Regards,
Li Wang