udevadm trigger: log errors and return first failure
When udevadm trigger is called, the list of devices to trigger is always
generated through enumeration, and devices can come and go, so we should not
treat -ENOENT as a failure. But other types of failure should be logged.
It seems they were logged until baa30fbc2c04b23209d0b8fb3c86cd15ef9ea81a.
Also, return the first error. (I'm not sure if there are other failure modes
which we want to ignore. If they are, they'll need to be whitelisted like
-ENOENT.).
(before)
$ build/systemctl list-machines
Need to be root.
$ sudo build/systemctl list-machines
NAME STATE FAILED JOBS
krowka (host) running 0 0
rawhide running 0 0
2 machines listed.
(after)
$ build/systemctl list-machines
NAME STATE FAILED JOBS
krowka (host) running 0 0
rawhide n/a 0 0
2 machines listed.
The output for non-root is missing some bits of information, but we display
what information is missing nicely, and e.g. in the case when no machines are
running at all, or only VMs are running, the unprivileged output would be the
same as the privileged one.
The reasoning is the same as in previous cases. We get an error like
"Failed to update EFI variable: Operation not permitted" anyway, so
the check is not very useful.
If we lack permissions, we will fail anyway. But by not doing the artifial
check, we get more information. For example, on my machine, I see
$ build/systemd-bless-boot good
Not booted with boot counting in effect.
while "Need to be root" is actually untrue, because being root doesn't change
the outcome in any way.
Letting the operation fail on the actual error makes it easier to do test runs:
we *know* the command will fail, but we want to see what the first step would
be.
Not doing the articial check makes it also easier to do create alternative
security arrangements, for example where the directories are mounted with
special ownership mode and an otherwise unprivileged user can perform certain
operations.
Checking if we are root on the client side is generally pointless, since the
privileged operation will fail anyway and we can than log what precisly went
wrong.
A check like this makes sense only if:
- we need to do some expensive unprivileged operation before attempting the
privileged operation, and the check allows us avoid wasting resources.
- the privileged operation would fail but in an unclear way.
Neither of those cases applies here.
This fixes calls like 'udevadm control -h' as unprivileged user.
Yu Watanabe [Sat, 4 May 2019 18:03:44 +0000 (20:03 +0200)]
network: fix conditional jump depends on uninitialised value(s)
When address is in IPv4, the remaining buffer in in_addr_union may
not be initialized.
Fixes the following valgrind warning:
```
==13169== Conditional jump or move depends on uninitialised value(s)
==13169== at 0x137FF6: UnknownInlinedFun (networkd-ndisc.c:77)
==13169== by 0x137FF6: UnknownInlinedFun (networkd-ndisc.c:580)
==13169== by 0x137FF6: ndisc_handler.lto_priv.83 (networkd-ndisc.c:597)
==13169== by 0x11BE23: UnknownInlinedFun (sd-ndisc.c:201)
==13169== by 0x11BE23: ndisc_recv.lto_priv.174 (sd-ndisc.c:254)
==13169== by 0x4AA18CF: source_dispatch (sd-event.c:2821)
==13169== by 0x4AA1BC2: sd_event_dispatch (sd-event.c:3234)
==13169== by 0x4AA1D88: sd_event_run (sd-event.c:3291)
==13169== by 0x4AA1FAB: sd_event_loop (sd-event.c:3313)
==13169== by 0x117401: UnknownInlinedFun (networkd.c:113)
==13169== by 0x117401: main (networkd.c:120)
==13169== Uninitialised value was created by a stack allocation
==13169== at 0x1753C8: manager_rtnl_process_address (networkd-manager.c:479)
```
Yu Watanabe [Sat, 4 May 2019 17:43:45 +0000 (19:43 +0200)]
network: fix use-after-free
The function sd_radv_add_prefix() in dhcp6_pd_prefix_assign() may
return -EEXIST, and in that case the sd_radv_prefix object allocated
in dhcp6_pd_prefix_assign() will be freed when the function returns.
Hence, the key value in Manager::dhcp6_prefixes hashmap is lost.
Susant Sahani [Thu, 2 May 2019 09:52:03 +0000 (15:22 +0530)]
networkd: manager do not unef netlink and gennetlink early
Because of this the fd is getting closed and we getting errors
like
```
^Ceno1: Could not send rtnetlink message: Bad file descriptor
enp7s0f0: Could not send rtnetlink message: Bad file descriptor
enp7s0f0: Cannot delete unreachable route for DHCPv6 delegated subnet 2a0a:...:fc::/62: Bad file descriptor
Assertion '*_head == _item' failed at ../systemd/src/network/networkd-route.c:126, function route_free(). Aborting.
Aborted
```
Closes one of https://github.com/systemd/systemd/issues/12452
test: return a non-zero return code when 'nobody' user doesn't exist
Lookup of a non-existing user using getpwnam() is not considered
an error, thus the `errno` is not set appropriately, causing
unexpected fails on systems, where 'nobody' user doesn't exist by
default
Chris Chiu [Thu, 2 May 2019 10:10:22 +0000 (18:10 +0800)]
hwdb: Align airplane mode toggle key mapping for all Acer series
Packard Bell and Gateway are different marketing names from Acer.
The same scan code E0 86 is fired for the airplane mode toggle key.
It was verified in commit d8d51328fe6db33a2d8cda06f181c55c00d09672.
fstab-generator: Prevent double free of reused FILE*
When the .automount unit file already existed for any reason in the
`normal-dir` passed to `systemd-fstab-generator`, but the normal .mount unit
file did not, `f` was closed (but _not_ set to NULL). The call to
`generator_open_unit_file(..., automount_name, &f)` then failed because the
.mount unit file already existed. Now `f` did not point to an open FILE and the
later cleanup from the `_cleanup_fclose_` attribute failed with a double free.
Reset `f` to NULL before reusing it.
Instead of blindly using the extra allocated space, let's do so only
after telling libc about it, via a second realloc(). The second
realloc() should be quick, since it never has to copy memory around.
meson: make source files including nspawn-settings.h depend on libseccomp
Since nspawn-settings.h includes seccomp.h, any file that includes
nspawn-settings.h should depend on libseccomp so the correct header path where
seccomp.h lives is added to the header search paths.
It's especially important for distros such as openSUSE where seccomp.h is not
shipped in /usr/include but /usr/include/libseccomp.
coccinelle: further restrict certain transformations
Some transformations generate results we don't want to keep, so
let's disable such transformations for specific files.
Also, disable const-strlen.cocci everywhere, as the STRLEN macro has a
pretty limited scope, so the transformation generates false positives in
most cases.
When realloc() is called, the extra memory between the originally
requested size and the end of malloc_usable_size() isn't copied. (at
least with the version of glibc that currently ships on Arch Linux)
As a result, some elements get lost and use uninitialized memory, most
commonly 0, and can lead to crashes.
Hans de Goede [Mon, 22 Apr 2019 07:15:40 +0000 (09:15 +0200)]
hwdb: Fix F12 mapping on the Logitech Internet Navigator
Many Logitech keyboards have the following special functions on F9-F12:
F9: file-browser F10: document-browser F11: image-browser F12:
music-browser. These should be bound to:
#define KEY_FILE 144 /* AL Local Machine Browser */
#define KEY_DOCUMENTS 235
#define KEY_IMAGES 0x1ba /* AL Image Browser */
#define KEY_AUDIO 0x188 /* AL Audio Browser */
This commit fixes the wrong binding of F12 to KEY_SOUND (which
translates to XF86AudioPreset) and removes the ?? comments from
both F11 and F12.
Hans de Goede [Sun, 28 Apr 2019 19:21:00 +0000 (21:21 +0200)]
hwdb: Add key mappings for Logitech MX5500 keyboard
Add support for various custom key-codes emitted by the Logitech MX5500
keyboard, both when attached through its Bluetooth-receiver in USB-HID
proxy mode; and when connected as a Bluetooth device.
Hans de Goede [Tue, 2 Apr 2019 15:23:12 +0000 (17:23 +0200)]
hwdb: Add key mappings for Logitech MX5000 keyboard
Add support for various custom key-codes emitted by the Logitech MX5000
keyboard, both when attached through its Bluetooth-receiver in USB-HID
proxy mode; and when connected as a Bluetooth device.
Hans de Goede [Fri, 5 Apr 2019 12:47:04 +0000 (14:47 +0200)]
hwdb: Add key mappings for Logitech 27 MHz S520 keyboard
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the S520 keyboard
(modelnumber Y-RBA97).
Hans de Goede [Fri, 5 Apr 2019 14:18:03 +0000 (16:18 +0200)]
hwdb: Add key mappings for Logitech 27 MHz EX100 keyboard
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the EX100 keyboard
(modelnumber Y-RBH94).
Hans de Goede [Thu, 4 Apr 2019 22:40:40 +0000 (00:40 +0200)]
hwdb: Add key mappings for Logitech 27 MHz MX3200 keyboard
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the MX3200 keyboard
(modelnumber Y-RAV80).
Hans de Goede [Wed, 3 Apr 2019 20:52:06 +0000 (22:52 +0200)]
hwdb: Add key mappings for Logitech 27 MHz MX3000 keyboard
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the MX3000 keyboard
(modelnumber Y-RAM74).
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the "Logitech Rechargeable
Desktop" keyboard (modelnumber Y-RK49).
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the "Logitech Cordless
Access Keyboard" (modelnumber Y-RH35).
Hans de Goede [Thu, 4 Apr 2019 20:39:24 +0000 (22:39 +0200)]
hwdb: Add generic key mapping for Logitech 27 MHz keyboards
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This will allow us to add per model keymappings for the special keys on
these keyboards, which may differ per model.
This commit adds a default / fallback mapping, assigning the most common
meaning of the custom Logitech c10XX keycodes.
coccinelle: exclude certain paths from the transformations
There's no point in running these transformation for certain files,
mainly anything from src/boot/efi and src/shared/linux, as this code
doesn't have access to our internal utility functions
basic/virt: try the /proc/1/sched hack also for PID1
If a container manager does not set $container, we could end up
in a strange situation when detect-virt returns container-other when
run as non-pid-1 and none when run as pid-1.
The link may not have corresponding .network file.
Note that in that case, link_ipv4ll_enabled() and link_dhcp4_enabled()
returns false. So, it is safe to drop the assertion.
coccinelle: avoid matching 'errno' as a file descriptor
The `coccinelle/take-fd.cocci` transformation file attempts to rewrite
r = fd;
fd = -1;
to
r = TAKE_FD(fd);
Unfortunately, using `identifier` or `idexpression` as a metavariable
type in this case wouldn't match more complex location descriptions,
like:
x->fd = fd
fd = -1;
Using 'expression' metavariable type generates false positives,
as you can't specify scope of such expression. The only real example
from the current codebase is the global 'errno' variable, which results
in following patch generated by `spatch`:
Let's explicitly state that the matched expression should not equal
'errno' to avoid this. It's not particularly nice, but it should be
enough, at least for now.
Coccinelle needs a custom isomorphism file with rules (isomorphisms) how
to correctly rewrite conditions with explicit NULL checks (i.e.
if (ptr == NULL)) to their shorter form (i.e. if (!ptr)). Coccinelle
already contains such isomorphisms in its default .iso file, however,
they're in the opposite direction, which results in useless output from
coccinelle/equals-null.cocci.
With this fix, `spatch` should no longer report patches like:
@@ -628,8 +628,9 @@ static int path_deserialize_item(Unit *u
f = path_result_from_string(value);
if (f < 0)
log_unit_debug(u, "Failed to parse result value: %s", value);
- else if (f != PATH_SUCCESS)
- p->result = f;
+ else {if (f != PATH_SUCCESS)
+ p->result = f;
+ }
projects / thirdparty / systemd.git / log
