Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe <axboe@kernel.dk>]

On 4/21/26 10:41 AM, Jens Axboe wrote:
> On 4/21/26 10:24 AM, Greg Kroah-Hartman wrote:
>> On Tue, Apr 21, 2026 at 10:21:04AM -0600, Jens Axboe wrote:
>>> On 4/21/26 10:05 AM, Jens Axboe wrote:
>>>> On 4/21/26 10:01 AM, Greg Kroah-Hartman wrote:
>>>>> On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
>>>>>> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
>>>>>>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
>>>>>>>> Note, I have no way of testing this, I'm only forwarding this on because
>>>>>>>> I got the bug report and was able to generate something that "seems"
>>>>>>>
>>>>>>> AI bug report I presume? Because I can't imagine anyone ever attempted
>>>>>>> to run this.
>>>>>>
>>>>>> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
>>>>>> guess you can do that with qemu these days?  I should dig into that,
>>>>>> maybe that way I can test this and get a reproducer for you.  If not,
>>>>>> let's just bin the thing.
>>>>>>
>>>>>>>> correct, but it might be a total load of crap here, my knowledge of the
>>>>>>>> vm layer is very low so take this for where it is coming from (i.e. a
>>>>>>>> non-deterministic pattern matching system.)
>>>>>>>>
>>>>>>>> I do have another patch that just disables io_uring for !MMU systems, if
>>>>>>>> you want that instead?  Or is this feature something that !MMU devices
>>>>>>>> actually care about?
>>>>>>>
>>>>>>> I mean, who really cares about !MMU in the first place, we should just
>>>>>>> kill that off with a passion.
>>>>>>>
>>>>>>> Let me take a closer look at this and bounce it past some vm people, my
>>>>>>> nommu knowledge is close to zero as it's never been relevant in my
>>>>>>> professional life time. Which is saying something...
>>>>>>
>>>>>> Let me try to get a reproducer going first, let's not waste any more
>>>>>> human time on this just yet, sorry for sending this out without that
>>>>>> done first...
>>>>>
>>>>> Ok, attached is a poc.c and a script to run it.  If you run this on a
>>>>> 7.0 kernel today, it "should" crash. and then if you apply the patch it
>>>>> doesn't (or at least that's what happened in my testing.)
>>>>>
>>>>> Note, I have run this locally, and it seems to work, but be careful, I
>>>>> can't guarantee anything, it does seem quite odd in that it "crashes"
>>>>> the kernel with a sysrq call to show "proof".  Although that is a cool
>>>>> trick, I need to remember that...
>>>>
>>>> I'll try and run a nommu qemu and see what pops out on my end. What a
>>>> waste of time for a nothing burger ;-)
>>>
>>> What is fix-paddr.py? It's referenced in the build script.
>>
>> Oops, this thing scattered crud all over the filesystem.  Here's what is
>> in the cross-wrap directory that it created.  If I forgot anything else,
>> let me know, sorry about that.  I need to clean up my working directory
>> for this box (which is rightfully air-gapped) as it's accumulated a lot
>> of cruft...
> 
> Still get the same error:
> 
> qemu-system-riscv64: Some ROM regions are overlapping
> These ROM regions might have been loaded by direct user request or by default.
> They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
> Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
> 
> The following two regions overlap (in the memory address space):
>   build-nommu/vmlinux.qemu ELF program header segment 0 (addresses 0x0000000000000000 - 0x00000000001f1e18)
>   mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
> 
> axboe@r7625 ~/v/nommu [1]> qemu-system-riscv64 --version
> QEMU emulator version 10.2.2 (Debian 1:10.2.2+ds-1)
> Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
> 
> What are you running this with?

Skipped the paddr/strip stuff and just booted arch/riscv/boot/Image:

[...]
[    0.217868] Freeing unused kernel image (initmem) memory: 400K
[    0.218137] This architecture does not have kernel memory protection.
[    0.218478] Run /init as init process
[*] pbuf_ring page mmap()ed at 0x8059c000
[*] unregistered; canary[0..3] = 55 55 55 55
[+] OK: canary intact — mmap holds page reference, fix is applied
[    0.237876] reboot: Power down

and doesn't complain here. Same sha, current Linus -tip which is also
what was used in the poc script.

Hmm?

-- 
Jens Axboe