Hello,
Michael Kelly, le dim. 18 janv. 2026 08:04:57 +, 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
