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