Bug 273373 - <sys/timerfd.h> fails to build in POSIX mode due to namespace pollution
Summary: <sys/timerfd.h> fails to build in POSIX mode due to namespace pollution
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Warner Losh
URL:
Keywords:
: 273500 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-08-26 23:26 UTC by Jan Beich
Modified: 2023-10-06 13:31 UTC (History)
5 users (show)

See Also:
jbeich: mfc-stable14+


Attachments
Drop <sys/proc.h> via forward declaration (842 bytes, patch)
2023-08-26 23:42 UTC, Jan Beich
no flags Details | Diff
Drop <sys/proc.h> via forward declaration (815 bytes, patch)
2023-08-26 23:43 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer freebsd_triage 2023-08-26 23:26:53 UTC
While timerfd_* isn't part of POSIX consumers may expect to build fine given epoll-shim, glibc, musl don't error out. Found via x11/mako.

$ cat a.cc
#define _XOPEN_SOURCE 700
#include <sys/timerfd.h>
int main() {}

$ cc a.c
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:49:
In file included from /usr/include/sys/filedesc.h:41:
In file included from /usr/include/sys/lock.h:37:
/usr/include/sys/_lock.h:36:2: error: unknown type name 'u_int'
        u_int   lo_flags;
        ^
/usr/include/sys/_lock.h:37:2: error: unknown type name 'u_int'
        u_int   lo_data;                /* General class specific data. */
        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:49:
In file included from /usr/include/sys/filedesc.h:41:
/usr/include/sys/lock.h:62:2: error: unknown type name 'u_int'
        u_int           lc_flags;
        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:49:
In file included from /usr/include/sys/filedesc.h:43:
/usr/include/sys/priority.h:133:2: error: unknown type name 'u_char'; did you mean 'char'?
        u_char  pri_class;      /* Scheduling class. */
        ^
/usr/include/sys/priority.h:134:2: error: unknown type name 'u_char'; did you mean 'char'?
        u_char  pri_level;      /* Normal priority level. */
        ^
/usr/include/sys/priority.h:135:2: error: unknown type name 'u_char'; did you mean 'char'?
        u_char  pri_native;     /* Priority before propagation. */
        ^
/usr/include/sys/priority.h:136:2: error: unknown type name 'u_char'; did you mean 'char'?
        u_char  pri_user;       /* User priority based on p_cpu and p_nice. */
        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:49:
/usr/include/sys/filedesc.h:53:2: error: unknown type name 'u_long'; did you mean 'long'?
        u_long          *fc_ioctls;     /* per-descriptor allowed ioctls */
        ^
/usr/include/sys/filedesc.h:97:2: error: unknown type name 'u_int'
        u_int           pwd_refcount;
        ^
/usr/include/sys/filedesc.h:108:2: error: unknown type name 'u_int'
        u_int           pd_refcount;
        ^
/usr/include/sys/filedesc.h:109:2: error: unknown type name 'u_short'; did you mean 'short'?
        u_short         pd_cmask;       /* mask for file creation */
        ^
/usr/include/sys/filedesc.h:118:2: error: unknown type name 'u_long'; did you mean 'long'?
        NDSLOTTYPE *fd_map;             /* bitmap of free fds */
        ^
/usr/include/sys/filedesc.h:86:20: note: expanded from macro 'NDSLOTTYPE'
#define NDSLOTTYPE      u_long
                        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:55:
/usr/include/sys/osd.h:40:2: error: unknown type name 'u_int'
        u_int             osd_nslots;   /* (c) */
        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:57:
/usr/include/sys/rtprio.h:74:2: error: unknown type name 'u_short'; did you mean 'short'?
        u_short type;                   /* scheduling class */
        ^
/usr/include/sys/rtprio.h:75:2: error: unknown type name 'u_short'; did you mean 'short'?
        u_short prio;
        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:58:
/usr/include/sys/runq.h:73:54: error: unknown type name 'u_char'; did you mean 'char'?
void    runq_remove_idx(struct runq *, struct thread *, u_char *);
                                                        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:62:
/usr/include/sys/signalvar.h:54:2: error: unknown type name 'sig_t'
        sig_t   ps_sigact[_SIG_MAXSIG]; /* Disposition of signals. */
        ^
/usr/include/sys/signalvar.h:67:2: error: unknown type name 'u_int'
        u_int   ps_refcnt;
        ^
In file included from a.c:2:
In file included from /usr/include/sys/timerfd.h:33:
In file included from /usr/include/sys/proc.h:70:
/usr/include/sys/ucred.h:98:2: error: unknown type name 'u_int'
        u_int   cr_version;             /* structure layout version */
        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
Comment 1 Jan Beich freebsd_committer freebsd_triage 2023-08-26 23:42:26 UTC
Created attachment 244372 [details]
Drop <sys/proc.h> via forward declaration

Tested by:
$ echo 'int main() {}' | cc -xc - -o/dev/null -include sys/sys/timerfd.h
$ echo 'int main() {}' | cc -xc - -o/dev/null -D_KERNEL -include sys/sys/timerfd.h
Comment 2 Jan Beich freebsd_committer freebsd_triage 2023-08-26 23:43:18 UTC
Created attachment 244373 [details]
Drop <sys/proc.h> via forward declaration
Comment 3 Jake Freeland 2023-08-27 00:33:55 UTC
This is addressed in https://reviews.freebsd.org/D41600
Comment 4 Jan Beich freebsd_committer freebsd_triage 2023-08-28 08:44:39 UTC
Both attachment 244373 [details] and review D41600?id=126574 are not self-sufficient:

$ cat a.c
#include <sys/timerfd.h>
int main() { timerfd_create(CLOCK_MONOTONIC, 0); return 0; }

$ cc a.c
a.c:2:29: error: use of undeclared identifier 'CLOCK_MONOTONIC'
int main() { timerfd_create(CLOCK_MONOTONIC, 0); return 0; }
                            ^
1 error generated.

as found via www/chromium

../../third_party/wayland/src/src/event-loop.c:318:28: error: use of undeclared identifier 'CLOCK_MONOTONIC'
        timer_fd = timerfd_create(CLOCK_MONOTONIC,
                                  ^
../../third_party/wayland/src/src/event-loop.c:495:2: warning: call to undeclared function 'clock_gettime'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        clock_gettime(CLOCK_MONOTONIC, &now);
        ^
../../third_party/wayland/src/src/event-loop.c:495:16: error: use of undeclared identifier 'CLOCK_MONOTONIC'
        clock_gettime(CLOCK_MONOTONIC, &now);
                      ^
../../third_party/wayland/src/src/event-loop.c:620:3: warning: call to undeclared function 'clock_gettime'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                clock_gettime(CLOCK_MONOTONIC, &deadline);
                ^
../../third_party/wayland/src/src/event-loop.c:620:17: error: use of undeclared identifier 'CLOCK_MONOTONIC'
                clock_gettime(CLOCK_MONOTONIC, &deadline);
                              ^

Note, clock_gettime() is also affected due to namespace pollution in glibc/musl where <sys/timerfd.h> includes <time.h>. On FreeBSD clock_gettime() was provided via <sys/proc.h> -> <sys/time.h>.
Comment 5 Jake Freeland 2023-08-28 22:17:02 UTC
(In reply to Jan Beich from comment #4)
Based on some simple testing, it looks like we can just follow glib/musl's lead and include sys/time.h?
Comment 6 Jake Freeland 2023-08-28 22:20:45 UTC
(In reply to Jake Freeland from comment #5)
Oops, I misread your comment. glib/musl includes time.h, not sys/time.h, in timerfd.h.
I am getting successful compilation when including sys/time.h in timerfd.h.
Comment 7 Jan Beich freebsd_committer freebsd_triage 2023-08-28 22:34:32 UTC
(In reply to Jake Freeland from comment #6)
> I am getting successful compilation when including sys/time.h in timerfd.h.

Maybe also drop <sys/timespec.h> as it's already included by <sys/time.h>.
Comment 8 Jake Freeland 2023-08-28 22:38:36 UTC
(In reply to Jan Beich from comment #7)
Of course:)

Does chromium successfully compile with this change? I just tested using this example:
#include <sys/timerfd.h>
int main() { timerfd_create(CLOCK_MONOTONIC, 0); return 0; }

I'm setting up a chromium compile now, but if you can do verify easier, I will stop it.
Comment 9 Jake Freeland 2023-08-29 16:05:19 UTC
(In reply to Jake Freeland from comment #8)
Chromium successfully compiled with this change. I'll update review D41600 to include sys/time.h in timerfd.h.

Thanks for reporting this, Jan.
Comment 10 Jan Beich freebsd_committer freebsd_triage 2023-09-01 16:49:03 UTC
*** Bug 273500 has been marked as a duplicate of this bug. ***
Comment 11 Jan Beich freebsd_committer freebsd_triage 2023-09-11 02:26:46 UTC
Landed in base fb5daae920ba but no MFC yet to stable/14 and releng/14.0.
Comment 12 Warner Losh freebsd_committer freebsd_triage 2023-09-11 02:31:15 UTC
(In reply to Jan Beich from comment #11)
Monday. There are several changes and I want to make sure I get them all. Thanks for heads up.
Comment 13 Jan Beich freebsd_committer freebsd_triage 2023-09-29 16:52:47 UTC
Now in stable/14 per base 8bcf9a87c79d but not yet in releng/14.0 (unlike other timerfd fixes). The latter is important for downstream CI e.g., 

https://github.com/emersion/mako/blob/master/.builds/freebsd.yml
https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/.builds/freebsd.yml
Comment 14 Warner Losh freebsd_committer freebsd_triage 2023-09-29 17:13:08 UTC
Doh. I thought I got them all. Will triple check today.

I've been fuzzy all week with an illness... I thought I'd returned to clear thinking yesterday... I'll try again today.
Comment 15 Tomoaki AOKI 2023-09-30 14:31:12 UTC
I thought the delay was just because waiting for re@'s approval.

Confirmed everything MFC'ed to stable/14 are now MFS'ed to releng/14, just before BRANCH is bumpet to BETA4. Thanks!
If I'm not missing anything (looking for open PR and differential revision containing "timerfd"), these were all that pending in base side.
Comment 16 Jan Beich freebsd_committer freebsd_triage 2023-09-30 15:02:13 UTC
(In reply to Tomoaki AOKI from comment #15)
See comment 3. D41600 was later split into series (Stack in Phabricator): D41600 + D41640 + D41641. Of those D41600 and D41640 are now on releng/14.0 but D41641 is still missing.

$ git log origin/releng/14.0 sys/sys/timerfd.h
or
$ git log -E --grep=D41641\|fb5daae920ba\|8bcf9a87c79d origin/releng/14.0
Comment 17 Warner Losh freebsd_committer freebsd_triage 2023-09-30 15:15:10 UTC
Yea. My method to pick all the hunks of timerfd fixes missed one. I've been sick, and was also rushing a little to get things in before the BETA4 deadline. This will be in rc1 or beta5, whatever the next one is called.
Comment 18 Tomoaki AOKI 2023-09-30 16:02:02 UTC
Ah, sorry. I've overlooked 1 of 6 MFCs. base 8bcf9a87c79d on stable/14 is missing on releng/14.0 (Not MFS'ed).
Maybe this is essential for ports maintainers.

Everything I've picked up before appears (including quotes) on freebsd-stable ML [1].
As this post was before some of differential revisions landed into main, some appears as D* numbers.

[1] https://lists.freebsd.org/archives/freebsd-stable/2023-September/001461.html
Comment 19 Warner Losh freebsd_committer freebsd_triage 2023-10-01 04:43:59 UTC
I've landed the last one in releng/14.0 with 7454117918cd9f7900d92513a7a4e3ed361987bc

If someone can confirm this fixes the issue, I'll close the bug
Comment 20 Jan Beich freebsd_committer freebsd_triage 2023-10-01 19:22:00 UTC
I confirm, created 14.0 poudriere jail and tested x11/mako build without the workaround.