Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

[Naresh Kamboju]

On Wed, 19 Mar 2025 at 20:09, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.6.84 release.
> There are 166 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 21 Mar 2025 14:29:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.84-rc1.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Regressions on mips the rt305x_defconfig builds failed with gcc-12
the stable-rc v6.6.83-167-gd16a828e7b09

First seen on the v6.6.83-167-gd16a828e7b09
 Good: v6.6.83
 Bad: v6.6.83-167-gd16a828e7b09

* mips, build
  - gcc-12-rt305x_defconfig

Regression Analysis:
 - New regression? Yes
 - Reproducibility? Yes

Build regression: mips implicit declaration of function 'vunmap'
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

## Build log
io_uring/io_uring.c: In function 'io_pages_unmap':
io_uring/io_uring.c:2708:17: error: implicit declaration of function
'vunmap'; did you mean 'kunmap'?
[-Werror=implicit-function-declaration]
 2708 |                 vunmap(ptr);
      |                 ^~~~~~
      |                 kunmap
io_uring/io_uring.c: In function '__io_uaddr_map':
io_uring/io_uring.c:2784:21: error: implicit declaration of function
'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration]
 2784 |         page_addr = vmap(page_array, nr_pages, VM_MAP, PAGE_KERNEL);
      |                     ^~~~
      |                     kmap
io_uring/io_uring.c:2784:48: error: 'VM_MAP' undeclared (first use in
this function); did you mean 'VM_MTE'?
 2784 |         page_addr = vmap(page_array, nr_pages, VM_MAP, PAGE_KERNEL);
      |                                                ^~~~~~
      |                                                VM_MTE

## Source
* Kernel version: 6.6.84-rc1
* Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* Git sha: d16a828e7b0965ca37245ebea19052ad7b4b2f9b
* Git describe: v6.6.83-167-gd16a828e7b09
* Project details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.83-167-gd16a828e7b09/

## Build
* Build log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.83-167-gd16a828e7b09/testrun/27677634/suite/build/test/gcc-12-rt305x_defconfig/log
* Build history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.83-167-gd16a828e7b09/testrun/27677634/suite/build/test/gcc-12-rt305x_defconfig/history/
* Build details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.83-167-gd16a828e7b09/testrun/27677634/suite/build/test/gcc-12-rt305x_defconfig/
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2uXZlKzVxja3mOQfRLlPRxHzd5L/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2uXZlKzVxja3mOQfRLlPRxHzd5L/config

## Steps to reproduce
 - tuxmake --runtime podman --target-arch mips --toolchain gcc-12
--kconfig rt305x_defconfig


--
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

[Jens Axboe]

On 3/19/25 10:33 AM, Naresh Kamboju wrote:
> On Wed, 19 Mar 2025 at 20:09, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>>
>> This is the start of the stable review cycle for the 6.6.84 release.
>> There are 166 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Fri, 21 Mar 2025 14:29:55 +0000.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.84-rc1.gz
>> or in the git tree and branch at:
>>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
> 
> Regressions on mips the rt305x_defconfig builds failed with gcc-12
> the stable-rc v6.6.83-167-gd16a828e7b09
> 
> First seen on the v6.6.83-167-gd16a828e7b09
>  Good: v6.6.83
>  Bad: v6.6.83-167-gd16a828e7b09
> 
> * mips, build
>   - gcc-12-rt305x_defconfig
> 
> Regression Analysis:
>  - New regression? Yes
>  - Reproducibility? Yes
> 
> Build regression: mips implicit declaration of function 'vunmap'
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

Ah that's my fault, forgot to include the backport of:

commit 62346c6cb28b043f2a6e95337d9081ec0b37b5f5
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sat Mar 16 07:21:43 2024 -0600

    mm: add nommu variant of vm_insert_pages()

for 6.1-stable and 6.6-stable. Greg, can you just cherry pick that one?
It'll pick cleanly into both, should go before the io_uring mmap series
obviously.

Sorry about that! I did have it in my local trees, but for some reason
forgot to include it in the sent in series.

-- 
Jens Axboe

Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

[Greg Kroah-Hartman]

On Wed, Mar 19, 2025 at 10:37:20AM -0600, Jens Axboe wrote:
> On 3/19/25 10:33 AM, Naresh Kamboju wrote:
> > On Wed, 19 Mar 2025 at 20:09, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> >>
> >> This is the start of the stable review cycle for the 6.6.84 release.
> >> There are 166 patches in this series, all will be posted as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Fri, 21 Mar 2025 14:29:55 +0000.
> >> Anything received after that time might be too late.
> >>
> >> The whole patch series can be found in one patch at:
> >>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.84-rc1.gz
> >> or in the git tree and branch at:
> >>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> >> and the diffstat can be found below.
> >>
> >> thanks,
> >>
> >> greg k-h
> > 
> > Regressions on mips the rt305x_defconfig builds failed with gcc-12
> > the stable-rc v6.6.83-167-gd16a828e7b09
> > 
> > First seen on the v6.6.83-167-gd16a828e7b09
> >  Good: v6.6.83
> >  Bad: v6.6.83-167-gd16a828e7b09
> > 
> > * mips, build
> >   - gcc-12-rt305x_defconfig
> > 
> > Regression Analysis:
> >  - New regression? Yes
> >  - Reproducibility? Yes
> > 
> > Build regression: mips implicit declaration of function 'vunmap'
> > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> Ah that's my fault, forgot to include the backport of:
> 
> commit 62346c6cb28b043f2a6e95337d9081ec0b37b5f5
> Author: Jens Axboe <axboe@kernel.dk>
> Date:   Sat Mar 16 07:21:43 2024 -0600
> 
>     mm: add nommu variant of vm_insert_pages()
> 
> for 6.1-stable and 6.6-stable. Greg, can you just cherry pick that one?
> It'll pick cleanly into both, should go before the io_uring mmap series
> obviously.
> 
> Sorry about that! I did have it in my local trees, but for some reason
> forgot to include it in the sent in series.

No worries, will do in a few hours and will push out a -rc2.

greg k-h

Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

[Greg Kroah-Hartman]

On Wed, Mar 19, 2025 at 10:37:20AM -0600, Jens Axboe wrote:
> On 3/19/25 10:33 AM, Naresh Kamboju wrote:
> > On Wed, 19 Mar 2025 at 20:09, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> >>
> >> This is the start of the stable review cycle for the 6.6.84 release.
> >> There are 166 patches in this series, all will be posted as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Fri, 21 Mar 2025 14:29:55 +0000.
> >> Anything received after that time might be too late.
> >>
> >> The whole patch series can be found in one patch at:
> >>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.84-rc1.gz
> >> or in the git tree and branch at:
> >>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> >> and the diffstat can be found below.
> >>
> >> thanks,
> >>
> >> greg k-h
> > 
> > Regressions on mips the rt305x_defconfig builds failed with gcc-12
> > the stable-rc v6.6.83-167-gd16a828e7b09
> > 
> > First seen on the v6.6.83-167-gd16a828e7b09
> >  Good: v6.6.83
> >  Bad: v6.6.83-167-gd16a828e7b09
> > 
> > * mips, build
> >   - gcc-12-rt305x_defconfig
> > 
> > Regression Analysis:
> >  - New regression? Yes
> >  - Reproducibility? Yes
> > 
> > Build regression: mips implicit declaration of function 'vunmap'
> > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> Ah that's my fault, forgot to include the backport of:
> 
> commit 62346c6cb28b043f2a6e95337d9081ec0b37b5f5
> Author: Jens Axboe <axboe@kernel.dk>
> Date:   Sat Mar 16 07:21:43 2024 -0600
> 
>     mm: add nommu variant of vm_insert_pages()
> 
> for 6.1-stable and 6.6-stable. Greg, can you just cherry pick that one?
> It'll pick cleanly into both, should go before the io_uring mmap series
> obviously.
> 
> Sorry about that! I did have it in my local trees, but for some reason
> forgot to include it in the sent in series.

Wait, this is already in the 6.6.y and 6.1.y queues, so this can't be
the fix.  Was there a fixup for that commit somewhere else that I'm
missing?

thanks,

greg k-h

Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

[Jens Axboe]

On 3/19/25 5:51 PM, Greg Kroah-Hartman wrote:
> On Wed, Mar 19, 2025 at 10:37:20AM -0600, Jens Axboe wrote:
>> On 3/19/25 10:33 AM, Naresh Kamboju wrote:
>>> On Wed, 19 Mar 2025 at 20:09, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> This is the start of the stable review cycle for the 6.6.84 release.
>>>> There are 166 patches in this series, all will be posted as a response
>>>> to this one.  If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Fri, 21 Mar 2025 14:29:55 +0000.
>>>> Anything received after that time might be too late.
>>>>
>>>> The whole patch series can be found in one patch at:
>>>>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.84-rc1.gz
>>>> or in the git tree and branch at:
>>>>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
>>>> and the diffstat can be found below.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>
>>> Regressions on mips the rt305x_defconfig builds failed with gcc-12
>>> the stable-rc v6.6.83-167-gd16a828e7b09
>>>
>>> First seen on the v6.6.83-167-gd16a828e7b09
>>>  Good: v6.6.83
>>>  Bad: v6.6.83-167-gd16a828e7b09
>>>
>>> * mips, build
>>>   - gcc-12-rt305x_defconfig
>>>
>>> Regression Analysis:
>>>  - New regression? Yes
>>>  - Reproducibility? Yes
>>>
>>> Build regression: mips implicit declaration of function 'vunmap'
>>> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>>
>> Ah that's my fault, forgot to include the backport of:
>>
>> commit 62346c6cb28b043f2a6e95337d9081ec0b37b5f5
>> Author: Jens Axboe <axboe@kernel.dk>
>> Date:   Sat Mar 16 07:21:43 2024 -0600
>>
>>     mm: add nommu variant of vm_insert_pages()
>>
>> for 6.1-stable and 6.6-stable. Greg, can you just cherry pick that one?
>> It'll pick cleanly into both, should go before the io_uring mmap series
>> obviously.
>>
>> Sorry about that! I did have it in my local trees, but for some reason
>> forgot to include it in the sent in series.
> 
> Wait, this is already in the 6.6.y and 6.1.y queues, so this can't be
> the fix.  Was there a fixup for that commit somewhere else that I'm
> missing?

Huh indeed, guess I didn't mess up in the first place. What is going on
here indeed... Is that mips config NOMMU yet doesn't link in mm/nommu.o?

Checking, and no, it definitely has MMU=y in the config. Guess I
should've read the initial report more closely, it's simply missing the
vunmap definition. Adding linux/vmalloc.h to io_uring/io_uring.c should
fix it.

How do we want to deal with this?

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 058c89f72e8c..efa7849b82c1 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -70,6 +70,7 @@
 #include <linux/io_uring.h>
 #include <linux/audit.h>
 #include <linux/security.h>
+#include <linux/vmalloc.h>
 #include <asm/shmparam.h>
 
 #define CREATE_TRACE_POINTS

-- 
Jens Axboe

Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]

On 3/20/25 6:55 AM, Jens Axboe wrote:
> On 3/19/25 5:51 PM, Greg Kroah-Hartman wrote:
>> On Wed, Mar 19, 2025 at 10:37:20AM -0600, Jens Axboe wrote:
>>> On 3/19/25 10:33 AM, Naresh Kamboju wrote:
>>>> On Wed, 19 Mar 2025 at 20:09, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>
>>>>> This is the start of the stable review cycle for the 6.6.84 release.
>>>>> There are 166 patches in this series, all will be posted as a response
>>>>> to this one.  If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Fri, 21 Mar 2025 14:29:55 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.84-rc1.gz
>>>>> or in the git tree and branch at:
>>>>>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>
>>>> Regressions on mips the rt305x_defconfig builds failed with gcc-12
>>>> the stable-rc v6.6.83-167-gd16a828e7b09
>>>>
>>>> First seen on the v6.6.83-167-gd16a828e7b09
>>>>  Good: v6.6.83
>>>>  Bad: v6.6.83-167-gd16a828e7b09
>>>>
>>>> * mips, build
>>>>   - gcc-12-rt305x_defconfig
>>>>
>>>> Regression Analysis:
>>>>  - New regression? Yes
>>>>  - Reproducibility? Yes
>>>>
>>>> Build regression: mips implicit declaration of function 'vunmap'
>>>> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>>>
>>> Ah that's my fault, forgot to include the backport of:
>>>
>>> commit 62346c6cb28b043f2a6e95337d9081ec0b37b5f5
>>> Author: Jens Axboe <axboe@kernel.dk>
>>> Date:   Sat Mar 16 07:21:43 2024 -0600
>>>
>>>     mm: add nommu variant of vm_insert_pages()
>>>
>>> for 6.1-stable and 6.6-stable. Greg, can you just cherry pick that one?
>>> It'll pick cleanly into both, should go before the io_uring mmap series
>>> obviously.
>>>
>>> Sorry about that! I did have it in my local trees, but for some reason
>>> forgot to include it in the sent in series.
>>
>> Wait, this is already in the 6.6.y and 6.1.y queues, so this can't be
>> the fix.  Was there a fixup for that commit somewhere else that I'm
>> missing?
> 
> Huh indeed, guess I didn't mess up in the first place. What is going on
> here indeed... Is that mips config NOMMU yet doesn't link in mm/nommu.o?
> 
> Checking, and no, it definitely has MMU=y in the config. Guess I
> should've read the initial report more closely, it's simply missing the
> vunmap definition. Adding linux/vmalloc.h to io_uring/io_uring.c should
> fix it.
> 
> How do we want to deal with this?

Either fold in the hunk from the previous email, or replace patch 2 in
the series I sent with this one instead, which adds the vmalloc.h
include. That should sort out the issue without needing add-on patches
that don't exist upstream.

-- 
Jens Axboe

[-- Attachment #2: 0002-io_uring-get-rid-of-remap_pfn_range-for-mapping-ring.patch --]
[-- Type: text/x-patch, Size: 7437 bytes --]

From 063cda8806cf277c56e4bfc7163e5faa355e177d Mon Sep 17 00:00:00 2001
From: Jens Axboe <axboe@kernel.dk>
Date: Wed, 13 Mar 2024 09:56:14 -0600
Subject: [PATCH 02/10] io_uring: get rid of remap_pfn_range() for mapping
 rings/sqes

Commit 3ab1db3c6039e02a9deb9d5091d28d559917a645 upstream.

Rather than use remap_pfn_range() for this and manually free later,
switch to using vm_insert_pages() and have it Just Work.

If possible, allocate a single compound page that covers the range that
is needed. If that works, then we can just use page_address() on that
page. If we fail to get a compound page, allocate single pages and use
vmap() to map them into the kernel virtual address space.

This just covers the rings/sqes, the other remaining user of the mmap
remap_pfn_range() user will be converted separately. Once that is done,
we can kill the old alloc/free code.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
 io_uring/io_uring.c | 140 +++++++++++++++++++++++++++++++++++++++++---
 io_uring/io_uring.h |   2 +
 2 files changed, 134 insertions(+), 8 deletions(-)

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 5776440f584c..b506064ca29d 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -71,6 +71,7 @@
 #include <linux/io_uring.h>
 #include <linux/audit.h>
 #include <linux/security.h>
+#include <linux/vmalloc.h>
 #include <asm/shmparam.h>
 
 #define CREATE_TRACE_POINTS
@@ -2683,6 +2684,36 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
 	return READ_ONCE(rings->cq.head) == READ_ONCE(rings->cq.tail) ? ret : 0;
 }
 
+static void io_pages_unmap(void *ptr, struct page ***pages,
+			   unsigned short *npages)
+{
+	bool do_vunmap = false;
+
+	if (!ptr)
+		return;
+
+	if (*npages) {
+		struct page **to_free = *pages;
+		int i;
+
+		/*
+		 * Only did vmap for the non-compound multiple page case.
+		 * For the compound page, we just need to put the head.
+		 */
+		if (PageCompound(to_free[0]))
+			*npages = 1;
+		else if (*npages > 1)
+			do_vunmap = true;
+		for (i = 0; i < *npages; i++)
+			put_page(to_free[i]);
+	}
+	if (do_vunmap)
+		vunmap(ptr);
+	kvfree(*pages);
+	*pages = NULL;
+	*npages = 0;
+}
+
 void io_mem_free(void *ptr)
 {
 	if (!ptr)
@@ -2787,8 +2818,8 @@ static void *io_sqes_map(struct io_ring_ctx *ctx, unsigned long uaddr,
 static void io_rings_free(struct io_ring_ctx *ctx)
 {
 	if (!(ctx->flags & IORING_SETUP_NO_MMAP)) {
-		io_mem_free(ctx->rings);
-		io_mem_free(ctx->sq_sqes);
+		io_pages_unmap(ctx->rings, &ctx->ring_pages, &ctx->n_ring_pages);
+		io_pages_unmap(ctx->sq_sqes, &ctx->sqe_pages, &ctx->n_sqe_pages);
 	} else {
 		io_pages_free(&ctx->ring_pages, ctx->n_ring_pages);
 		ctx->n_ring_pages = 0;
@@ -2800,6 +2831,80 @@ static void io_rings_free(struct io_ring_ctx *ctx)
 	ctx->sq_sqes = NULL;
 }
 
+static void *io_mem_alloc_compound(struct page **pages, int nr_pages,
+				   size_t size, gfp_t gfp)
+{
+	struct page *page;
+	int i, order;
+
+	order = get_order(size);
+	if (order > 10)
+		return ERR_PTR(-ENOMEM);
+	else if (order)
+		gfp |= __GFP_COMP;
+
+	page = alloc_pages(gfp, order);
+	if (!page)
+		return ERR_PTR(-ENOMEM);
+
+	for (i = 0; i < nr_pages; i++)
+		pages[i] = page + i;
+
+	return page_address(page);
+}
+
+static void *io_mem_alloc_single(struct page **pages, int nr_pages, size_t size,
+				 gfp_t gfp)
+{
+	void *ret;
+	int i;
+
+	for (i = 0; i < nr_pages; i++) {
+		pages[i] = alloc_page(gfp);
+		if (!pages[i])
+			goto err;
+	}
+
+	ret = vmap(pages, nr_pages, VM_MAP, PAGE_KERNEL);
+	if (ret)
+		return ret;
+err:
+	while (i--)
+		put_page(pages[i]);
+	return ERR_PTR(-ENOMEM);
+}
+
+static void *io_pages_map(struct page ***out_pages, unsigned short *npages,
+			  size_t size)
+{
+	gfp_t gfp = GFP_KERNEL_ACCOUNT | __GFP_ZERO | __GFP_NOWARN;
+	struct page **pages;
+	int nr_pages;
+	void *ret;
+
+	nr_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+	pages = kvmalloc_array(nr_pages, sizeof(struct page *), gfp);
+	if (!pages)
+		return ERR_PTR(-ENOMEM);
+
+	ret = io_mem_alloc_compound(pages, nr_pages, size, gfp);
+	if (!IS_ERR(ret))
+		goto done;
+
+	ret = io_mem_alloc_single(pages, nr_pages, size, gfp);
+	if (!IS_ERR(ret)) {
+done:
+		*out_pages = pages;
+		*npages = nr_pages;
+		return ret;
+	}
+
+	kvfree(pages);
+	*out_pages = NULL;
+	*npages = 0;
+	return ret;
+}
+
 void *io_mem_alloc(size_t size)
 {
 	gfp_t gfp = GFP_KERNEL_ACCOUNT | __GFP_ZERO | __GFP_NOWARN | __GFP_COMP;
@@ -3463,14 +3568,12 @@ static void *io_uring_validate_mmap_request(struct file *file,
 		/* Don't allow mmap if the ring was setup without it */
 		if (ctx->flags & IORING_SETUP_NO_MMAP)
 			return ERR_PTR(-EINVAL);
-		ptr = ctx->rings;
-		break;
+		return ctx->rings;
 	case IORING_OFF_SQES:
 		/* Don't allow mmap if the ring was setup without it */
 		if (ctx->flags & IORING_SETUP_NO_MMAP)
 			return ERR_PTR(-EINVAL);
-		ptr = ctx->sq_sqes;
-		break;
+		return ctx->sq_sqes;
 	case IORING_OFF_PBUF_RING: {
 		struct io_buffer_list *bl;
 		unsigned int bgid;
@@ -3494,11 +3597,22 @@ static void *io_uring_validate_mmap_request(struct file *file,
 	return ptr;
 }
 
+int io_uring_mmap_pages(struct io_ring_ctx *ctx, struct vm_area_struct *vma,
+			struct page **pages, int npages)
+{
+	unsigned long nr_pages = npages;
+
+	vm_flags_set(vma, VM_DONTEXPAND);
+	return vm_insert_pages(vma, vma->vm_start, pages, &nr_pages);
+}
+
 #ifdef CONFIG_MMU
 
 static __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
 {
+	struct io_ring_ctx *ctx = file->private_data;
 	size_t sz = vma->vm_end - vma->vm_start;
+	long offset = vma->vm_pgoff << PAGE_SHIFT;
 	unsigned long pfn;
 	void *ptr;
 
@@ -3506,6 +3620,16 @@ static __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
 	if (IS_ERR(ptr))
 		return PTR_ERR(ptr);
 
+	switch (offset & IORING_OFF_MMAP_MASK) {
+	case IORING_OFF_SQ_RING:
+	case IORING_OFF_CQ_RING:
+		return io_uring_mmap_pages(ctx, vma, ctx->ring_pages,
+						ctx->n_ring_pages);
+	case IORING_OFF_SQES:
+		return io_uring_mmap_pages(ctx, vma, ctx->sqe_pages,
+						ctx->n_sqe_pages);
+	}
+
 	pfn = virt_to_phys(ptr) >> PAGE_SHIFT;
 	return remap_pfn_range(vma, vma->vm_start, pfn, sz, vma->vm_page_prot);
 }
@@ -3795,7 +3919,7 @@ static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,
 		return -EOVERFLOW;
 
 	if (!(ctx->flags & IORING_SETUP_NO_MMAP))
-		rings = io_mem_alloc(size);
+		rings = io_pages_map(&ctx->ring_pages, &ctx->n_ring_pages, size);
 	else
 		rings = io_rings_map(ctx, p->cq_off.user_addr, size);
 
@@ -3820,7 +3944,7 @@ static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,
 	}
 
 	if (!(ctx->flags & IORING_SETUP_NO_MMAP))
-		ptr = io_mem_alloc(size);
+		ptr = io_pages_map(&ctx->sqe_pages, &ctx->n_sqe_pages, size);
 	else
 		ptr = io_sqes_map(ctx, p->sq_off.user_addr, size);
 
diff --git a/io_uring/io_uring.h b/io_uring/io_uring.h
index 57658d24a73e..ea0b8acabc71 100644
--- a/io_uring/io_uring.h
+++ b/io_uring/io_uring.h
@@ -55,6 +55,8 @@ bool io_fill_cqe_req_aux(struct io_kiocb *req, bool defer, s32 res, u32 cflags);
 void __io_commit_cqring_flush(struct io_ring_ctx *ctx);
 
 struct page **io_pin_pages(unsigned long ubuf, unsigned long len, int *npages);
+int io_uring_mmap_pages(struct io_ring_ctx *ctx, struct vm_area_struct *vma,
+			struct page **pages, int npages);
 
 struct file *io_file_get_normal(struct io_kiocb *req, int fd);
 struct file *io_file_get_fixed(struct io_kiocb *req, int fd,
-- 
2.49.0

Re: [PATCH 6.6 000/166] 6.6.84-rc1 review

[Greg Kroah-Hartman]

On Thu, Mar 20, 2025 at 07:02:23AM -0600, Jens Axboe wrote:
> On 3/20/25 6:55 AM, Jens Axboe wrote:
> > On 3/19/25 5:51 PM, Greg Kroah-Hartman wrote:
> >> On Wed, Mar 19, 2025 at 10:37:20AM -0600, Jens Axboe wrote:
> >>> On 3/19/25 10:33 AM, Naresh Kamboju wrote:
> >>>> On Wed, 19 Mar 2025 at 20:09, Greg Kroah-Hartman
> >>>> <gregkh@linuxfoundation.org> wrote:
> >>>>>
> >>>>> This is the start of the stable review cycle for the 6.6.84 release.
> >>>>> There are 166 patches in this series, all will be posted as a response
> >>>>> to this one.  If anyone has any issues with these being applied, please
> >>>>> let me know.
> >>>>>
> >>>>> Responses should be made by Fri, 21 Mar 2025 14:29:55 +0000.
> >>>>> Anything received after that time might be too late.
> >>>>>
> >>>>> The whole patch series can be found in one patch at:
> >>>>>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.84-rc1.gz
> >>>>> or in the git tree and branch at:
> >>>>>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> >>>>> and the diffstat can be found below.
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> greg k-h
> >>>>
> >>>> Regressions on mips the rt305x_defconfig builds failed with gcc-12
> >>>> the stable-rc v6.6.83-167-gd16a828e7b09
> >>>>
> >>>> First seen on the v6.6.83-167-gd16a828e7b09
> >>>>  Good: v6.6.83
> >>>>  Bad: v6.6.83-167-gd16a828e7b09
> >>>>
> >>>> * mips, build
> >>>>   - gcc-12-rt305x_defconfig
> >>>>
> >>>> Regression Analysis:
> >>>>  - New regression? Yes
> >>>>  - Reproducibility? Yes
> >>>>
> >>>> Build regression: mips implicit declaration of function 'vunmap'
> >>>> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> >>>
> >>> Ah that's my fault, forgot to include the backport of:
> >>>
> >>> commit 62346c6cb28b043f2a6e95337d9081ec0b37b5f5
> >>> Author: Jens Axboe <axboe@kernel.dk>
> >>> Date:   Sat Mar 16 07:21:43 2024 -0600
> >>>
> >>>     mm: add nommu variant of vm_insert_pages()
> >>>
> >>> for 6.1-stable and 6.6-stable. Greg, can you just cherry pick that one?
> >>> It'll pick cleanly into both, should go before the io_uring mmap series
> >>> obviously.
> >>>
> >>> Sorry about that! I did have it in my local trees, but for some reason
> >>> forgot to include it in the sent in series.
> >>
> >> Wait, this is already in the 6.6.y and 6.1.y queues, so this can't be
> >> the fix.  Was there a fixup for that commit somewhere else that I'm
> >> missing?
> > 
> > Huh indeed, guess I didn't mess up in the first place. What is going on
> > here indeed... Is that mips config NOMMU yet doesn't link in mm/nommu.o?
> > 
> > Checking, and no, it definitely has MMU=y in the config. Guess I
> > should've read the initial report more closely, it's simply missing the
> > vunmap definition. Adding linux/vmalloc.h to io_uring/io_uring.c should
> > fix it.
> > 
> > How do we want to deal with this?
> 
> Either fold in the hunk from the previous email, or replace patch 2 in
> the series I sent with this one instead, which adds the vmalloc.h
> include. That should sort out the issue without needing add-on patches
> that don't exist upstream.

Now replaced, thanks!