It's like CIFuzz but unlike CIFuzz it's compatible with forks and
it should make it possible to run the fuzzers to make sure that
patches backported to them are backported correctly without introducing
new bugs and regressions.
A bind mount is added directly from private on the host to the actual
destination directory, no need for the symlinks (which cannot be created
as the bind mount happens first and creates the target as an actual directory)
Fixes https://github.com/systemd/systemd/issues/22264
If wait_operstate() is called super quickly after ip command, then the
up/down state may not be changed and propagated to networkd, and
wait_operstate() mistakenly pass with the previous state.
To avoid such situation, wait for a while to make networkd actually
detect the interface brought up/down.
This fixes the following race:
1. when a dummy interface is created, it is initially down state,
2. hence, wait_operstate() may pass before the link is activated,
3. and the ip command bring up the interface before the activation,
4. and networkd activates, that is, brings down the interface,
5. thus, next wait_operstate() timedout, as it waits for the interface up.
To fix the race, let's wait the link is activated, before enter the loop
of wait_operstate().
Fixes#22267.
Since the TEST-64-UDEV-STORAGE fails are quite frequent now and the root
cause is yet to be discovered, let's add a kludge that attempts to retry
the test up to two more times in case it fails, so we don't
unnecessarily disturb CIs while the issue is being investigated.
Revert this commit once #21819 is sorted out.
Tests DnsStream event handling, both for plain TCP DNS and DNS over TLS.
The DoT test requires the "openssl s_server" command line tool to mock a simple
TLS server. Thus the test's TLS part is skipped if openssl it not available.
The test works for both DNS_OVER_TLS_USE_GNUTLS and DNS_OVER_TLS_USE_OPENSSL.
The DoT case fails due to a bug, which is fixed on the next commit.
When sending multiple DNS questions to a DNS-over-TLS server (e.g. a question
for A and AAAA records, as is typical) on the same session, the server may
answer to each question in a separate TLS record, but it may also aggregate
multiple answers in a single TLS record.
(Some servers do this very often (e.g. Cloudflare 1.0.0.1), some do it sometimes
(e.g. Google 8.8.8.8) and some seem to never do it (e.g. Quad9 9.9.9.10)).
Both cases should be handled equivalently, as the byte stream is the same, but
when multiple answers came in a single TLS record, usually the first answer was
processed, but the second answer was entirely ignored, which caused a 10s delay
until the resolution timed out and the missing question was retried.
This can be reproduced by configuring one of the offending server and running
`resolvectl query google.com --cache=no` a few times.
To be notified of incoming data, systemd-resolved listens to `EPOLLIN` events
on the underlying socket. However, when DNS-over-TLS is used, the TLS library
(OpenSSL or GnuTLS) may read and buffer the entire TLS record when reading the
first answer, so usually no further `EPOLLIN` events will be generated, and the
second answer will never be processed.
To avoid this, if there's buffered TLS data, generate a "fake" EPOLLIN event.
This is hacky, but it makes this case transparent to the rest of the IO code.
Yu Watanabe
Frantisek Sumsal
Evgeny Vereshchagin
Anita Zhang
Daan De Meyer
Ryan Hendrickson
Julia Kartseva
Luca Boccassi
Seth Falco
Christian Brauner
Joan Bruguera
Arfrever Frehtes Taifersar Arahesis