| Age | Commit message (Collapse) | Author |
|---|
|
the pid list will be accessed inside the SIGCHLD signal handler. so we
must ensure SIGCHLD handler doesn't get invoked while the list is at an
inconsistent state making it unsafe to interact with.
Co-authored-by: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Bug: https://github.com/OpenRC/openrc/issues/589#issuecomment-1406588576
|
|
`free` is not async-signal-safe and calling it inside a signal handler
can have bad effects, as reported in the musl ML:
https://www.openwall.com/lists/musl/2023/01/23/1
the solution:
- keep track of weather remove_pid() is being called from inside a
signal handler or not.
- if it's inside a signal handler then DO NOT call free - instead put
that pointer into a "to be freed later" list.
- if it's not inside a signal handler then take the "to be freed later"
list and free anything in it.
Bug: https://github.com/OpenRC/openrc/issues/589
Reported-by: Dominique MARTINET <dominique.martinet@atmark-techno.com>
|
|
|
|
problem:
* vfork has been removed from POSIX [0].
* clang-tidy flags the `strerror` and `eerror` call inside the vfork-ed
child as undefined behavior.
solution: use posix_spawnp, which is serves similar purpose and is
specified in posix. and as an added bonus, it's also easier to use and
less lines of code.
[0]: https://www.man7.org/linux/man-pages/man2/vfork.2.html#CONFORMING_TO
|
|
Make function declarations use the EINFO_RESTRICT macro instead of
__EINFO_RESTRICT which gets treated as the name of the argument.
|
|
Thanks to vapier for noticing.
|
|
This conflicts with linux-headers which uses __unused for some padding members
on ppc64le at least.
Closes: https://github.com/OpenRC/openrc/issues/622
|
|
this was mistakenly changed to 2023 instead of 2022-2023 in 63a5ee3d
|
|
|
|
|
|
`seed_dir` gets allocated via xstrdup but never gets freed - which
clang-tidy flags as a memory leak.
instead of free-ing the allocation, just don't allocate to begin with
since there's no need for it.
also bump the copyright year.
|
|
same rational as 459783bb
Bug: https://github.com/OpenRC/openrc/issues/589
|
|
same rational as 459783bb
Bug: https://github.com/OpenRC/openrc/issues/589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
this was reported by codeql's scan as a TOCTOU bug. while that's true in
theory, i don't believe it would've had any practical effect.
a better justification for this change might be the fact that it
upgrades from `utime` (which is depreciated by POSIX [0]) to `futimens`.
[0]: https://www.man7.org/linux/man-pages/man3/utime.3p.html#FUTURE_DIRECTIONS
|
|
malloc (called by xasprintf) is not async-signal-safe. beside, the
string here is constant, so there's no need to malloc it all.
eerrorx isn't async-signal-safe either (due to calling fprintf and exit)
but consequence of them are _typically_ not as grave as calling malloc
while it's internal state is inconsistent.
Bug: https://github.com/OpenRC/openrc/issues/589
|
|
|
|
For -Wmissing-noreturn.
|
|
For -Wmissing-noreturn.
|
