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.

https://clangd.llvm.org/design/include-cleaner
Though somehow I'm all the time getting false positives for
"daemon/bindings/impl.h"

It provides more information and the condition is typically
easier to read, too.

WARNING: You should add the boolean check kwarg to the run_command call.
         It currently defaults to false,
         but it will default to true in future releases of meson.
         See also: https://github.com/mesonbuild/meson/issues/9300

In almost all cases we already check the return code explicitly
and throw a more descriptive message than what would be the default.

Konstantin Amelichev authored 2 years ago and Vladimír Čunát committed 2 years ago

https://github.com/CZ-NIC/knot-resolver/pull/77
originally but changed by vcunat quite a bit.

https://man7.org/linux/man-pages/man3/posix_fallocate.3.html#ERRORS:
> EOPNOTSUPP
> The filesystem containing the file referred to by fd does not support
> this operation.  This error code can be returned by C libraries that
> don't perform the emulation shown in NOTES, such as **musl libc**.

I've encountered this problem on Alpine Linux running inside an LXC
container on Ubuntu with data on ZFS.

Fixes #728

Debian 10 could probably get dropped soon, but not yet.

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

The nghttp2 documentation states that we must not send data from inside
of its callbacks. It may result in crashes.

Closes #742

Closes #443 and #738

- I see no motivation to search for NS records here;
  and I didn't like that loop nesting
- philosophy shift akin to the recent
  replacement of kr_nsec_existence_denial()

Just as with NODATA; basically the same comments
apply here (i.e. for NXDOMAIN) as well.

The NSEC validation code has been written very mechanically
according to RFC 4033..4035, but those explain wildcard-related
topics in a way that's hard to understand right.

So here I rewrite it with a different philosophy, so it should be
easier to understand, a bit faster, and less buggy and bug-prone.