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

[Jens Axboe <axboe@kernel.dk>]

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?

-- 
Jens Axboe