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

[Jens Axboe <axboe@kernel.dk>]

On 4/21/26 11:04 AM, Jens Axboe wrote:
> 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?

I'm just going to apply the patch, it's trivial (grab refs at mmap, drop
on close) and there's zero point in spending anymore time on this.

-- 
Jens Axboe