public inbox for [email protected]
 help / color / mirror / Atom feed
From: John David Anglin <[email protected]>
To: Jens Axboe <[email protected]>, Helge Deller <[email protected]>,
	[email protected],
	linux-parisc <[email protected]>
Subject: Re: [PATCHSET 0/5] User mapped provided buffer rings
Date: Thu, 16 Mar 2023 15:08:17 -0400	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 2023-03-15 5:18 p.m., Jens Axboe wrote:
> On 3/15/23 2:38 PM, Jens Axboe wrote:
>> On 3/15/23 2:07?PM, Helge Deller wrote:
>>> On 3/15/23 21:03, Helge Deller wrote:
>>>> Hi Jens,
>>>>
>>>> Thanks for doing those fixes!
>>>>
>>>> On 3/14/23 18:16, Jens Axboe wrote:
>>>>> One issue that became apparent when running io_uring code on parisc is
>>>>> that for data shared between the application and the kernel, we must
>>>>> ensure that it's placed correctly to avoid aliasing issues that render
>>>>> it useless.
>>>>>
>>>>> The first patch in this series is from Helge, and ensures that the
>>>>> SQ/CQ rings are mapped appropriately. This makes io_uring actually work
>>>>> there.
>>>>>
>>>>> Patches 2..4 are prep patches for patch 5, which adds a variant of
>>>>> ring mapped provided buffers that have the kernel allocate the memory
>>>>> for them and the application mmap() it. This brings these mapped
>>>>> buffers in line with how the SQ/CQ rings are managed too.
>>>>>
>>>>> I'm not fully sure if this ONLY impacts archs that set SHM_COLOUR,
>>>>> of which there is only parisc, or if SHMLBA setting archs (of which
>>>>> there are others) are impact to any degree as well...
>>>> It would be interesting to find out. I'd assume that other arches,
>>>> e.g. sparc, might have similiar issues.
>>>> Have you tested your patches on other arches as well?
>>> By the way, I've now tested this series on current git head on an
>>> older parisc box (with PA8700 / PCX-W2 CPU).
>>>
>>> Results of liburing testsuite:
>>> Tests timed out (1): <send-zerocopy.t> - (may not be a failure)
>>> Tests failed (5): <buf-ring.t> <file-verify.t> <poll-race-mshot.t> <ringbuf-read.t> <send_recvmsg.t>
> If you update your liburing git copy, switch to the ring-buf-alloc branch,
> then all of the above should work:
With master liburing branch, test/poll-race-mshot.t still crashes my rp3440:
Running test poll-race-mshot.t Bad cqe res -233
Bad cqe res -233
Bad cqe res -233

There is a total lockup with no messages of any kind.

I think the io_uring code needs to reject user supplied ring buffers that are not equivalently mapped
to the corresponding kernel pages.  Don't know if it would be possible to reallocate kernel pages so they
are equivalently mapped.

Dave

-- 
John David Anglin  [email protected]


  parent reply	other threads:[~2023-03-16 19:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 17:16 [PATCHSET 0/5] User mapped provided buffer rings Jens Axboe
2023-03-14 17:16 ` [PATCH 1/5] io_uring: Adjust mapping wrt architecture aliasing requirements Jens Axboe
2023-07-12  4:43   ` matoro
2023-07-12 16:24     ` Helge Deller
2023-07-12 17:28       ` matoro
2023-07-12 19:05         ` Helge Deller
2023-07-12 20:30           ` Helge Deller
2023-07-13  0:35             ` matoro
2023-07-13  7:27               ` Helge Deller
2023-07-13 23:57                 ` matoro
2023-07-16  6:54                   ` Helge Deller
2023-07-16 18:03                     ` matoro
2023-07-16 20:54                       ` Helge Deller
2023-03-14 17:16 ` [PATCH 2/5] io_uring/kbuf: move pinning of provided buffer ring into helper Jens Axboe
2023-03-14 17:16 ` [PATCH 3/5] io_uring/kbuf: add buffer_list->is_mapped member Jens Axboe
2023-03-14 17:16 ` [PATCH 4/5] io_uring/kbuf: rename struct io_uring_buf_reg 'pad' to'flags' Jens Axboe
2023-03-14 17:16 ` [PATCH 5/5] io_uring: add support for user mapped provided buffer ring Jens Axboe
2023-03-16 18:07   ` Ammar Faizi
2023-03-16 18:42     ` Jens Axboe
2023-03-15 20:03 ` [PATCHSET 0/5] User mapped provided buffer rings Helge Deller
2023-03-15 20:07   ` Helge Deller
2023-03-15 20:38     ` Jens Axboe
2023-03-15 21:04       ` John David Anglin
2023-03-15 21:08         ` Jens Axboe
2023-03-15 21:18       ` Jens Axboe
2023-03-16 10:18         ` Helge Deller
2023-03-16 17:00           ` Jens Axboe
2023-03-16 19:08         ` John David Anglin [this message]
2023-03-16 19:46           ` Jens Axboe
2023-03-17  2:09             ` Jens Axboe
2023-03-17  2:17               ` Jens Axboe
2023-03-17 15:36                 ` John David Anglin
2023-03-17 15:57                   ` Jens Axboe
2023-03-17 16:15                     ` John David Anglin
2023-03-17 16:37                       ` Jens Axboe
2023-03-15 20:11   ` 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] \
    [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