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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
oomd.conf has two parameters with fractionals: SwapUsedLimit= and
DefaultMemoryPressureLimit=, but one accepts permyriads, the other only
percentages, for no apparent reason. One carries the "Percent" in the
name, the other doesn't.
Let's clean this up: always accept permyriads, and drop the suffix,
given that it is misleading.
I figure we should internally try to focus on scaling everything
relative to UINT32_MAX, and if that isn't in the cards at least 10000,
but never permille nor percent unless there's a really really good
reason for it (e.g. interface defined by someone else).
So far OOMD limits used permyriads, as an upgrade from the original
percent.
The rest of our codebase typically scales stuff relative to UINT32_MAX.
Let's clean this up, an make sure this happens here too. This is
particularly relevant, as this is exposed in unit files and API, and
before we mark this stable we should get the APIs right.
Let's define a set of macros for making output of permyriad values easy.
They are printed in pure ASCII, i.e. without the permille/permyriad
suffix, using just percent and two places after the dot.
At various places we accept values scaled to the range 0…2^32-1 which
are exposed to the user as percentages/permille/permyriad. Let's add
some helper macros (actually: typesafe macro-like functions) that help
with converting our internal encoding to the external encodings.
benefits: some of the previous code rounded up, some down. let's always
round to nearest, to ensure that our conversions are reversible. Also,
check for overflows correctly.
This also adds a test that makes sure that for the full
percent/permille/permyriad ranges we can convert forth and back without
loss of accuracy.
Previously, when parsing myriads, we'd support:
x% → percent, no places after the dot
x.yz% → percent, two places after the dot
x‰ → permille, no places after the dot
x.y‰ → permille, one place after the dot
x‱ → permyriad, no places after the dot
What's missing is:
x.y% → percent, one place after the dot
Let's add it in.
A good chunk of parse-util.[ch] has been about parsing parts per
hundred/thousand/ten-thousand. Let's split that out into its own file.
No code changes, just some shuffling around.
Given that we now have a parser for permyriads, let's use it everywhere
for greater accuracy. This means wherever we previously supported % and
‰, we now also support ‱.
The additional rules fix a firmware bug in the en keyboard of Librem notebooks by Purism.
By doing so the break the keyboard with other layouts which do not have the same bug in their firmware.
This doesn't really change anything, but feels nicer, since it abstracts
away what device_action_from_string()/device_action_to_string() do
internally, and always uses a normalized action string (yes, there's no
ambiguity, but it's nice to stay abstract, maybe one day there is
ambiguity around this)
To make sd-device properly usable for all programs we need to provide an
API for the "action" field of an event, it's one of the most relevant
ones, and it was so far missing.
This also adds sd_device_get_seqnum(), which isn't that interesting,
except for generating pretty debug output, which we use it ourselves
for.
This also makes device_new_from_stat_rdev() public, as it is truly
useful, as we can see in our own uses of it, and I think is fairly
generic to show up in the public APIs.
Apparently, in our current public headers (i.e. those called sd-*.h) we
suffixed typedefs that we use as values with _t, but we didn't do this
for enum typedefs. Fix that while this stuff is not actually public yet.
With this scheme "value typedefs" now end systematically in _t, and
"object typedefs" (i.e. structures that are typically passed around via
pointers and not values) do not.
No code changes, just some renaming.
Fragmenting sucks, let's avoid it. Thus let's start tracking the maximum
fragment size we receive.
Also, let's redo a transaction via TCP if we see fragmenting on UDP, as
effective mitigation against DNS fragment attacks.
Let's take all MTU info we possibly have into account, i.e. the one
reported via netlink, as before and the one the socket might now (from
PMTUD and such), clamped by our own ideas.
We can later use this to adapt our announced EDNS buffer size in order
to avoid fragmentation to make the best of large datagrams while still
avoiding he security weaknesses of it.
A "Credentials" section name in systemd.exec man page was used
both for User/Group and for actual credentials support in systemd.
Rename the first instance to "User/Group Identity"
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.
This was changed in commit 482efedc08,
which was released in v243, to only enable and never disable IPv6.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
