The current check checks for n_sigbus_queue
being greater than or equal to SIGBUS_QUEUE_MAX,
when it should be just greater than as
n_sigbus_queue being SIGBUS_QUEUE_MAX indicates
that the queue is full, but not overflowed.
Currently, networkd does not change pool size dynamically, so this
should not change behavior. But if networkd does that, then forgetting
leases causes that an address still used by a client may be assigned to
another host.
- Even if we found a matching static lease, check if there is no
conflicting lease.
- Accept an address request that is different from the previous one.
- Also return NAK if the server address is requested.
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.
This adds a new concept for handling paths. At appropriate places, if a
path such as /foo/bar/baz.v/ is specified, we'll
automatically enumerate all entries in /foo/bar/baz.v/baz* and then
do a version sort and pick the newest file.
A slightly more complex syntax is available, too:
/foo/bar/baz.v/quux___waldo
if that's used, then we'll look for all files matching
/foo/bar/baz.v/quux*waldo, and split out the middle, and version sort
it, and pick the nwest.
The ___ wildcard indicates both a version string, and if needed an
architecture ID, in case per-arch entries shall be supported.
This is a very simple way to maintain versioned resources in a dir, and
make systemd's components automatically pick the newest. Example:
/srv/myimages.v/foobar_1.32.65_x86-64.raw
/srv/myimages.v/foobar_1.33.45_x86-64.raw
/srv/myimages.v/foobar_1.31.5_x86-64.raw
/srv/myimages.v/foobar_1.31.5_arm64.raw
If now nspawn is invoked like this:
systemd-nspawn --image=/srv/myimages.v/foobar___.raw
Then it will automatically pick
/srv/myimages.v/foobar_1.33.45_x86-64.raw as the version to boot on
x86-64, and /srv/myimages.v/foobar_1.31.5_arm64.raw on arm64.
This commit only adds the basic implementation for picking files from a
dir, but no hook-up anywhere.
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
Global resource (whole system or root cg's (e.g. in a container)) is
also a well-defined limit for memory and tasks, take it into account
when calculating effective limits.
Users become perplexed when they run their workload in a unit with no
explicit limits configured (moreover, listing the limit property would
even show it's infinity) but they experience unexpected resource
limitation.
The memory and pid limits come as the most visible, therefore add new
unit read-only properties:
- EffectiveMemoryMax=,
- EffectiveMemoryHigh=,
- EffectiveTasksMax=.
These properties represent the most stringent limit systemd is aware of
for the given unit -- and that is typically(*) the effective value.
Implement the properties by simply traversing all parents in the
leaf-slice tree and picking the minimum value. Note that effective
limits are thus defined even for units that don't enable explicit
accounting (because of the hierarchy).
(*) The evasive case is when systemd runs in a cgroupns and cannot
reason about outer setup. Complete solution would need kernel support.
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 is important now that creds are sent via varlink
systemd-creds[463]: varlink-3: Sending message: {"parameters":{"data":"Zm9vYmFyCg=="}}
systemd-creds[462]: varlink-3: New incoming message: {"method":"io.systemd.Credentials.Encrypt","parameters":{"data":"Zm9vYmFyCg=="}}
This extends our current polkit logic, so that we can in a very similar
fashion as we already can authenticate dbus peers authenticate varlink
connection peers.
polkit natively speaks dbus and can authentication dbus peers. To get
the same level of support for varlink we'll use authentication by
pidfd+uid. This requires polkit v124, and if that's not available it
will fallback to authorizing root only as before.
Co-authored-by: Luca Boccassi <bluca@debian.org>
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.
Yu Watanabe
Michal Sekletar
Rose
Dmitry Konishchev
Lennart Poettering
Mike Yuan
Michal Koutný
Luca Boccassi