NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/57705: rump doesn't have a way to interrupt rump_sys_* by a signal
>Number: 57705
>Category: kern
>Synopsis: rump doesn't have a way to interrupt rump_sys_* by a signal
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Nov 19 00:30:00 +0000 2023
>Originator: Taylor R Campbell
>Release: current
>Organization:
The RumpBSD Signallation
>Environment:
>Description:
It is important for some automatic tests (like the one I drafted for PR kern/57703, https://gnats.NetBSD.org/57703) to test interrupting a blocking system call with a signal, so that cv_wait_sig (or legacy tsleep) will return with EINTR.
However, as far as I can tell, there's no way to do that with rump at the moment. Simply delivering a signal to the process or pthread doesn't do anything -- the underlying pthread_cond_wait inside the rump cv_wait_sig won't wake on signal, and there's no logic in it to trigger a wakeup.
>How-To-Repeat:
Write a test of interrupting a blocking syscall with a signal.
>Fix:
Yes, please!
Probably just a matter of creating a path in locks.c docvwait to check for pending signals and set l->l_sched.info = cv under a lock, so that another thread can deliver a `signal' by setting pending signals and cv_broadcasting l->l_sched.info.
Home |
Main Index |
Thread Index |
Old Index