In payload processes on a PS5 (firmware 12.70), re-adding an existing
periodic EVFILT_TIMER with EV_ADD, fflags 0 and a positive period kept
the armed expiry and the expirations already counted, and applied the
new period after that expiry, as FreeBSD 11.0 does. EV_ONESHOT in the
re-add left the timer periodic. Here such a re-add threw; it now does
the same. Re-adding a one-shot or disabled timer, a re-add with nonzero
fflags, a period of 0 or less, a period that overflows the armed expiry
or flags other than EV_ONESHOT, and the other changes to an existing
timer except EV_DELETE still throw.
There, EV_ADD failed with EPERM for EVFILT_AIO, EVFILT_LIO and
EVFILT_SENDFILE at every ident and flag set tried, and EV_DELETE and
EV_ENABLE of them without EV_ADD failed with ENOENT. EVFILT_PROCDESC
failed with EBADF on a descriptor that is not open and with EINVAL on
every kind of open descriptor tried, and EV_DELETE of it on a socket
failed with ENOENT. These filters threw here; they now answer the same
way. EV_ADD of EVFILT_PROCDESC fails with EINVAL on the kinds of
descriptor tried and on shared memory, and throws on other kinds and on
descriptors 0 to 2 that are not sockets or kqueues; a change without
EV_ADD fails with ENOENT, after the descriptor check for
EVFILT_PROCDESC.
A new kevent measurements debt entry, which the kqueue and kevent entry
points to, records these measurements and the answers for NOTE_LOWAT
marks and EVFILT_READ on another kqueue, which still throw here. The
kqueue and kevent entry also stops listing a NOTE_NSECONDS period above
one second with a fraction among the cases that throw, since d71a1c577
made it work.
On Linux and macOS, sceKernelRaiseException runs the guest handler in
the target's SIGUSR1 handler wherever the thread was interrupted. A
thread interrupted while it held the address-wait lock of
sceKernelSyncOnAddressWait, sceKernelSyncOnAddressWake or _umtx_op ran
the handler with the lock held, so a handler that waits, as a
stop-the-world collector's does, blocked every other thread that waits
on or wakes an address. #5756 fixed this on Windows.
The address-wait lock is now taken under DeliveryDeferral on every
host. On POSIX the deferral is a count per thread: while it is raised
the SIGUSR1 handler only records the signal, and DeliverDeferred sends
it to the thread again once the lock is released. An address waiter
waits on its own semaphore (sem_t, a dispatch semaphore on macOS) with
the lock released and the deferral lifted, so a raise reaches a thread
that waits for an address without a timeout.
The address-lock phases of guest_raise_exception now run on every
host, with a new phase that raises at a thread in an unbounded address
wait.
The connect-to-AF_UNSPEC debt entry only described Linux. On Windows a socket bound to an explicit address keeps it in the same way, getsockname reports the host address, and a sendto to a non-loopback address then fails with ENETUNREACH, where FreeBSD's udp_disconnect() resets the local address and the send succeeds.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
fcntl(F_SETFL) threw when it changed O_APPEND on a Windows file. The
guest flag already chooses WriteAtEnd, but a descriptor opened with
O_APPEND also carries the CRT's append flag, so _write kept appending
after the guest cleared it. F_SETFL now replaces the CRT descriptor of
every descriptor sharing the open file's status with a duplicate handle
opened with or without _O_APPEND, as libc fdopen does for append mode.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The prosper console oracle measured SCE_KERNEL_ERROR_EINVAL for creating
a semaphore with an initial count above the maximum, a maximum of 0, a
negative initial count or a null name, for polling 0 or more than the
maximum, and for signalling 0. These threw, or polled past the maximum
returned EBUSY, and signalling 0 succeeded.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
scePthreadCreate returns ENAMETOOLONG for a name of 32 bytes or more without creating the thread, and scePthreadDetach returns ESRCH for a joined thread.
Co-Authored-By: Claude Opus 5.5 <[email protected]>