public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jeff Moyer <[email protected]>
To: Jens Axboe <[email protected]>
Cc: io-uring <[email protected]>
Subject: Re: [PATCH] io_uring: don't allow IORING_SETUP_NO_MMAP rings on highmem pages
Date: Tue, 03 Oct 2023 12:30:02 -0400	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]> (Jens Axboe's message of "Tue, 3 Oct 2023 10:02:35 -0600")

Hi, Jens,

Jens Axboe <[email protected]> writes:

> On at least arm32, but presumably any arch with highmem, if the
> application passes in memory that resides in highmem for the rings,
> then we should fail that ring creation. We fail it with -EINVAL, which
> is what kernels that don't support IORING_SETUP_NO_MMAP will do as well.
>
> Cc: [email protected]
> Fixes: 03d89a2de25b ("io_uring: support for user allocated memory for rings/sqes")
> Signed-off-by: Jens Axboe <[email protected]>
>
> ---
>
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index 783ed0fff71b..d839a80a6751 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -2686,7 +2686,7 @@ static void *__io_uaddr_map(struct page ***pages, unsigned short *npages,
>  {
>  	struct page **page_array;
>  	unsigned int nr_pages;
> -	int ret;
> +	int ret, i;
>  
>  	*npages = 0;
>  
> @@ -2716,6 +2716,20 @@ static void *__io_uaddr_map(struct page ***pages, unsigned short *npages,
>  	 */
>  	if (page_array[0] != page_array[ret - 1])
>  		goto err;
> +
> +	/*
> +	 * Can't support mapping user allocated ring memory on 32-bit archs
> +	 * where it could potentially reside in highmem. Just fail those with
> +	 * -EINVAL, just like we did on kernels that didn't support this
> +	 * feature.
> +	 */
> +	for (i = 0; i < nr_pages; i++) {
> +		if (PageHighMem(page_array[i])) {
> +			ret = -EINVAL;
> +			goto err;
> +		}
> +	}
> +

What do you think about throwing a printk_once in there that explains
the problem?  I'm worried that this will fail somewhat randomly, and it
may not be apparent to the user why.  We should also add documentation,
of course, and encourage developers to add fallbacks for this case.

-Jeff


  reply	other threads:[~2023-10-03 16:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 16:02 [PATCH] io_uring: don't allow IORING_SETUP_NO_MMAP rings on highmem pages Jens Axboe
2023-10-03 16:30 ` Jeff Moyer [this message]
2023-10-03 16:27   ` Jens Axboe
2023-10-03 18:24     ` Jeff Moyer
2023-10-03 18:25       ` 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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox