Just have the one callback, but return an abstracted event mask
to work out if we can read/write have something else.
Log diagnostics if the event mask is unexpected.
While here add more logging if we fail to register an event to
monitor.
The default is ppoll(2), but we still allow epoll(7) so
allowing pselect(2) makes perfect sense and allows the user
to pick the polling mechanism they want.
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_MICROBLAZE is only defined since
kernel 3.18 and
ce5d112827
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_NIOS2 is only defined since kernel
5.2 and
1660aac45e
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_XTENSA is only defined since kernel
5.0 and
98c3115a4e
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_NDS32 is only defined since kernel
5.2 and
fa562447e1
Fixes:
- http://autobuild.buildroot.org/results/af8ba07ea0c12ab8cd24d528ef98db05521f3d36
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This makes the code smaller yet and also use less memory then ppoll!
Still, the API blows chunks and we still have arbitary fd limits
which we'll realistically never hit.
Also, some BSD's note potential issues with select on the same fd
across processes so ppoll is still the winner.
Even though we now have fully working kqueue(2) and epoll(7)
with our privsep code, ppoll(2) is faster and smaller for our
workload.
This time though, we will keep the code here as it's fully working
and while fixing kqueue we also fixed other bugs in dhcpcd as a result
so it's not time wasted at all.
kqueue allows for O(1) processing of active fd's an a more
robust signal handling method without the need to use global
variables to avoid calling functions during signal delivery.
The problems with the prior implemenation have now been fixed.
We do this by ensuring the events list or pollfd struct storage
is not modified during the revent processing.
An event with a fd of -1 means it's been deleted and one without
a pollfd struct reference has been newly added.
This also allows us to count down the number of fd's that
returned a revent so we can break the loop early if possible.
This is a really minor optimisation that at best only applies if
more than one revent is returned via poll(2).
In the case on dhcpcd on NetBSD with privsep, the number of
fd's is really low. And on other platforms or without privsep it's
low also (just not as low).
It's only when you run dhcpcd per interface that the number
of fd's starts to creep upwards as you then need one per address
dhcpcd is monitoring (as well as the ARP listener per IPv4 address
for non NetBSD).
However, I use eloop in other code where this could be a good saving
and dhcpcd is where the master version of this lives!
This solves the warnings on all OS other than Linux who don't have
a supporting resolvconf for deprecating DNS because they never
emit the NOCARRIER_ROAMING reason.
This is given when the OS supports the concept of wireless roaming
or the IP setup can be persisted when the carrier drops.
When this happens, routes are moved to a higher metric (if supported)
to support non preferred but non roaming routes.
The `interface_order` hook variable will now order the interfaces
according to priority and move roaming interfaces to the back of the
list.
If resolvconf is present then it is called with the -C option
to deprecate DNS and if carrier comes back it is called again with the
-c option to activate it once more.
As part of this change, default route metrics have been changed to
support a larger number of interfaces.
base metric 1000 (was 200)
wireless offset 2000 (was 100)
IPv4LL offset 1000000 (was 10000)
roaming offset 2000000
