IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I'm getting the following error under valgrind:
==305970== Invalid free() / delete / delete[] / realloc()
==305970== at 0x483E9F1: free (vg_replace_malloc.c:538)
==305970== by 0x4012CD: mfree (alloc-util.h:48)
==305970== by 0x4012EF: freep (alloc-util.h:83)
==305970== by 0x4017F4: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970== Address 0x59972f0 is 0 bytes inside a block of size 8,192 free'd
==305970== at 0x483FCE4: realloc (vg_replace_malloc.c:834)
==305970== by 0x4C986F7: _IO_mem_finish (in /usr/lib64/libc-2.33.so)
==305970== by 0x4C8F5E0: fclose@@GLIBC_2.2.5 (in /usr/lib64/libc-2.33.so)
==305970== by 0x49D2CDB: fclose_nointr (fd-util.c:108)
==305970== by 0x49D2D3D: safe_fclose (fd-util.c:124)
==305970== by 0x4A4BCCC: fclosep (fd-util.h:41)
==305970== by 0x4A4E00F: bus_match_to_string (bus-match.c:859)
==305970== by 0x4016C2: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970== Block was alloc'd at
==305970== at 0x483FAE5: calloc (vg_replace_malloc.c:760)
==305970== by 0x4C98787: open_memstream (in /usr/lib64/libc-2.33.so)
==305970== by 0x49D56D6: open_memstream_unlocked (fileio.c:97)
==305970== by 0x4A4DEC5: bus_match_to_string (bus-match.c:859)
==305970== by 0x4016C2: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970==
So the fclose() which is called from _cleanup_fclose_ clearly reallocates the
buffer (maybe to save memory?). open_memstream(3) says:
The locations referred to by these pointers are updated each time the
stream is flushed (fflush(3)) and when the stream is closed (fclose(3)).
This seems to mean that we should close the stream first before grabbing the
buffer pointer.
(cherry picked from commit 5963e6f43c4f33d5255ef0fb887cdf382bd51c9e)
(cherry picked from commit f8fd75183bcf9cd6b55c3f8e752863d0083ed772)
Nominally, the bug was in unit_load_dropin(), which just took the last mtime
instead of calculating the maximum. But instead of adding code to wrap the
loop, this patch goes in the other direction.
All (correct) callers of config_parse() followed a very similar pattern to
calculate the maximum mtime. So let's simplify things by making config_parse()
assume that mtime is initialized and update it to the maximum. This makes all
the callers that care about mtime simpler and also fixes the issue in
unit_load_dropin().
config_parse_many_nulstr() and config_parse_many() are different, because it
makes sense to call them just once, and current ret_mtime behaviour make sense.
Fixes#17730, https://bugzilla.redhat.com/show_bug.cgi?id=1933137.
(cherry picked from commit da46a1bc3cd28ac36114002c216196dae004b05c)
(cherry picked from commit b29181eaa50a0fd9cefc4bcfbd0e6949038b65c9)
BPF filtering accesses fields in the netlink header that are
only filled in by libudev, never by the kernel. Therefore adding
BPF filters for kernel monitors is pointless. Even false filtering
of kernel events might be possible; at least it's hard to prove that
it can't occur.
(cherry picked from commit d8ce385fe3e5be91b6f414415e10f8897e41d942)
(cherry picked from commit 8f67d7ba3af72b1b3750530c123702246f35987f)
Let's add a special tweak to the btrfs builtin: if /dev/btrfs-control is
not there, let's consider all btrfs file systems as SYSTEMD_READY=0.
This is useful in initrds, where btrfs.ko might be missing. After the
initrd → host transition we can then retigger the device and undo the
SYSTEMD_READY=0 marking.
(cherry picked from commit 97e535c7248cc0457395e2d62b6e7d6c342a0bd2)
(cherry picked from commit 3f94149a9bdf7267453f614aa85f1735913d91a2)
Let's generate the warning on a unit that actually needs the BPF
firewall, and not confusingly already for a sibling of one.
(cherry picked from commit a437c5e4da666d16f15649461ce45e0e6d735148)
(cherry picked from commit 6349fb59858618bf9b92e4abb77dc4027b2fd35f)
The firmware spec doesn't really say whether FilePath of the LoadedImage
protocol may be NULL or not. So far we assumed it to be non-NULL, but
apparently the FreeBSD UEFI chainloader sets it to NULL. Handle this
gracefully.
(Noticed and tracked down by Alexander Schreiber)
Fixes: #18733
(cherry picked from commit 685097b9cadf92d21dfa857c3a7ddc1ba115088e)
(cherry picked from commit 151c62b5bcb7124ec43fbd7e21872974e1d9e500)
Kernels can be compiled without the attribute. It's fine if this is not
set, so silence the warning.
(cherry picked from commit fa98c99ea7f7c5bec3962fa52f4d3496a9777024)
(cherry picked from commit 46c271feee9d660e79f93ae8ffc29955ebd8c61f)
See https://wiki.gnome.org/HowDoI/DBusApplicationLaunching and
https://wiki.gnome.org/Initiatives/GnomeGoals/DBusActivatable for a description
of this key:
> Instead of the typical UNIX-style fork()/exec() approach to process creation,
> launching an application is done by sending a D-Bus message to the well-known
> name of that application, causing a D-Bus activation.
>
> Starting processes with D-Bus activation ensures that each application gets
> started in its own pristine environment, as a direct descendent of the
> session -- not in the environment of whatever its parent happened to be. This
> is important for ensuring the app ends up in the correct cgroup, for example.
So this motivation is not important for us: we launch stuff ourselves better.
This fixes warnings during boot:
systemd-xdg-autostart-generator[2274]: /etc/xdg/autostart/org.freedesktop.problems.applet.desktop:92: Unknown key name 'DBusActivatable' in section 'Desktop Entry', ignoring.
(cherry picked from commit 36290e0b97ba032cbd71723f2255917924eadc05)
(cherry picked from commit 8e444ad2e2b9c1940bf54dceb2ac74c909abd286)
I'm seeing the following with kernel-core-5.10.16-200.fc33.x86_64:
$ sudo SYSTEMD_LOG_LEVEL=debug build/systemd-rfkill
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 0 and type bluetooth.
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
rfkill0: Operating on rfkill device 'tpacpi_bluetooth_sw'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/platform-thinkpad_acpi:bluetooth.
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 1 and type wwan.
rfkill1: Operating on rfkill device 'tpacpi_wwan_sw'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/platform-thinkpad_acpi:wwan.
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 2 and type bluetooth.
rfkill2: Operating on rfkill device 'hci0'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/pci-0000:00:14.0-usb-0:7:1.0:bluetooth.
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 3 and type wlan.
rfkill3: Operating on rfkill device 'phy0'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/pci-0000:04:00.0:wlan.
All events read and idle, exiting.
We were expecting a read of exactly RFKILL_EVENT_SIZE_V1==8 bytes. But the
structure has 9 after [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=14486c82612a177cb910980c70ba900827ca0894
For some reason the kernel does not accept the full structure size, but cuts
the write short after 8 bytes:
static ssize_t rfkill_fop_write(struct file *file, const char __user *buf,
size_t count, loff_t *pos)
{
struct rfkill_event ev;
/* we don't need the 'hard' variable but accept it */
if (count < RFKILL_EVENT_SIZE_V1 - 1)
return -EINVAL;
/*
* Copy as much data as we can accept into our 'ev' buffer,
* but tell userspace how much we've copied so it can determine
* our API version even in a write() call, if it cares.
*/
count = min(count, sizeof(ev));
if (copy_from_user(&ev, buf, count))
return -EFAULT;
... so it should accept the full size. I'm not sure what is going on here.
But we don't care about the extra fields, so let's accept a write as long as
it's at least RFKILL_EVENT_SIZE_V1.
Fixes#18677.
(cherry picked from commit a71c09685021cbcecb7566a00342421f635cc002)
(cherry picked from commit 310c58b1db09ed20bbb284f8b7f5fac5a169f16f)
If we get something of unexpected size, log the sizes. Also, don't log twice.
(cherry picked from commit 6c7afdeab010025c80508effd2b0039bc5181b82)
(cherry picked from commit c0e60c3079efa8d1d24ab83966b30da90d3d2ae0)
This was changed in commit 482efedc081b0c4bf2e77a3dee6b979d9c9a5765,
which was released in v243, to only enable and never disable IPv6.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
(cherry picked from commit f542f3b2ed3cf3e71692d1736f3fdd0ebdc226ef)
(cherry picked from commit 807d6dd157e67648dfb7ad8f8ff85a0b0a3db829)
The existing set_offline() short-circuit erroneously included
when f->archive was true and header->state was STATE_OFFLINE.
This commit makes the short-circuit f->archive aware, so it will
only catch scenarios where there's not an offlining in progress
and the header state matches the target state of either archived
or offline.
Fixes https://github.com/systemd/systemd/issues/17770
(cherry picked from commit bb1296b55a222cbab24d533006e730529009258c)
(cherry picked from commit 50e6c3b2e547aa29d1c5e160f9e5aa4dc9e07168)
Use the right FD, and do a fd_reopen instead of a dup, since the
latter will still share the internal pointer which then gets
moved by FOREACH_DIRENT, affecting the caller's FD.
(cherry picked from commit b8f762f2fe59c94323c95d2aadea68612dca2b04)
(cherry picked from commit 67e03400e881929ca0c940a4a51e76d3c68b6c29)
Downgrade the phrasing, since it is a bit misleading.
Fixes: #18465
(cherry picked from commit 71311efe2377d7e37a6af76f110882eed2332f4e)
(cherry picked from commit 884202fc1dcf1600c801ca68311530feee2fc1c2)
Don't run blkid on mmcblk[0-9]boot[0-9] devices because they contain
bootloaders or boot parameters, and not partitions or file systems.
(cherry picked from commit 8db704b28b4fd4d13e376cf3495005010443937e)
(cherry picked from commit 584a36e9f7c30d5ace1d734c2e1c4ed19b8393cb)
This use on %n was completely unnecessary: fprintf returns the number of
characters written. And the issue was that if fprintf failed for whatever
reason, it would not process the %n and m would be unitialized. Rework the
code a bit to simplify it.
Coverity CID#1444708.
(cherry picked from commit 333ab199a12c7b060d3a3f4d50a8f73ee4fd5ebd)
(cherry picked from commit dd04760980a0116267d33713348ae8c0f73a6052)
systemd-inhibit when invoked with a command line will put the whole
command line in the "who" field of the inhibitor lock. This can get
extremely long for shell expressions, making the table "systemd-inhibit
--list" shows ridiculously weirdly formatted. Let's put a limit on the
column width: half of the screen, not more.
(cherry picked from commit 619b0c077cbb12b85c9d752779095b99cfd2c66c)
(cherry picked from commit b5fc252d26beaab7aec7a51442db81001a5322e9)
If one field in a specific column has a maximum size limit, other fields
in the same column might affected by it and get less than they asked
for. Let's make sure we can handle this, and don't assert on this
because surprisingly we got less than what we asked for.
(cherry picked from commit 2cd9f773e29873df1b9f9b09c6c4f78853b16215)
(cherry picked from commit db3aaa0a661c993994194a60f1a24a1495496bab)
Aaargh. See the comment in the code.
Apparently the range is like that:
$ sudo bash -c 'echo "default 1001" >/sys/fs/cgroup/user.slice/io.bfq.weight'
bash: line 0: echo: write error: Numerical result out of range
$ uname -r
5.11.0-0.rc4.129.fc34.x86_64
(cherry picked from commit 29eb0eefd14afc9a2424781a28b376db47c3c570)
(cherry picked from commit c3ba9cb8f1b3ea0211123e1ae8e00bf7494ba233)
An (imperfect) fix for #14760.
This makes collisions unlikely, but still theoretically possible.
Fixes: #14760
(cherry picked from commit ac3bc1b819b66f925145629a5c2ccb0a098f0446)
Let's use uint32_t everywhere to maintain the seqno, since that's what
the kernel does. Prviously in the reply_callback logic we used 64bit,
for no apparent reason.
Using 32bit also provides us with the benefit that we can avoid using
uint64_hash_ops, and can use trivial_hash_ops instead for the reply
hashmap, so that we can store the seqno in the key pointer directly.
While we are at it, let's make sure we never run into serial collisions
internally (32bit is a lot, but not that much), and let's put a limit on
outstanding serials, to catch programming errors.
(cherry picked from commit b522c4b92a1a8999e008002f0a30acbaf58b55e4)
Apparently, there are plenty routers in place that report an incorrect
RR count in the packets: they declare more RRs than are actually
included.
Let's accept these responses, but let's downgrade them to baseline, i.e.
let's suppress OPT in this case: if they don't even get the RR count
right, let's operate on the absolute baseline, and not bother with
anything fancier such as EDNS.
Prompted-by: https://github.com/systemd/systemd/issues/12841#issuecomment-724063973Fixes: #3980
Most likely fixes: #12841
(cherry picked from commit 18674159ebbf622a9e6e5a45cc36b38f74dae315)
(cherry picked from commit fdfffdaf20a18a50c9a6d858359cf4af6d2f4c8b)
Follow-up for 4ea8b443de. The logic that manages DnsQueryCandidate is rather
complicated: a calls to dns_query_complete() that wants to destroy a
DnsQueryCandidate can be nested inside a deep chain of calls. Using reference
counts seems like the simplest approach.
DnsSearchDomain already uses reference counting.
This patch effectively brings dns_query_candidate_go() to the state before
4ea8b443de, but wraps the iteration over DnsQueryCandidate.transactions in
dns_query_candidate_ref+dns_query_candidate_unref.
(cherry picked from commit 0e0fd08fc832b8f42e567d722d388eba086da5ff)
(cherry picked from commit ab9f7e1a51005f12d3bac83b86716d9d33048eb7)
When dns_transaction_complete() manages to resolve a query, it invalidates the
query candidate object. It shall not be accessed afterwards.
We have the following chain of calls:
dns_query_candidate_go → dns_transaction_go → dns_transaction_prepare → dns_cache_lookup (success: 1)
→ dns_transaction_complete
After returning back to dns_query_candidate_go(), we'd attempt to continue
iteration over the list of transactions attached to the query candidate,
accessing already freed (and overwritten) memory:
(gdb) bt
0 0x00007f637297cf47 in hashmap_iterate_entry (i=0x7ffe7e15cc90, h=0x706f746b73656465) at ../src/basic/hashmap.c:703
1 _hashmap_iterate (h=0x706f746b73656465, i=i@entry=0x7ffe7e15cc90, value=value@entry=0x7ffe7e15cc88,
key=key@entry=0x0) at ../src/basic/hashmap.c:712
2 0x00007f637297d01b in set_iterate (s=<optimized out>, i=i@entry=0x7ffe7e15cc90, value=value@entry=0x7ffe7e15cc88)
at ../src/basic/hashmap.c:733
hence we crash
3 0x0000557bc99eb80f in dns_query_candidate_go (c=c@entry=0x557bcaf86890) at ../src/resolve/resolved-dns-query.c:139
...but c is not valid here in the second iteration of the loop
4 0x0000557bc99eb720 in dns_query_candidate_notify (c=0x557bcaf86890) at ../src/resolve/resolved-dns-query.c:271
c was valid here at entry...
5 0x0000557bc99efe28 in dns_transaction_complete (t=0x557bcac072f0, state=<optimized out>)
at ../src/resolve/resolved-dns-transaction.c:350
t is a valid transaction (11481 in the backtrace below)
6 0x0000557bc99f1efb in dns_transaction_process_reply (t=0x557bcac072f0, p=<optimized out>)
at ../src/resolve/resolved-dns-transaction.c:1171
7 0x0000557bc99f2d41 in on_dns_packet (s=<optimized out>, fd=<optimized out>, revents=<optimized out>,
userdata=0x557bcac072f0) at ../src/resolve/resolved-dns-transaction.c:1223
8 0x00007f6372a25217 in source_dispatch (s=s@entry=0x557bcb162c50) at ../src/libsystemd/sd-event/sd-event.c:3181
9 0x00007f6372a254fd in sd_event_dispatch (e=0x557bcb15b050) at ../src/libsystemd/sd-event/sd-event.c:3620
10 0x00007f6372a267c8 in sd_event_run (e=e@entry=0x557bcb15b050, timeout=timeout@entry=18446744073709551615)
at ../src/libsystemd/sd-event/sd-event.c:3678
11 0x00007f6372a269ef in sd_event_loop (e=0x557bcb15b050) at ../src/libsystemd/sd-event/sd-event.c:3700
12 0x0000557bc99ddc14 in run (argc=<optimized out>, argv=<optimized out>) at ../src/resolve/resolved.c:92
13 0x0000557bc99d260a in main (argc=<optimized out>, argv=<optimized out>) at ../src/resolve/resolved.c:99
xxx.name.net systemd-resolved[31705]: Got message type=method_call sender=:1.3644 destination=org.freedesktop.resolve1 path=/org/freedesktop/resolve1 interface=org.freedesktop.resolve1.Manager member=ResolveHostname cookie=2 reply_cookie=0 signature=isit error-name=n/a error-message=n/a
xxx.name.net systemd-resolved[31705]: idn2_lookup_u8: xxx → xxx
xxx.name.net systemd-resolved[31705]: Looking up RR for xxx IN A.
xxx.name.net systemd-resolved[31705]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=1102 reply_cookie=0 signature=s error-name=n/a error-message=n/a
xxx.name.net systemd-resolved[31705]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=GetNameOwner cookie=1103 reply_cookie=0 signature=s error-name=n/a error-message=n/a
xxx.name.net systemd-resolved[31705]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.3324 path=n/a interface=n/a member=n/a cookie=4294967295 reply_cookie=1103 signature=s error-name=n/a error-message=n/a
xxx.name.net systemd-resolved[31705]: Cache miss for xxx.name.net IN A
xxx.name.net systemd-resolved[31705]: Transaction 11481 for <xxx.name.net IN A> scope dns on enp42s0/*.
xxx.name.net systemd-resolved[31705]: Using feature level UDP for transaction 11481.
xxx.name.net systemd-resolved[31705]: Using DNS server 192.168.1.1 for transaction 11481.
xxx.name.net systemd-resolved[31705]: Sending query packet with id 11481 of size 35.
xxx.name.net systemd-resolved[31705]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.3324 path=n/a interface=n/a member=n/a cookie=4294967295 reply_cookie=1102 signature= error-name=n/a error-message=n/a
xxx.name.net systemd-resolved[31705]: Match type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.3644' successfully installed.
xxx.name.net systemd-resolved[31705]: Processing incoming packet on transaction 11481 (rcode=NXDOMAIN).
xxx.name.net systemd-resolved[31705]: Not caching negative entry without a SOA record: xxx.name.net IN A
xxx.name.net systemd-resolved[31705]: Transaction 11481 for <xxx.name.net IN A> on scope dns on enp42s0/* now complete with <rcode-failure> from network (unsigned).
xxx.name.net systemd-resolved[31705]: Positive cache hit for xxx.lan IN A
xxx.name.net systemd-resolved[31705]: Transaction 64364 for <xxx.lan IN A> on scope dns on enp42s0/* now complete with <success> from cache (unsigned).
xxx.name.net systemd-resolved[31705]: Sent message type=method_return sender=n/a destination=:1.3644 path=n/a interface=n/a member=n/a cookie=1104 reply_cookie=2 signature=a(iiay)st error-name=n/a error-message=n/a
xxx.name.net systemd-resolved[31705]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RemoveMatch cookie=1105 reply_cookie=0 signature=s error-name=n/a error-message=n/a
xxx.name.net systemd-resolved[31705]: Freeing transaction 64364.
xxx.name.net systemd[1]: systemd-resolved.service: Main process exited, code=dumped, status=11/SEGV
xxx.name.net systemd[1]: systemd-resolved.service: Failed with result 'core-dump'.
Fixes#16168, https://bugzilla.redhat.com/show_bug.cgi?id=1895937.
(cherry picked from commit 4ea8b443de8be0f7a932f325dfafa1ee2a843795)
(cherry picked from commit 64317106aed94a6fb758ab6b08ba490873fc5227)
So the currentl and only fd_is_mount_point() check is actually entirely
bogus: it passes "/" as filename argument, but that's not actually a
a valid filename, but an absolute path.
fd_is_mount_point() is written in a way tha the fd refers to a directory
and the specified path is a file directly below it that shall be
checked. The test call actually violated that rule, but still expected
success.
Let's fix this, and check for this explicitly, and refuse it.
Let's extend the test and move it to test-mountpoint-util.c where the
rest of the tests for related calls are placed.
Replaces: #18004Fixes: #17950
(cherry picked from commit 95231c7215c3ff14c491eb1d2a93312a8fe0c4f6)
(cherry picked from commit 551dd873b0bdfb9e7e47431b2933c8b910228f0c)
Apparently SELinux inserts control data into AF_UNIX datagrams where we
don't expect it, thus miscalculating the control data. This looks like
something to fix in SELinux, but we still should handle this gracefully
and just drop the offending datagram and continue.
recvmsg_safe() actually already drops the datagram, it's just a matter
of actually ignoring EXFULL (which it generates if control data is too
large) in the right places.
This does this wherever an AF_UNIX/SOCK_DGRAM socket is used with
recvmsg_safe() that is not just internal communication.
Fixes: #17795
Follow-up for: 3691bcf3c5eebdcca5b4f1c51c745441c57a6cd1
(cherry picked from commit 741bfd7f4e60fdc07ecaadbd93f1196dbee657ca)
(cherry picked from commit b7e0ac754eba3c91b76dc7b92802716144b569b8)
This variable (a.k.a. rootlibexecdir), was exposed through the .pc file, but
not as rpm macro.
The .pc file must be located in the package that provides libraries, which
pulls in a lot of dependencies. In Fedora, the macros are split out to a
separate package so that other packages which need to refer to some systemd
path but don't otherwise require it, can only pull in the (much smaller and
dependency-less) macros package. zram-generator uses the path to specify the
location of systemd-makefs, so by using the rpm macro we'll be able to use
a much smaller buildroot.
(cherry picked from commit 3bc66bfa0136e370a8f7b06c3b69a52f5636ef82)
(cherry picked from commit 490b9ae9dd786e0924cab59d578bb3d69a174079)
Previously, if an interface does not have SSID, e.g. run in mesh-point
type, then the wifi iftype obtained by the netlink call was ignored.
Fixes#18059.
(cherry picked from commit a66a402da471f6230ab8674fd2c1df6d918773b5)
(cherry picked from commit fc4eae72f8dd34a334b2707614d9c07974d4d604)
It looks like zero'ing the struct is not enough, and with some level
of optimizations there is still non-zero padding left over.
Switch to member-by-member initialization. Also convert all remaining
bpf_attr variables in other files.
(cherry picked from commit 9ca600e2bfacc52a65c89f3485723b2c27394e55)
(cherry picked from commit 95ee2c6b481b7a1f953cb720c35df568b7a6cb70)
(apparently overlayfs has issues with xattrs, hence don't require that
/usr supports xattrs)
(cherry picked from commit 84319c5c07e7283f31930c799dfd948d251d9b73)
(cherry picked from commit 3dcf950663f906db8a9baa465bd2ac384e832a46)
When building with Clang and using structured initialization, the
bpf_attr union is not zero-padded, so the kernel misdetects it as
an unsupported extension.
zero it until Clang's behaviour matches GCC. Do not skip the test
on Github Actions anymore.
(cherry picked from commit 28abf5ad3483a417d3d4de561533d282493a7f2a)
(cherry picked from commit 94bb28590b21f37bcd9b831029af05a8a78f49ef)
