Re: [PATCHSET 0/5] User mapped provided buffer rings

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Helge Deller]

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?

Helge

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Helge Deller]

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>

Helge

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

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>

send-zerocopy.t takes about ~20 seconds for me on modern hardware, so
that one likely just needs a longer timeout to work. Running it here on
my PA8900:

axboe@c8000 ~/g/liburing (master)> time test/send-zerocopy.t 

________________________________________________________
Executed in  115.08 secs    fish           external
   usr time   63.70 secs    1.08 millis   63.70 secs
   sys time   57.25 secs    4.26 millis   57.24 secs

which on that box is almost twice as long as the normal timeout for
the test script.

For file-verify.t, that one should work with the current tree. The issue
there is the use of registered buffers, and I added a parisc hack for
that. Maybe it's too specific to the PA8900 (the 128 byte stride). If
your tree does have:

commit 4c4fd1843bf284c0063c3a0f8822cb2d352b20c0 (origin/master, origin/HEAD, master)
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Mar 15 11:34:54 2023 -0600

    test/file-verify: add dcache sync for parisc

then please experiment with that. 64 might be the correct value here and
I just got lucky with my testing...
be interesting to see 

For the remainder, they are all related to the buffer ring, which is
what is enabled by this series. But the tests don't use that yet, so
they will fail just like they do without the patch. In the
ring-buf-alloc branch of liburing there's the start of adding helpers to
setup the buffer rings, and then we can switch them to the mmap()
approach without much trouble. It's just not done yet, I will add a
patch in there to do that.

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[John David Anglin]

On 2023-03-15 4:38 p.m., Jens Axboe wrote:
> For file-verify.t, that one should work with the current tree. The issue
> there is the use of registered buffers, and I added a parisc hack for
> that. Maybe it's too specific to the PA8900 (the 128 byte stride). If
> your tree does have:
The 128 byte stride is only used on PA8800 and PA8900 processors. Other PA 2.0 processors
use a 64 byte stride.  PA 1.1 processors need a 32 byte stride.

The following gcc defines are available: _PA_RISC2_0, _PA_RISC1_1 and _PA_RISC1_0.

/proc/cpuinfo provides the CPU type but I'm not aware of any easy way to access the stride value
from userspace.  It's available from the PDC_CACHE call and it's used in the kernel.
>
> commit 4c4fd1843bf284c0063c3a0f8822cb2d352b20c0 (origin/master, origin/HEAD, master)
> Author: Jens Axboe<axboe@kernel.dk>
> Date:   Wed Mar 15 11:34:54 2023 -0600
>
>      test/file-verify: add dcache sync for parisc
>
> then please experiment with that. 64 might be the correct value here and
> I just got lucky with my testing...
> be interesting to see

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/15/23 3:04?PM, John David Anglin wrote:
> On 2023-03-15 4:38 p.m., Jens Axboe wrote:
>> For file-verify.t, that one should work with the current tree. The issue
>> there is the use of registered buffers, and I added a parisc hack for
>> that. Maybe it's too specific to the PA8900 (the 128 byte stride). If
>> your tree does have:
> The 128 byte stride is only used on PA8800 and PA8900 processors. Other PA 2.0 processors
> use a 64 byte stride.  PA 1.1 processors need a 32 byte stride.
> 
> The following gcc defines are available: _PA_RISC2_0, _PA_RISC1_1 and _PA_RISC1_0.

Ah perfect!

> /proc/cpuinfo provides the CPU type but I'm not aware of any easy way to access the stride value
> from userspace.  It's available from the PDC_CACHE call and it's used in the kernel.

model		: 9000/785/C8000 - Crestone Peak Mako+ Slow [128]

I guess that's why it worked for me. OK, will ponder how to define that,
I think just going lowest common denominator is enough for now.

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

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:

axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/buf-ring.t
axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/send_recvmsg.t 
axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/ringbuf-read.t 
axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/poll-race-mshot.t 
axboe@c8000 ~/g/liburing (ring-buf-alloc)> git describe
liburing-2.3-245-g8534193

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Helge Deller]

On 3/15/23 22:18, 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:
>
> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/buf-ring.t
> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/send_recvmsg.t
> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/ringbuf-read.t
> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/poll-race-mshot.t
> axboe@c8000 ~/g/liburing (ring-buf-alloc)> git describe
> liburing-2.3-245-g8534193

Yes, verified. All tests in that branch pass now.

Thanks!
Helge

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/16/23 4:18 AM, Helge Deller wrote:
> On 3/15/23 22:18, 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:
>>
>> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/buf-ring.t
>> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/send_recvmsg.t
>> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/ringbuf-read.t
>> axboe@c8000 ~/g/liburing (ring-buf-alloc)> test/poll-race-mshot.t
>> axboe@c8000 ~/g/liburing (ring-buf-alloc)> git describe
>> liburing-2.3-245-g8534193
> 
> Yes, verified. All tests in that branch pass now.

Nice, thanks for re-testing!

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[John David Anglin]

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  dave.anglin@bell.net

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/16/23 1:08?PM, John David Anglin wrote:
> 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.

We can do that, you'd just want to add that check in io_pin_pbuf_ring()
when the pages have been mapped AND we're on an arch that has those
kinds of requirements. Maybe something like the below, totally
untested...

I am puzzled where the crash is coming from, though. It should just hit
the -ENOBUFS case as it can't find a buffer, and that'd terminate that
request. Which does seem to be what is happening above, that is really
no different than an attempt to read/receive from a buffer group that
has no buffers available. So a bit puzzling on what makes your kernel
crash after that has happened, as we do have generic test cases that
exercise that explicitly.


diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
index cd1d9dddf58e..73f290aca7f1 100644
--- a/io_uring/kbuf.c
+++ b/io_uring/kbuf.c
@@ -491,6 +491,15 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
 		return PTR_ERR(pages);
 
 	br = page_address(pages[0]);
+#ifdef SHM_COLOUR
+	if ((reg->ring_addr & (unsigned long) br) & SHM_COLOUR) {
+		int i;
+
+		for (i = 0; i < nr_pages; i++)
+			unpin_user_page(pages[i]);
+		return -EINVAL;
+	}
+#endif
 	bl->buf_pages = pages;
 	bl->buf_nr_pages = nr_pages;
 	bl->buf_ring = br;

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/16/23 1:46 PM, Jens Axboe wrote:
> On 3/16/23 1:08?PM, John David Anglin wrote:
>> 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.
> 
> We can do that, you'd just want to add that check in io_pin_pbuf_ring()
> when the pages have been mapped AND we're on an arch that has those
> kinds of requirements. Maybe something like the below, totally
> untested...
> 
> I am puzzled where the crash is coming from, though. It should just hit
> the -ENOBUFS case as it can't find a buffer, and that'd terminate that
> request. Which does seem to be what is happening above, that is really
> no different than an attempt to read/receive from a buffer group that
> has no buffers available. So a bit puzzling on what makes your kernel
> crash after that has happened, as we do have generic test cases that
> exercise that explicitly.
> 
> 
> diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
> index cd1d9dddf58e..73f290aca7f1 100644
> --- a/io_uring/kbuf.c
> +++ b/io_uring/kbuf.c
> @@ -491,6 +491,15 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
>  		return PTR_ERR(pages);
>  
>  	br = page_address(pages[0]);
> +#ifdef SHM_COLOUR
> +	if ((reg->ring_addr & (unsigned long) br) & SHM_COLOUR) {

& (SHM_COLOUR - 1)) {

of course...

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/16/23 8:09?PM, Jens Axboe wrote:
> On 3/16/23 1:46?PM, Jens Axboe wrote:
>> On 3/16/23 1:08?PM, John David Anglin wrote:
>>> 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.
>>
>> We can do that, you'd just want to add that check in io_pin_pbuf_ring()
>> when the pages have been mapped AND we're on an arch that has those
>> kinds of requirements. Maybe something like the below, totally
>> untested...
>>
>> I am puzzled where the crash is coming from, though. It should just hit
>> the -ENOBUFS case as it can't find a buffer, and that'd terminate that
>> request. Which does seem to be what is happening above, that is really
>> no different than an attempt to read/receive from a buffer group that
>> has no buffers available. So a bit puzzling on what makes your kernel
>> crash after that has happened, as we do have generic test cases that
>> exercise that explicitly.
>>
>>
>> diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
>> index cd1d9dddf58e..73f290aca7f1 100644
>> --- a/io_uring/kbuf.c
>> +++ b/io_uring/kbuf.c
>> @@ -491,6 +491,15 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
>>  		return PTR_ERR(pages);
>>  
>>  	br = page_address(pages[0]);
>> +#ifdef SHM_COLOUR
>> +	if ((reg->ring_addr & (unsigned long) br) & SHM_COLOUR) {
> 
> & (SHM_COLOUR - 1)) {
> 
> of course...

Full version, I think this should do the right thing. If the kernel and
app side isn't aligned on the same SHM_COLOUR boundary, we'll return
-EINVAL rather than setup the ring.

For the ring-buf-alloc branch, this is handled automatically. But we
should, as you mentioned, ensure that the kernel doesn't allow setting
something up that will not work.

Note that this is still NOT related to your hang, I honestly have no
idea what that could be. Unfortunately parisc doesn't have a lot of
debugging aids for this... Could even be a generic kernel issue. I
looked up your rp3440, and it sounds like we have basically the same
setup. I'm running a dual socket PA8900 at 1GHz.


diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
index cd1d9dddf58e..7c6544456f90 100644
--- a/io_uring/kbuf.c
+++ b/io_uring/kbuf.c
@@ -491,6 +491,15 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
 		return PTR_ERR(pages);
 
 	br = page_address(pages[0]);
+#ifdef SHM_COLOUR
+	if ((reg->ring_addr | (unsigned long) br) & (SHM_COLOUR - 1)) {
+		int i;
+
+		for (i = 0; i < nr_pages; i++)
+			unpin_user_page(pages[i]);
+		return -EINVAL;
+	}
+#endif
 	bl->buf_pages = pages;
 	bl->buf_nr_pages = nr_pages;
 	bl->buf_ring = br;

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[John David Anglin]

On 2023-03-16 10:17 p.m., Jens Axboe wrote:
> On 3/16/23 8:09?PM, Jens Axboe wrote:
>> On 3/16/23 1:46?PM, Jens Axboe wrote:
>>> On 3/16/23 1:08?PM, John David Anglin wrote:
>>>> 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.
>>> We can do that, you'd just want to add that check in io_pin_pbuf_ring()
>>> when the pages have been mapped AND we're on an arch that has those
>>> kinds of requirements. Maybe something like the below, totally
>>> untested...
>>>
>>> I am puzzled where the crash is coming from, though. It should just hit
>>> the -ENOBUFS case as it can't find a buffer, and that'd terminate that
>>> request. Which does seem to be what is happening above, that is really
>>> no different than an attempt to read/receive from a buffer group that
>>> has no buffers available. So a bit puzzling on what makes your kernel
>>> crash after that has happened, as we do have generic test cases that
>>> exercise that explicitly.
>>>
>>>
>>> diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
>>> index cd1d9dddf58e..73f290aca7f1 100644
>>> --- a/io_uring/kbuf.c
>>> +++ b/io_uring/kbuf.c
>>> @@ -491,6 +491,15 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
>>>   		return PTR_ERR(pages);
>>>   
>>>   	br = page_address(pages[0]);
>>> +#ifdef SHM_COLOUR
>>> +	if ((reg->ring_addr & (unsigned long) br) & SHM_COLOUR) {
>> & (SHM_COLOUR - 1)) {
>>
>> of course...
> Full version, I think this should do the right thing. If the kernel and
> app side isn't aligned on the same SHM_COLOUR boundary, we'll return
> -EINVAL rather than setup the ring.
>
> For the ring-buf-alloc branch, this is handled automatically. But we
> should, as you mentioned, ensure that the kernel doesn't allow setting
> something up that will not work.
>
> Note that this is still NOT related to your hang, I honestly have no
> idea what that could be. Unfortunately parisc doesn't have a lot of
> debugging aids for this... Could even be a generic kernel issue. I
> looked up your rp3440, and it sounds like we have basically the same
> setup. I'm running a dual socket PA8900 at 1GHz.
With this change, test/poll-race-mshot.t no longer crashes my rp34404.

Results on master are:
Tests timed out (2): <a4c0b3decb33.t> <send-zerocopy.t>
Tests failed (1): <fd-pass.t>

Running test buf-ring.t 0 sec [0]
Running test poll-race-mshot.t Skipped

Results on ring-buf-alloc are:
Tests timed out (2): <a4c0b3decb33.t> <send-zerocopy.t>
Tests failed (2): <buf-ring.t> <fd-pass.t>

Running test buf-ring.t register buf ring failed -22
test_full_page_reg failed
Test buf-ring.t failed with ret 1
Running test poll-race-mshot.t 4 sec

Without the change, the test/poll-race-mshot.t test causes HPMCs on my rp3440 (two processors).
The front status LED turns red and the event is logged in the hardware system log.  I looked at where
the HPMC occurred but the locations were unrelated to io_uring.

I tried running the test under strace.  With output to console, the test doesn't cause a crash and it more
or less exits normally (need ^C to kill one process).  With output to file, system crashes and file is empty
on reboot.

fd-pass.t fail is new.

I don't think buf-ring.t and send_recvmsg.t actually pass on master with change.  Tests probably need
updating.

The "Bad cqe res -233" messages are gone😁

Aside from additional server related stuff, the rp3440 is architecturally similar to c8000.  Both used PA8800
and PA8900 CPUs.

>
>
> diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
> index cd1d9dddf58e..7c6544456f90 100644
> --- a/io_uring/kbuf.c
> +++ b/io_uring/kbuf.c
> @@ -491,6 +491,15 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
>   		return PTR_ERR(pages);
>   
>   	br = page_address(pages[0]);
> +#ifdef SHM_COLOUR
> +	if ((reg->ring_addr | (unsigned long) br) & (SHM_COLOUR - 1)) {
> +		int i;
> +
> +		for (i = 0; i < nr_pages; i++)
> +			unpin_user_page(pages[i]);
> +		return -EINVAL;
> +	}
> +#endif
>   	bl->buf_pages = pages;
>   	bl->buf_nr_pages = nr_pages;
>   	bl->buf_ring = br;
>

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/17/23 9:36?AM, John David Anglin wrote:
> On 2023-03-16 10:17 p.m., Jens Axboe wrote:
>> On 3/16/23 8:09?PM, Jens Axboe wrote:
>>> On 3/16/23 1:46?PM, Jens Axboe wrote:
>>>> On 3/16/23 1:08?PM, John David Anglin wrote:
>>>>> 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.
>>>> We can do that, you'd just want to add that check in io_pin_pbuf_ring()
>>>> when the pages have been mapped AND we're on an arch that has those
>>>> kinds of requirements. Maybe something like the below, totally
>>>> untested...
>>>>
>>>> I am puzzled where the crash is coming from, though. It should just hit
>>>> the -ENOBUFS case as it can't find a buffer, and that'd terminate that
>>>> request. Which does seem to be what is happening above, that is really
>>>> no different than an attempt to read/receive from a buffer group that
>>>> has no buffers available. So a bit puzzling on what makes your kernel
>>>> crash after that has happened, as we do have generic test cases that
>>>> exercise that explicitly.
>>>>
>>>>
>>>> diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
>>>> index cd1d9dddf58e..73f290aca7f1 100644
>>>> --- a/io_uring/kbuf.c
>>>> +++ b/io_uring/kbuf.c
>>>> @@ -491,6 +491,15 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
>>>>           return PTR_ERR(pages);
>>>>         br = page_address(pages[0]);
>>>> +#ifdef SHM_COLOUR
>>>> +    if ((reg->ring_addr & (unsigned long) br) & SHM_COLOUR) {
>>> & (SHM_COLOUR - 1)) {
>>>
>>> of course...
>> Full version, I think this should do the right thing. If the kernel and
>> app side isn't aligned on the same SHM_COLOUR boundary, we'll return
>> -EINVAL rather than setup the ring.
>>
>> For the ring-buf-alloc branch, this is handled automatically. But we
>> should, as you mentioned, ensure that the kernel doesn't allow setting
>> something up that will not work.
>>
>> Note that this is still NOT related to your hang, I honestly have no
>> idea what that could be. Unfortunately parisc doesn't have a lot of
>> debugging aids for this... Could even be a generic kernel issue. I
>> looked up your rp3440, and it sounds like we have basically the same
>> setup. I'm running a dual socket PA8900 at 1GHz.
> With this change, test/poll-race-mshot.t no longer crashes my rp34404.
> 
> Results on master are:
> Tests timed out (2): <a4c0b3decb33.t> <send-zerocopy.t>

Take too long on your system.. Would work with bigger timeout.

> Tests failed (1): <fd-pass.t>

This one is missing a patch that'll go upstream today, and it's testing
for it and hence failing.

> Running test buf-ring.t 0 sec [0]
> Running test poll-race-mshot.t Skipped
> 
> Results on ring-buf-alloc are:
> Tests timed out (2): <a4c0b3decb33.t> <send-zerocopy.t>
> Tests failed (2): <buf-ring.t> <fd-pass.t>
> 
> Running test buf-ring.t register buf ring failed -22
> test_full_page_reg failed
> Test buf-ring.t failed with ret 1

The buf-ring failure with the patch from my previous message is because
it manually tries to set up a ring with an address that won't work. The
test case itself never uses the ring, it's just a basic
register/unregister test. So would just need updating if that patch goes
in to pass on hppa, there's nothing inherently wrong here.

> Running test poll-race-mshot.t 4 sec
> 
> Without the change, the test/poll-race-mshot.t test causes HPMCs on my rp3440 (two processors).
> The front status LED turns red and the event is logged in the hardware system log.  I looked at where
> the HPMC occurred but the locations were unrelated to io_uring.
> 
> I tried running the test under strace.  With output to console, the test doesn't cause a crash and it more
> or less exits normally (need ^C to kill one process).  With output to file, system crashes and file is empty
> on reboot.
> 
> fd-pass.t fail is new.
> 
> I don't think buf-ring.t and send_recvmsg.t actually pass on master with change.  Tests probably need
> updating.
> 
> The "Bad cqe res -233" messages are gone?

Those happened because we filled the buffers on the user side, but the
kernel side didn't see them due to the aliasing issue. Which means that
ring provided buffers now work.

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[John David Anglin]

On 2023-03-17 11:57 a.m., Jens Axboe wrote:
>> Running test buf-ring.t register buf ring failed -22
>> test_full_page_reg failed
>> Test buf-ring.t failed with ret 1
> The buf-ring failure with the patch from my previous message is because
> it manually tries to set up a ring with an address that won't work. The
> test case itself never uses the ring, it's just a basic
> register/unregister test. So would just need updating if that patch goes
> in to pass on hppa, there's nothing inherently wrong here.
>
I would suggest it.  From page F-7 of the PA-RISC 2.0 Architecture:

    All other uses of non-equivalent aliasing (including simultaneously enabling multiple non-equivalently
    aliased translations where one or more allow for write access) are prohibited, and can cause machine
    checks or silent data corruption, including data corruption of unrelated memory on unrelated pages.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/17/23 10:15?AM, John David Anglin wrote:
> On 2023-03-17 11:57 a.m., Jens Axboe wrote:
>>> Running test buf-ring.t register buf ring failed -22
>>> test_full_page_reg failed
>>> Test buf-ring.t failed with ret 1
>> The buf-ring failure with the patch from my previous message is because
>> it manually tries to set up a ring with an address that won't work. The
>> test case itself never uses the ring, it's just a basic
>> register/unregister test. So would just need updating if that patch goes
>> in to pass on hppa, there's nothing inherently wrong here.
>>
> I would suggest it.  From page F-7 of the PA-RISC 2.0 Architecture:
> 
>    All other uses of non-equivalent aliasing (including simultaneously
>    enabling multiple non-equivalently aliased translations where one
>    or more allow for write access) are prohibited, and can cause
>    machine checks or silent data corruption, including data corruption
>    of unrelated memory on unrelated pages.

I did add a patch to skip that sub-test on hppa, as there's just no way
to make that one work as it relies on manually aligning memory to
trigger an issue in an older kernel. So the test should pass now in the
liburing master branch.

I'll send out the alignment check patch and we can queue that up for
6.4.

-- 
Jens Axboe

Re: [PATCHSET 0/5] User mapped provided buffer rings

[Jens Axboe]

On 3/15/23 2:03?PM, 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?

I don't have any sparc boxes, unfortunately.. But yes, would be
interesting to test on sparc for sure.

I do all my testing on aarch64 and x86-64, and I know that powerpc/s390
has been tested too. But in terms of coverage and regular testing, it's
just the former two.

-- 
Jens Axboe

Re: [PATCH 5/5] io_uring: add support for user mapped provided buffer ring

[Ammar Faizi]

I tried to verify the for-next build report. And I think this doesn't
look right.

On Tue, Mar 14, 2023 at 11:16:42AM -0600, Jens Axboe wrote:
> @@ -214,15 +215,27 @@ static int __io_remove_buffers(struct io_ring_ctx *ctx,
>  	if (!nbufs)
>  		return 0;
>  
> -	if (bl->is_mapped && bl->buf_nr_pages) {
> -		int j;
> -
> +	if (bl->is_mapped) {
>  		i = bl->buf_ring->tail - bl->head;
                    ^^^^^^^^^^^^^^^^^^

Dereference bl->buf_ring. It implies bl->buf_ring is not NULL.

> -		for (j = 0; j < bl->buf_nr_pages; j++)
> -			unpin_user_page(bl->buf_pages[j]);
> -		kvfree(bl->buf_pages);
> -		bl->buf_pages = NULL;
> -		bl->buf_nr_pages = 0;
> +		if (bl->is_mmap) {
> +			if (bl->buf_ring) {
                        ^^^^^^^^^^^^^^^^^

A NULL check against bl->buf_ring here. If it was possible to be NULL,
wouldn't the above dereference BUG()?

-- 
Ammar Faizi

Re: [PATCH 5/5] io_uring: add support for user mapped provided buffer ring

[Jens Axboe]

On 3/16/23 12:07 PM, Ammar Faizi wrote:
> I tried to verify the for-next build report. And I think this doesn't
> look right.
> 
> On Tue, Mar 14, 2023 at 11:16:42AM -0600, Jens Axboe wrote:
>> @@ -214,15 +215,27 @@ static int __io_remove_buffers(struct io_ring_ctx *ctx,
>>  	if (!nbufs)
>>  		return 0;
>>  
>> -	if (bl->is_mapped && bl->buf_nr_pages) {
>> -		int j;
>> -
>> +	if (bl->is_mapped) {
>>  		i = bl->buf_ring->tail - bl->head;
>                     ^^^^^^^^^^^^^^^^^^
> 
> Dereference bl->buf_ring. It implies bl->buf_ring is not NULL.
> 
>> -		for (j = 0; j < bl->buf_nr_pages; j++)
>> -			unpin_user_page(bl->buf_pages[j]);
>> -		kvfree(bl->buf_pages);
>> -		bl->buf_pages = NULL;
>> -		bl->buf_nr_pages = 0;
>> +		if (bl->is_mmap) {
>> +			if (bl->buf_ring) {
>                         ^^^^^^^^^^^^^^^^^
> 
> A NULL check against bl->buf_ring here. If it was possible to be NULL,
> wouldn't the above dereference BUG()?

I don't think it's possible and we should probably just remove that
latter check. If the buffer group is visible, either method will have
a valid ->buf_ring IFF is_mmap/is_mapped is set.

-- 
Jens Axboe