We've been unable to progress with these failures for some time,
and it's not good to have them red in CI all the time.
Manual start should allow easier testing of future fixes,
without doing the futile runs automatically.

Fixes #758

Héctor Molinero Fernández authored 2 years ago and Vladimír Čunát committed 2 years ago

Fixes a regression on Meson 0.57.0 that produces a timeout in config.ta_bootstrap test.

Some of our CI jobs use project-specific GitLab runners (e.g. requiring
the `dind` tag). The jobs then fail when someone forks the repository
and opens a merge request. This commit confines those jobs to the
`knot/knot-resolver` repository.

Oto Šťáva authored 2 years ago and Vladimír Čunát committed 2 years ago

The double-free may have happened in some cases when the upstream
resolver was stopped while answering a forwarded query. I was reliably
reproducing it by running resperf on two kresd instances with one forwarded
to the other, and killing the upstream one.

When kresd starts without working internet connection, these would spam
logs by default every 10 seconds, which doesn't seem useful.

I can't see sufficient motivation here.  The cache will be slightly
less ready, but it's not often that you need to contact a root server.

Most importantly, kresd must work well anyway, even with empty cache.
Also, the compiled-in address set of root servers should be quite
accurate - the NS set has never changed, and the last address change
was five years ago with just one of 26 records changing.

Fixes #746

The `check_uri()` function now only checks that the endpoint is either
`/doh` or `/dns-query`. Parameter checks were moved into
`process_uri_path()` so that the check only takes place for GET
requests. POST requests now do not care about parameters at all.

release 5.5.1

See merge request !1308

Oto Šťáva authored 2 years ago and Vladimír Čunát committed 2 years ago

(we changed the original fix a bit)

Олег Петрачев authored 2 years ago and Vladimír Čunát committed 2 years ago

(with minor cleanups from vcunat)

I have no idea why this one appeared right now (part not touched),
and it does not make sense at all:

../../../lib/utils.c:524:20: warning: Out of bound memory access (accessed memory precedes memory block)
        buf[len_need - 1] = 0;
        ~~~~~~~~~~~~~~~~~~^~~

I used -Winline (optimizing, gcc 11 or 12) to gather warnings
about cases that were considered too expensive for inlining.
Some of these probably used not to happen when we were dropping
assertions during preprocessing in -DNDEBUG builds.
This commit mainly improves size of the compiled binary by several KiB.

- queue_head_impl(): optionally (un)inline; not big but in warnings
- queue_pop_impl(): uninline; too complex for my today's eyes
- kr_rand_bytes(): optionally (un)inline
  The inlining potential there comes from calling with a constant.
- kr_straddr(): uninline.  It's never been meant for hot code,
  and this gives us large savings due to deduplicating the static array.
- For some I couldn't see a good resolution due to restrictions in C.

C hint: `static inline` is probably well known;
the other inline combination is well explained at:
https://stackoverflow.com/a/6312813/587396

And that made the "NO6: is KO" line extraneous.
Example in context:
[select][14162.01]   => id: '15271' choosing from addresses: 0 v4 + 1 v6; names to resolve: 6 v4 + 5 v6; force_resolve: 0; NO6: IPv6 is OK
[select][14162.01]   => id: '15271' choosing: 'ns1.p31.dynect.net.'@'2600:2000:2210::31#00053' with timeout 774 ms zone cut: 'amazon.com.'
[select][14162.01]   => id: '15271' updating: 'ns1.p31.dynect.net.'@'2600:2000:2210::31#00053' zone cut: 'amazon.com.' with rtt 316 to srtt: 311 and variance: 89

It was still possible to get into a deadlock here.
https://forum.turris.cz/t/not-connecting-to-applications-like-discord/17111/7
If A records for a NS fell out of cache but AAAA remained,
with probability 1-\epsilon we'd choose an AAAA address
even if IPv6 was considered broken.

I looked at *the whole* no6 strategy again, and I do think that
there are no such holes anymore.  A few percent attempts will still
go over IPv6 even if it's considered broken, but that sounds OK-ish.

No other job can do it, as we don't have docker images ready for that,
and the usual manual workflow won't be well usable with arm64.
We'll need to convert their generation to (manual?) CI schedules.

Other pkgtest jobs can't do this, as they're designed for LXC
and we don't have an arm+LXC runner.