History log of /netbsd-src/sys/kern/kern_exec.c (Results 1 – 25 of 525)
Revision Date Author Comments
# 09bb7d6a 06-Dec-2024 riastradh <riastradh@NetBSD.org>

sys/kern/kern_exec.c, exec_*.c: Nix trailing whitespace.

No functional change intended.


# b5090f27 06-Dec-2024 riastradh <riastradh@NetBSD.org>

sys/kern/kern_exec.c, exec_*.c: Sprinkle SET_ERROR dtrace probes.

PR kern/58378: Kernel error code origination lacks dtrace probes


# f47e8594 06-Dec-2024 riastradh <riastradh@NetBSD.org>

sys/kern/kern_exec.c, exec_*.c: Sort includes.

No functional change intended.


# 8dcf088f 10-Nov-2024 mlelstv <mlelstv@NetBSD.org>

Add missing rw_exit() in error path.


# 9f323629 08-Oct-2023 ad <ad@NetBSD.org>

Defer some wakeups till lock release.


# 0f335007 04-Oct-2023 ad <ad@NetBSD.org>

kauth_cred_hold(): return cred verbatim so that donating a reference to
another data structure can be done more elegantly.


# 0a6ca13b 04-Oct-2023 ad <ad@NetBSD.org>

Eliminate l->l_biglocks. Originally I think it had a use but these days a
local variable will do.


# e04f4645 01-Jul-2022 riastradh <riastradh@NetBSD.org>

posix_spawn(2): Plug leak in proc_alloc error branch.


# ef3476fb 09-Apr-2022 riastradh <riastradh@NetBSD.org>

sys: Use membar_release/acquire around reference drop.

This just goes through my recent reference count membar audit and
changes membar_exit to membar_release and membar_enter to
membar_acquire -- t

sys: Use membar_release/acquire around reference drop.

This just goes through my recent reference count membar audit and
changes membar_exit to membar_release and membar_enter to
membar_acquire -- this should make everything cheaper on most CPUs
without hurting correctness, because membar_acquire is generally
cheaper than membar_enter.

show more ...


# 122a3e8a 12-Mar-2022 riastradh <riastradh@NetBSD.org>

sys: Membar audit around reference count releases.

If two threads are using an object that is freed when the reference
count goes to zero, we need to ensure that all memory operations
related to the

sys: Membar audit around reference count releases.

If two threads are using an object that is freed when the reference
count goes to zero, we need to ensure that all memory operations
related to the object happen before freeing the object.

Using an atomic_dec_uint_nv(&refcnt) == 0 ensures that only one
thread takes responsibility for freeing, but it's not enough to
ensure that the other thread's memory operations happen before the
freeing.

Consider:

Thread A Thread B
obj->foo = 42; obj->baz = 73;
mumble(&obj->bar); grumble(&obj->quux);
/* membar_exit(); */ /* membar_exit(); */
atomic_dec -- not last atomic_dec -- last
/* membar_enter(); */
KASSERT(invariant(obj->foo,
obj->bar));
free_stuff(obj);

The memory barriers ensure that

obj->foo = 42;
mumble(&obj->bar);

in thread A happens before

KASSERT(invariant(obj->foo, obj->bar));
free_stuff(obj);

in thread B. Without them, this ordering is not guaranteed.

So in general it is necessary to do

membar_exit();
if (atomic_dec_uint_nv(&obj->refcnt) != 0)
return;
membar_enter();

to release a reference, for the `last one out hit the lights' style
of reference counting. (This is in contrast to the style where one
thread blocks new references and then waits under a lock for existing
ones to drain with a condvar -- no membar needed thanks to mutex(9).)

I searched for atomic_dec to find all these. Obviously we ought to
have a better abstraction for this because there's so much copypasta.
This is a stop-gap measure to fix actual bugs until we have that. It
would be nice if an abstraction could gracefully handle the different
styles of reference counting in use -- some years ago I drafted an
API for this, but making it cover everything got a little out of hand
(particularly with struct vnode::v_usecount) and I ended up setting
it aside to work on psref/localcount instead for better scalability.

I got bored of adding #ifdef __HAVE_ATOMIC_AS_MEMBAR everywhere, so I
only put it on things that look performance-critical on 5sec review.
We should really adopt membar_enter_preatomic/membar_exit_postatomic
or something (except they are applicable only to atomic r/m/w, not to
atomic_load/store_*, making the naming annoying) and get rid of all
the ifdefs.

show more ...


# df008c2b 05-Feb-2022 christos <christos@NetBSD.org>

Prevent escallation of privilege due to poor handling of argc == 0 in set*id
binaries by refusing to execute them.


# d9c43f29 26-Nov-2021 ryo <ryo@NetBSD.org>

Fix anonymous memory object leak for sigcode.

- Repeating "modload compat_linux && /emul/linux/bin/ls && modunload compat_linux"
will reproduce this problem.
- It cause in exec_sigcode_map(), anon

Fix anonymous memory object leak for sigcode.

- Repeating "modload compat_linux && /emul/linux/bin/ls && modunload compat_linux"
will reproduce this problem.
- It cause in exec_sigcode_map(), anon-object for sigcode was created at
first exec, but it remained even after exec_remove.
- Fixed that the anon-object for sigcode is created at exec_add(), and the
anon-object reference is removed at exec_remove().
- sigobject_lock is no longer needed since it is locked by exec_lock.
- The compat_16 module rewrites the e_sigcode entry in emul_netbsd directly and
does not use exec_add()/exec_remove(), so it needs to call
sigcode_alloc()/sigcode_free() on its own.

show more ...


# 4754a9ec 25-Nov-2021 ryo <ryo@NetBSD.org>

Reverte my previous changes kern_exec.c r1.512. It panics.

This changes was insufficient because es_emul is referenced by multiple execsw.


# 482faf0e 25-Nov-2021 ryo <ryo@NetBSD.org>

Fix anonymous memory object leak for sigcode.

- Repeating "modload compat_linux && /emul/linux/bin/ls && modunload compat_linux"
will reproduce this problem.
- It cause in exec_sigcode_map(), anon

Fix anonymous memory object leak for sigcode.

- Repeating "modload compat_linux && /emul/linux/bin/ls && modunload compat_linux"
will reproduce this problem.
- It cause in exec_sigcode_map(), anon-object for sigcode was created at
first exec, but it remained even after exec_remove.
- Fixed that the anon-object for sigcode is created at exec_add(), and the
anon-object reference is removed at exec_remove().
- sigobject_lock is no longer needed since it is locked by exec_lock.

show more ...


# 1a7d57ca 07-Nov-2021 christos <christos@NetBSD.org>

Merge the kernel portion of the posix-spawn-chdir project by Piyush Sachdeva.


# 263f7b1e 10-Oct-2021 thorpej <thorpej@NetBSD.org>

Changes to make EVFILT_PROC MP-safe:

Because the locking protocol around processes is somewhat complex
compared to other events that can be posted on kqueues, introduce
new functions for posting NOT

Changes to make EVFILT_PROC MP-safe:

Because the locking protocol around processes is somewhat complex
compared to other events that can be posted on kqueues, introduce
new functions for posting NOTE_EXEC, NOTE_EXIT, and NOTE_FORK,
rather than just using the generic knote() function. These functions
KASSERT() their locking expectations, and deal with other complexities
for each situation.

knote_proc_fork(), in particiular, needs to handle NOTE_TRACK, which
requires allocation of a new knote to attach to the child process. We
don't want to be allocating memory while holding the parent's p_lock.
Furthermore, we also have to attach the tracking note to the child
process, which means we have to acquire the child's p_lock.

So, to handle all this, we introduce some additional synchronization
infrastructure around the 'knote' structure:

- Add the ability to mark a knote as being in a state of flux. Knotes
in this state are guaranteed not to be detached/deleted, thus allowing
a code path drop other locks after putting a knote in this state.

- Code paths that wish to detach/delete a knote must first check if the
knote is in-flux. If so, they must wait for it to quiesce. Because
multiple threads of execution may attempt this concurrently, a mechanism
exists for a single LWP to claim the detach responsibility; all other
threads simply wait for the knote to disappear before they can make
further progress.

- When kqueue_scan() encounters an in-flux knote, it simply treats the
situation just like encountering another thread's queue marker -- wait
for the flux to settle and continue on.

(The "in-flux knote" idea was inspired by FreeBSD, but this works differently
from their implementation, as the two kqueue implementations have diverged
quite a bit.)

knote_proc_fork() uses this infrastructure to implement NOTE_TRACK like so:

- Attempt to put the original tracking knote into a state of flux; if this
fails (because the note has a detach pending), we skip all processing
(the original process has lost interest, and we simply won the race).

- Once the note is in-flux, drop the kq and forking process's locks, and
allocate 2 knotes: one to post the NOTE_CHILD event, and one to attach
a new NOTE_TRACK to the child process. Notably, we do NOT go through
kqueue_register() to do this, but rather do all of the work directly
and KASSERT() our assumptions; this allows us to directly control our
interaction with locks. All memory allocations here are performed with
KM_NOSLEEP, in order to prevent holding the original knote in-flux
indefinitely.

- Because the NOTE_TRACK use case adds knotes to kqueues through a
sort of back-door mechanism, we must serialize with the closing of
the destination kqueue's file descriptor, so steal another bit from
the kq_count field to notify other threads that a kqueue is on its
way out to prevent new knotes from being enqueued while the close
path detaches them.

In addition to fixing EVFILT_PROC's reliance on KERNEL_LOCK, this also
fixes a long-standing bug whereby a NOTE_CHILD event could be dropped
if the child process exited before the interested process received the
NOTE_CHILD event (the same knote would be used to deliver the NOTE_EXIT
event, and would clobber the NOTE_CHILD's 'data' field).

Add a bunch of comments to explain what's going on in various critical
sections, and sprinkle additional KASSERT()s to validate assumptions
in several more locations.

show more ...


# 4146ac03 28-Sep-2021 thorpej <thorpej@NetBSD.org>

Make sure the robust futex head is zeroed out, since this LWP
will live on with a different program image. (Thanks ryo@ for
pointing out my mistake.)


# 978ef622 28-Sep-2021 thorpej <thorpej@NetBSD.org>

futex_release_all_lwp(): No need to pass the "tid" argument separately; that
is a vestige of an older version of the code. Also, move a KASSERT() that
both futex_release_all_lwp() call sites had ins

futex_release_all_lwp(): No need to pass the "tid" argument separately; that
is a vestige of an older version of the code. Also, move a KASSERT() that
both futex_release_all_lwp() call sites had inside of futex_release_all_lwp()
itself.

show more ...


# 6129c025 28-Sep-2021 thorpej <thorpej@NetBSD.org>

In the exec path, multi-LWP programs dispose of their robust futexes
by calling exit_lwps(), except for the last LWP. So, dispose of that
LWP's robust futexes right before calling lwp_ctl_exit().

F

In the exec path, multi-LWP programs dispose of their robust futexes
by calling exit_lwps(), except for the last LWP. So, dispose of that
LWP's robust futexes right before calling lwp_ctl_exit().

Fixes a "WARNING: ... : unmapped robust futex list head" message when
running bash under Linux emulation on aarch64.

Root caused and patch proposed by ryo@. I have tweaked it slightly,
just to add a comment and a KASSERT().

show more ...


# d8862951 11-Jun-2021 martin <martin@NetBSD.org>

Fix the order of handling of posix_spawn attributes and file actions.
The standard is explicit about it and it matters if e.g. RESETIDS is
used as an attribute and file actions depend on the group ri

Fix the order of handling of posix_spawn attributes and file actions.
The standard is explicit about it and it matters if e.g. RESETIDS is
used as an attribute and file actions depend on the group rights for
opening a file.

show more ...


# 2bec2479 02-May-2021 martin <martin@NetBSD.org>

Fix copy&pasto in handling of POSIX_SPAWN_RESETIDS in posix_spawn(3)


# d54d6b7a 05-Dec-2020 thorpej <thorpej@NetBSD.org>

Refactor interval timers to make it possible to support types other than
the BSD/POSIX per-process timers:

- "struct ptimer" is split into "struct itimer" (common interval timer
data) and "struct

Refactor interval timers to make it possible to support types other than
the BSD/POSIX per-process timers:

- "struct ptimer" is split into "struct itimer" (common interval timer
data) and "struct ptimer" (per-process timer data, which contains a
"struct itimer").

- Introduce a new "struct itimer_ops" that supplies information about
the specific kind of interval timer, including it's processing
queue, the softint handle used to schedule processing, the function
to call when the timer fires (which adds it to the queue), and an
optional function to call when the CLOCK_REALTIME clock is changed by
a call to clock_settime() or settimeofday().

- Rename some fuctions to clearly identify what they're operating on
(ptimer vs itimer).

- Use kmem(9) to allocate ptimer-related structures, rather than having
dedicated pools for them.

Welcome to NetBSD 9.99.77.

show more ...


# 69ad8431 25-Nov-2020 wiz <wiz@NetBSD.org>

Define LMSG outside the MAXTSIZ check so it also exists in non-MAXTSIZ kernels.


# 3910cb68 06-Oct-2020 christos <christos@NetBSD.org>

Make MAXTSIZ optional.


# 0eaaa024 23-May-2020 ad <ad@NetBSD.org>

Move proc_lock into the data segment. It was dynamically allocated because
at the time we had mutex_obj_alloc() but not __cacheline_aligned.


12345678910>>...21