When KeepCarrier is set, networkd doesn't close tun/tap file descriptor
preserving the active interface state, but doesn't disable its queue
which makes kernel to think that it's still active and send packets to
it.
This patch disables the created queue right after tun/tap interface
creation.
Here is the steps to reproduce the bug:
Having:
systemd/network/10-tun-test.netdev:
[NetDev]
Name=tun-test
Kind=tun
[Tun]
MultiQueue=yes
KeepCarrier=yes
systemd/network/10-tun-test.network:
[Match]
Name=tun-test
[Network]
DHCP=no
IPv6AcceptRA=false
LLMNR=false
MulticastDNS=false
Address=172.31.0.1/24
app.c:
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <linux/if.h>
#include <sys/ioctl.h>
#include <linux/if_tun.h>
int main() {
int fd;
struct ifreq ifr;
memset(&ifr, 0, sizeof ifr);
strcpy(ifr.ifr_name, "tun-test");
ifr.ifr_flags = IFF_TUN | IFF_NO_PI | IFF_MULTI_QUEUE;
if((fd = open("/dev/net/tun", O_RDWR)) < 0) {
perror("Open error");
return 1;
}
if(ioctl(fd, TUNSETIFF, &ifr)) {
perror("Configure error");
return 1;
}
puts("Ready.");
char buf[1500];
while(1) {
int size = read(fd, buf, sizeof buf);
if(size < 0) {
perror("Read error");
return 1;
}
printf("Read %d bytes.\n", size);
}
return 0;
}
Run:
* gcc -o app app.c && ./app
* ping -I tun-test 172.31.0.2
Before the patch the app shows no pings, but after it works properly.
If a TPM doesn't do ECC it could either return zero curves when asked
for it, or it could simply fail with TPM2_RC_VALUES because it doesn't
recognize the capability at all.
Handle both cases the same way.
Fixes: #30679
This commit introduces new D-Bus API, StartAuxiliaryScope(). It may be
used by services as part of the restart procedure. Service sends an
array of PID file descriptors corresponding to processes that are part
of the service and must continue running also after service restarts,
i.e. they haven't finished the job why they were spawned in the first
place (e.g. long running video transcoding job). Systemd creates new
scope unit for these processes and migrates them into it. Cgroup
properties of scope are copied from the service so it retains same
cgroup settings and limits as service had.
Distributions apparently only compile a subset of TPM2 drivers into the
kernel. For those not compiled it but provided as kmod we need a
synchronization point: we must wait before the first TPM2 interaction
until the driver is available and accessible.
This adds a tpm2.target unit as such a synchronization point. It's
ordered after /dev/tpmrm0, and is pulled in by a generator whenever we
detect that the kernel reported a TPM2 to exist but we have no device
for it yet.
This should solve the issue, but might create problems: if there are TPM
devices supported by firmware that we don't have Linux drivers for we'll
hang for a bit. Hence let's add a kernel cmdline switch to disable (or
alternatively force) this logic.
Fixes: #30164
When we receive a goodby packet about a host, and we have a cache entry about
the host, we do not immediately remove the cache entry, but update it with TTL 1.
See RFC 6762 section 10.1 and 3755027c2c.
If we receive a request soon after the goodby packet, previously the
entry was included in the known answers section of the reply. But such
information should not be appended.
Follow-up for 3755027c2c.
This does what we do for system extension also for configuration
extension.
This is complicated by the fact that we previously looked for
<uki-binary>.d/*.raw for system extensions. We want to measure sysexts
and confexts to different PCRs (13 vs. 12) hence we must distinguish
them, but *.raw would match both kinds.
This commit solves this via the following mechanism: we'll load confexts
from *.confext.raw and sysexts from *.raw but will then enclude
*.confext.raw from the latter. This preserves compatibility but allows
us to somewhat reasonable distinguish both types of images.
The documentation is updated not going into this detail though, and
instead now claims that sysexts shall be *.sysext.raw and confexts
*.confext.raw even though we actually are more lenient than this. This
is simply to push people towards using the longer, more descriptive
suffixes.
I added an XML comment (<!-- … -->) about this to the docs, so that
whenever somebody notices the difference between code and docs
understands why and leaves it that way.
Currently, link_queue_request_safe(), which is a wrapper of
request_new(), is called with a free function at
- link_request_stacked_netdev() at netdev/netdev.c,
- link_request_address() at networkd-address.c,
- link_request_nexthop() at networkd-nexthop.c,
- link_request_neighbor() at networkd-networkd.c.
For the netdev case, the reference counter of the passed object is increased
only when the function returns 1. So, on failure (with -ENOMEM)
previously we unexpectedly dropped the reference of the NetDev object.
Similarly, for Address and friends, the ownership of the object is moved to the
Request object only when the function returns 1. And on failure, previously
the object was freed twice.
Also, netdev_queue_request(), which is another wrapper of request_new()
potentially leaks memory when the same NetDev object is queued twice.
Fortunately, that should not happen as the function is called only once
per object.
This fixes the above issue, and now the ownership or the reference
counter of the object is changed only when it is succeeded with 1.
Rewrite the test in bash and make it part of our integration test suite,
so it's actually executed in all our upstream CI environments.
The original test is flaky in environments where daemon-reload might
occur during the test runtime (e.g. when running the test in parallel
with the systemd-networkd test suite). Also, it was run only in CentOS
CI in limited way (i.e. without sanitizers), since it tests the host's
systemd, instead of the just built one.
Resolves: #29943
Then, replace address_remove_and_drop() with it.
If an address is requested, and the request is already called,
we may not received its reply and notification from the kernel, and
the corresponding address object may not be remmbered. Even in such
case, we need to remove the address, otherwise the address will come
later after the function called.
Turns out Coccinelle can handle compound literals just fine, the parsing
errors were caused by incorrectly parsed macros in code before the
literals, so let's just provide simplified versions for such macros.
The parsing error in `Type *foo[ELEMENTSOF(bar)] = {};` is actually
harmless; it occurs only when creating an array of pointers for a type
that's in an external header and it occurs only on the first parser's
pass, subsequent passes resolve the type correctly.
Also, unset ENABLE_DEBUG_HASHMAP, so Coccinelle doesn't expand the
hashmap debug macros.
As for the remaining FIXMEs, I opened a couple of issues in the
Coccinelle upstream to see if they can be fixed there (or at least
properly analyzed).
Yu Watanabe
Dmitry Konishchev
Lennart Poettering
Mike Yuan
Michal Sekletar
Rose
Frantisek Sumsal
Mike Gilbert