From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: io-uring@vger.kernel.org
Subject: Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps
Date: Tue, 21 Apr 2026 18:24:54 +0200 [thread overview]
Message-ID: <2026042125-disabled-conjure-67e4@gregkh> (raw)
In-Reply-To: <aed22e56-a39b-4c4b-a413-b5b1cd64deb4@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]
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...
greg k-h
[-- Attachment #2: fix-paddr.py --]
[-- Type: text/plain, Size: 562 bytes --]
#!/usr/bin/env python3
# Set p_paddr = p_vaddr in every program header so qemu -kernel loads
# the ELF at its link address. riscv vmlinux.lds sets LMA=VMA-LOAD_OFFSET
# for the Image target; we want qemu to honour VMA instead.
import sys, struct
with open(sys.argv[1], 'r+b') as f:
f.seek(0x20); phoff, = struct.unpack('<Q', f.read(8))
f.seek(0x36); phentsize, phnum = struct.unpack('<HH', f.read(4))
for i in range(phnum):
base = phoff + i * phentsize
f.seek(base + 16); vaddr = f.read(8)
f.seek(base + 24); f.write(vaddr)
[-- Attachment #3: objcopy --]
[-- Type: text/plain, Size: 926 bytes --]
#!/bin/sh
# Host objcopy lacks the riscv backend. Force the generic elf64-little
# reader so it can parse the input, then restore e_machine/e_flags in
# the output (which objcopy writes as EM_NONE) from the input file.
#
# Kernel objcopy invocations are: objcopy [FLAGS] INPUT OUTPUT
# (cmd_objcopy in scripts/Makefile.lib). The last two args are always
# the in/out files.
in=""
out=""
for a; do
case "$a" in
-*) ;;
*) in=$out; out=$a ;;
esac
done
/usr/bin/objcopy -I elf64-little "$@" || exit $?
# If output is ELF, restore e_machine (0x12, 2 bytes) and e_flags
# (0x30, 4 bytes) from the input so lld recognises it as riscv.
if [ -n "$in" ] && [ -f "$in" ] && [ -f "$out" ] && \
[ "$(head -c4 "$out" 2>/dev/null)" = "$(printf '\177ELF')" ]; then
dd if="$in" of="$out" bs=1 skip=18 seek=18 count=2 conv=notrunc 2>/dev/null
dd if="$in" of="$out" bs=1 skip=48 seek=48 count=4 conv=notrunc 2>/dev/null
fi
exit 0
[-- Attachment #4: objdump --]
[-- Type: text/plain, Size: 99 bytes --]
#!/bin/sh
exec /usr/bin/objdump -b elf64-little -m riscv "$@" 2>/dev/null || /usr/bin/objdump "$@"
next prev parent reply other threads:[~2026-04-21 16:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 13:46 [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps Greg Kroah-Hartman
2026-04-21 13:50 ` Jens Axboe
2026-04-21 13:55 ` Greg Kroah-Hartman
2026-04-21 14:02 ` Jens Axboe
2026-04-21 16:01 ` Greg Kroah-Hartman
2026-04-21 16:05 ` Jens Axboe
2026-04-21 16:21 ` Jens Axboe
2026-04-21 16:24 ` Greg Kroah-Hartman [this message]
2026-04-21 16:41 ` Jens Axboe
2026-04-21 17:04 ` Jens Axboe
2026-04-21 17:38 ` Jens Axboe
2026-04-21 17:39 ` Jens Axboe
2026-04-22 1:17 ` Jens Axboe
2026-04-22 1:56 ` Jens Axboe
2026-04-22 2:26 ` Jens Axboe
2026-04-22 5:36 ` Greg Kroah-Hartman
2026-04-22 8:11 ` Greg Kroah-Hartman
2026-04-22 12:40 ` Jens Axboe
2026-04-22 13:03 ` Greg Kroah-Hartman
2026-04-22 13:06 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026042125-disabled-conjure-67e4@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.