Keep a copy of the name with the semaphore and move the export from the libkernel_sys stub into libkernel next to the other sem_* exports.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
FreeBSD re-evaluates a kqueue's EVFILT_READ note from kqueue_wakeup,
which runs whenever the watched kqueue queues a note, so an EV_CLEAR
note fires again only after such an activation. The equeue now counts
activations, and the EV_CLEAR note fires when the count moves while
notes are queued.
The PS5 3.20 export lists have ksem_* in libkernel as well as
libkernel_sys, and on Windows a libkernel import never reaches
libkernel_sys, so titles importing them from libkernel did not find
them. Following pipe1os's review on #9284, also: ENOSPC from
ksem_init when no descriptor is left, the SEM_MAX limit of 30 with
ENOSPC, and dup/dup2 from a ksem id throwing as for a kqueue.
TakeSnapshot read FileBasicInfo and then FileStandardInfo. A truncate or
write landing between the two left a snapshot with the new size and the
old LastWriteTime, and the next poll reported the same size with a newer
LastWriteTime as NOTE_WRITE. guest_kqueue's FileWatch aborts on Windows
when that happens after its ftruncate to 0.
Read FileBasicInfo again after FileStandardInfo and retry until both
reads agree. The window NTFS itself leaves, a truncate's new
LastWriteTime shown before its new size, stays and is listed in the
libkernel debt.
A guest mmap with PROT_EXEC and MAP_SHARED of a shared-memory object or a regular file threw on Windows. The section is now created from a handle reopened with GENERIC_EXECUTE, as PAGE_EXECUTE_READ or PAGE_EXECUTE_READWRITE, the owner ACE of named objects grants execute with read, and a writable shared mapping of a read-only descriptor fails with EACCES, as FreeBSD 11.4 shm_mmap and vn_mmap do.
Fixes#12337
Both log their arguments and the caller and return. Note what the
titles' bundled libc.prx passes them and that three of its
sceKernelDebugRaiseException calls are followed by ud2 in every build
checked, so the guest reaches that ud2 here.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
This reverts commit 780b33aea3, restoring the 13824 MiB direct memory pool.
With the pool at 12288 MiB, Astro Bot (PPSA21564) can no longer load its
level: DirectMemoryAllocator asserts "Can't allocate direct memory" for a
64 MB VideoPlayerTexture with 12228 of 12288 MB in use, then the process
faults about 26 s in (2 of 2 runs, RTX 4090, Linux, main cccdaa2734).
The same tree with only this merge reverted runs the full 150 s with no
direct memory assert (2 of 2 runs).
Under Rosetta the main thread stack lies at about 12 GiB, inside the guest
arena, where a title can map fixed addresses; a fixed mapping over it
aborts with a host region overlap.
- Aps5StartGuest moves the main thread onto a 16 MiB stack at
0x600000000000 when the old stack overlaps a host region of the arena.
It copies argv, environ, the program name and the initial block off the
old stack, then frees the old stack and releases its range to the arena.
- The guest thread keeps the stack size of the original main thread.
- The arena gets GuestArenaOverlapsHostRegion and
GuestArenaReleaseHostRegion for POSIX hosts.
- guest_main_stack_move starts the guest, then requires the main thread
outside the arena, a fixed mapping where the old stack was, and argv and
the environment intact.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
scePthreadMutexattrSetkind called NotImplemented_nid_no_patch for a kind
outside 1 to 4. Firmware 13.42's libkernel, run in an emulator, makes it
call pthread_mutexattr_setkind_np, which stores any kind as a signed
16-bit value and returns 0, and turns a null attribute's -1 with errno 22
into 0x8001FFFF. It now forwards to pthread_mutexattr_setkind_np and
converts the result with sceKernelError, so a null attribute or object
still returns 0x8001FFFF and now also sets errno 22.
An out-of-range kind is refused by scePthreadMutexInit with 0x80020016,
leaving the mutex untouched, as measured for the same module.
scePthreadMutexattrGetkind is unchanged; kind 0 now reaches it and
returns 0.
Probe p87_libkernel lines 7-27: a payload process on a PS5 returns 0 and keeps the limits for a raised RLIMIT_DATA or RLIMIT_STACK hard limit, and reads back RLIMIT_CORE soft limits.