[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc3a0edc-f2fb-488a-81d9-016f78b5671d@kernel.dk>
Date: Tue, 15 Oct 2024 15:56:29 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Dave Hansen <dave.hansen@...el.com>,
Marius Fleischer <fleischermarius@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski
<luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org
Cc: syzkaller@...glegroups.com, harrisonmichaelgreen@...il.com,
Pavel Begunkov <asml.silence@...il.com>, io-uring@...r.kernel.org
Subject: Re: WARNING in get_pat_info
On 10/15/24 2:04 PM, Dave Hansen wrote:
> On 10/15/24 11:55, Marius Fleischer wrote:
>> Hope you are doing well!
>>
>> Quick update from our side: The reproducer from the previous email
>> still triggers a WARNING on v5.15 (commit hash
>> 3a5928702e7120f83f703fd566082bfb59f1a57e). Happy to also test on
>> other kernel versions if that helps.
>>
>> Please let us know if there is any other helpful information we can provide.
>
> I don't know for sure, but I suspect that io_uring is triggering this.
> The reproducer is:
>
> syz_io_uring_setup(0x6f7e, &(0x7f0000000080), 0x0, 0x0)
> syz_clone(0x24080, 0x0, 0x0, 0x0, 0x0, 0x0) (fail_nth: 40)
>
> and the stack trace shows:
>
> untrack_pfn+0xdc/0x240 arch/x86/mm/pat/memtype.c:1122
> ...
> __mmput+0x122/0x4b0 kernel/fork.c:1126
> ...
> __do_sys_clone+0xc8/0x110 kernel/fork.c:2721
>
> So whatever is happening is going on with a VM_PFNMAP VMA. Those aren't
> super common except when you're mmap()'ing something from a device
> driver. I would randomly guess that io_uring_setup() is setting up a
> VM_PFNMAP VMA and untrack_pfn() is getting called when that VMA is
> getting torn down.
>
> The other goofiness is that the copy_mm() path is ending up in
> exit_mmap(). I think the only way to end up doing that is in the
> failure path of dup_mm().
>
> So I *think* what happens is that a io_uring VMA gets created in
> dup_mmap(), but never gets any pages faulted in. Some later setup fails
> and the new mm needs to be torn down. *Something* about the io_uring
> VMA screws up the untrack_pfn() code.
>
> I'm hoping that this rings a bell with the io_uring folks and this is a
> bug they've found and fixed in mainline that just got missed backporting
> to stable.
Doesn't ring a bell, and haven't had anyone report that before. The
older io_uring code does indeed use remap_pfn_range(), this is gone in
newer kernels. But in any case, I can't seem to trigger this on
5.15-stable, I might be missing something in my .config...
--
Jens Axboe
Powered by blists - more mailing lists