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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit f699bd81e8 (#22063)
We should suppress the TSC data when we generate it if we assume its
invalid, not when we consume it, because at that point we don't even
know if the data stems from TSC or something else.
Apparently 2G is too low for various real-life systems. But raising it
universally above 2^32 sounds wrong to me, since that makes no sense on
32bit systems, that we still support.
Hence, let's raise the limit to 32G on 64bit systems, and *lower* it to
1G on 32bit systems.
32G is 4 orders of magnitude higher then the old settings. Let's hope
that's enough for now. Should this not be enough we can raise it
further.
Fixes: #22076
This queries the sector size from libfdisk instead of assuming 512, and
uses that when converting from bytes to the offset/size values libfdisk
expects.
This is an alternative to Tom Yan's #21823, but prefers using libfdisk's
own ideas of the sector size instead of going directly to the backing
device via ioctls. (libfdisk can after all also operate on regular
files, where the sector size concept doesn't necessarily apply the same
way.)
This also makes the "grain" variable, i.e. how we'll align the
partitions. Previously this was hardcoded to 4K, and that still will be
the minimum grain we use, but should the sector size be larger than that
we'll use the next multiple of the sector size instead.
If the query get CNAME or DNAME, then the query will be restarted.
Even in that case, previously, the event source was freed and allocated
again. Let's slightly optimize it.
Fortunately, unlike the issue fixed in the previous commit, the memleak
should be superficial and not become apparent, as the queries handled
here are managed by the stub stream, and will be freed when the stream
is closed.
Just for safety, and slightly reducing the runtime memory usage by the
stub stream.
When stub stream is closed early, then queries associated to the stream
are freed. Previously, the timer event source for queries may not be
disabled, hence may be triggered with already freed query.
See also dns_stub_stream_complete().
Note that we usually not set NULL or zero when freeing simple objects.
But, here DnsQuery is large and complicated object, and the element may
be referenced in subsequent freeing process in the future. Hence, for
safety, let's set NULL to the pointer.
This is a follow up to 29f4185a9c ("oomd: Dump top offenders after a
kill action") to clean up the code a bit for review comments that
happened after the code had been merged already.
Coverity (and I, initially) get really confused about "fn"'s validity
here. it doesn't grok that free_and_strdup() is actually a NOP in case
the string isn't changed, and assumes it always invalidates the
specified buffer, which it doesn't do though.
Follow-up for: f4b1a6b641
If we're going upwards in the journal file during entry iteration and we
can't reach the current entry due to corruption, start iterating upwards
from the last reachable entry array. This is equivalent to skipping
all entries in the array that can't be reached anymore.
Fixes#22431
8d801e35cb didn't take into account
upwards iteration of entry items when we're working on a corrupted
journal file. Instead of moving to the previous entry array, we'd
always move to the next array, regardless of the iteration direction.
To fix this, we introduce bump_entry_array() that moves to the next
or previous entry array depending on the given direction. Since the
entry array chains are singly linked lists, we have to start iterating
from the front to find the previous array. We only reach this logic
if we're working on a corrupted journal file so being slow here shouldn't
matter too much.
Fixes an assertion failure "pd->type == SD_DHCP6_OPTION_IA_PD" in dhcp6_option_append_pd().
Something similar was done in commit 26a63b8132 ('sd-dhcp6-client: Fix
sending prefix delegation request (#17136)'). The justification is
probably the same.
In D-Bus, clients connect to a bus (the usual case), or use direct
questions to each other (the unusual case). A bus is a program one can
connect to and implemented by dbus-daemon or dbus-broker. HOwever,
busses never connect between each other, that doesn't exist. Hence don't
claim so.
This is probably confusion about the fact that sd-bus calls D-Bus
connection objects just "sd_bus" for simplicity, given they are used in
99% of the cases to connect to a bus — only in exceptional cases they
are used for direct connections between peers without involving a bus.
Follow-up for b7bb58ef70
Apparently the error code fallocate() returns if hole punching is not
supported is not too well defined (man page just says "an error is
returned"), hence let's accept the usual set of errors, and the
normalize it to EOPNOTSUPP, and generate a clear error message in this
case.
This basically reverts #22079.
Stopping the watchdog is wrong. The reboot watchdog is supposed to cover
the whole time from the point when systemd start systemd-reboot until the
hardware resets.
Otherwise the system may hang in the final shutdown phase.
Add a comment, why keeping the watchdog running is correct here.
If watchdog_set_device() is not called before open_watchdog() then
'watchdog_device' remains 'NULL' while the device is open.
As a result, the "same device" check in watchdog_set_device() does not work
correctly: If no device is specified (e.g. from watchdog_free_device())
then the current fd is not closed.
Fix this by setting 'watchdog_device' to the correct device during
open_watchdog()
Since a long time the D-Bus spec knows a special bit in its message
header for indicating that "interactive" authentication is OK. The
original hostnamed API is before that was added hence most functions
expose that boolean as explicit argument.
For new added functions let's get rid of it, the message flag is good
enough and replaces it with complete functionality.
No new APIs should carry the "interactive" boolean flag explicitly as
argument anymore.
Follow-up for: 9697662915
