Re: New pmap status update

[Jason Thorpe <thorpej%me.com@localhost>]

> On Dec 14, 2025, at 4:55 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
>> On Dec 14, 2025, at 9:25 AM, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
>> 
>> I've tried SMALL020 kernel (i.e. traditional pmap) around 20251207
>> (via netboot) and unfortunately it gets panic() due to another
>> TAS instruction in _kernel_lock() (maybe __cpu_simple_lock_try()?):
> 
> Yes, looks like it’s __cpu_simple_lock() and/or __cpu_simple_lock_try().  I’ll add a __HAVE_M68K_BROKEN_RMC check in <m68k/lock.h> and make it use _atomic_cas_32() in that case.

Ok, this one is a little annoying because __cpu_simple_lock_t is 8-bit, and I need a 32-bit datum for the kernel restartable atomic sequence.

    https://www.netbsd.org/~thorpej/m68k-simple-lock-rmc-fix.txt

I’m not entirely satisfied with that solution, if only because it feels a little gross.

__cpu_simple_lock_t is exported to user-space, too (used by libpthread), so this patch can’t quite go in 100% as-is; at the very least, I’ll need to conditionalize it on _KERNEL and fix up libpthread another day.  (Actually, this applies to the other user-space atomic(3) ops, as well.)

-- thorpej