Hello, Michael Kelly, le dim. 18 janv. 2026 08:04:57 +0000, a ecrit: > On 18/01/2026 03:46, Damien Zammit wrote: > > There are two known remaining issues with this patchset: > > > > 1. There is a problem with the recent changes regarding > > _Xmach_port_set_ktype -> ipc_kobject_set that causes a hang > > only on SMP kernels, which can be temporarily worked around by > > reverting commit: > > fdfca0e8 "Add mach_port_set_ktype RPC to set ktype of a user port" > > but we really ought to dig into it and fix this. > > This seems to be a case of trying to acquire a lock that is already held. > The function mach_port_set_ktype() in mach_port.c acquires the ip_lock on > the 'port' indirectly via ipc_object_translate(). The call to > ipc_kobject_set then tries to also acquire the lock already held. As a > workaround proof I added a ipc_kobject_set_unlocked() that does the same as > ipc_kobject_set() but without the lock/unlock. This alteration allowed the > i386/smp to boot to console login. > > Which of these methods is the best way of fixing this properly? > > 1) Drop the port lock before the call to ipc_kobject_set() in some safe way. > > 2) As above with a version of ipc_kobject_set() that requires the port to be > already locked.
Yes, an internal version that assumes the port is locked will be fine. Call it ipc_kobject_set_locked, however, to be consistent with other such functions (e.g. vm_object_reference_locked etc.). And make ipc_kobject_set call it, to avoid duplicating code. Samuel
