| Age | Commit message (Collapse) | Author |
|---|
|
The barrier implementation tracks remote states internally. There is no
need to check the return value of any barrier_*() function if the caller
is not interested in the result. The barrier helpers only return the state
of the remote side, which is usually not interesting as later calls to
barrier_sync() will catch this, anyway.
Shut up coverity by explicitly ignoring return values of barrier_place()
if we're not interested in it.
|
|
Imagine a constructor like this:
int object_new(void **out) {
void *my_object;
int r;
...
r = ioctl(...);
if (r < 0)
return -errno;
...
*out = my_object;
return 0;
}
We have a lot of those in systemd. If you now call those, gcc might inline
the call and optimize it. However, gcc cannot know that "errno" is
negative if "r" is. Therefore, a caller like this will produce warnings:
r = object_new(&obj);
if (r < 0)
return r;
obj->xyz = "foobar";
In case the ioctl in the constructor fails, gcc might assume "errno" is 0
and thus the error-handling is not triggered. Therefore, "obj" is
uninitialized, but accessed. Gcc will warn about that.
The new negative_errno() helper can be used to mitigate those warnings.
The helper is guaranteed to return a negative integer. Furthermore, it
spills out runtime warnings if "errno" is non-negative.
Instead of returning "-errno", you can use:
return negative_errno();
gcc will no longer assume that this can return >=0, thus, it will not warn
about it.
Use this new helper in libsystemd-terminal to fix some grdev-drm warnings.
|
|
This macro exists for MIPS since v3.17:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=42944521af97a3b25516f15f3149aec3779656dc
|
|
This complements the fix in:
commit cd4c6fb12598435fe24431f1dd616f9582f0e3bd
Author: Jan Synacek <jsynacek@redhat.com>
Date: Mon Oct 20 12:43:39 2014 +0200
man: fix localectl set-x11-keymap syntax description
|
|
|
|
|
|
always pass along comm, as documented by audit. Always set the correct
comm value.
|
|
have anyway
|
|
A small readability improvement...
|
|
Let's make the log output more readable, and the header can be
reconstructed in full from the other fields
|
|
|
|
Similar to auditd actually turn on auditing as we are starting. This way
we can operate entirely without auditd around.
|
|
audit doesn't support timestamps anyway
|
|
|
|
|
|
|
|
journal files based on a size/time limit
This is equivalent to the effect of SystemMaxUse= and RetentionSec=,
however can be invoked directly instead of implicitly.
|
|
|
|
|
|
|
|
And conditionalize journald audit support with it
|
|
|
|
|
|
|
|
|
|
This is just an example, so no error-handling is done here anyway.
|
|
On older kernels before this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e8b671460410c8fd996c8a1c228b718c547cc236
ppp-ioctl.h did not pull in ppp_defs.h which results in build errors
|
|
Otherwise we could attempt to flush the journal while /var/log/ was
still ro, and silently skip journal flushing.
The way that errors in flushing are handled should still be changed to
be more transparent and robust.
|
|
Since commit 19f8d037833f2 'timer: order OnCalendar units after
timer-sync.target if DefaultDependencies=no' timers might get a
dependency on time-sync.target, which does not really belong in early
boot. If ntp is enabled, time-sync.target might be delayed until a
network connection is established.
It turns out that majority of timer units found in the wild do not
need to be started in early boot. Out of the timer units available in
Fedora 21, only systemd-readahead-done.timer and mdadm-last-resort@.timer
should be started early, but they both have DefaultDependencies=no,
so are not part of timers.target anyway. All the rest look like they
will be fine with being started a bit later (and the majority even
much later, since they run daily or weekly).
Let timers.target be pulled in by basic.target, but without the
temporal dependency. This means timer units are started on a "best
effort" schedule.
https://bugzilla.redhat.com/show_bug.cgi?id=1158206
|
|
|
|
This way they always show up together with 'Found ordering cycle...'.
Ordering cycles are a serious error and a major pain to debug. If
quiet is enabled, only the first and the last line of output are
shown:
systemd[1]: Found ordering cycle on basic.target/start
systemd[1]: Breaking ordering cycle by deleting job timers.target/start
systemd[1]: Job timers.target/start deleted to break ordering cycle starting with basic.target/start
which isn't particularly enlightening. So just show the whole message
at the same level.
https://bugzilla.redhat.com/show_bug.cgi?id=1158206
|
|
|
|
This library negotiates a PPPoE channel. It handles the discovery stage and
leaves the session stage to the kernel. A further PPP library is needed to
actually set up a PPP unit (negotatie LCP, IPCP and do authentication), so in
isolation this is not yet very useful.
The test program has two modes:
# ./test-pppoe
will create a veth tunnel in a new network namespace, start pppoe-server on one
end and this client library on the other. The pppd server will time out as no
LCP is performed, and the client will then shut down gracefully.
# ./test-pppoe eth0
will run the client on eth0 (or any other netdev), and requires a PPPoE server
to be reachable on the local link.
|
|
FILE * wants cleanup_fclose().
Spotted by udev hwdb segfaulting in gnome-continuous' buildroot
construction.
|
|
s/threat/treat/g
|
|
|
|
A recent commit (2f3a215) changed the parsing of /proc/cmdline to use a
shell array. Unfortunately, this introduced a bug: "read -ar line"
populates the shell variable $r, not $line. This breaks installation of
new loader entries:
# kernel-install add 3.17.1-304.fc21.x86_64 \
/boot/vmlinuz-3.17.1-304.fc21.x86_64
Could not determine the kernel command line parameters.
Please specify the kernel command line in /etc/kernel/cmdline!
This commit alters the read command to correctly populate the $line
array instead.
|
|
This service is now synchronous, so "trigger" is misleading.
|
|
|
|
|
|
|
|
The duid data passed by the caller does not include the DUID type,
but sd_dhcp6_client_set_duid() was treating it like it did.
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=85657
|
|
The term "priority" is misleading because higher levels have lower
priority. "Level" is clearer and shorter.
This commit touches only the textual descriptions, not function and variable
names themselves. "Priority" is used in various command-line switches and
protocol constants, so completly getting rid of "priority" is hard.
I also left "priority" in various places where the clarity suffered
when it was removed.
|
|
Invalid log levels lead to a assert failure later on.
https://bugs.freedesktop.org/show_bug.cgi?id=85657
|
|
This brings udev logging style a bit closer to normal systemd convention.
|
|
Also change the default prefixlen function to only access the first octet of the in_addr.
|
|
|
|
|
