On 4/19/24 12:08, Pavel Begunkov wrote:
Please, don't take directly, conflicts with io_uring.
When everyone is happy with the patches, Jens and Jakub will hopefully
help to merge them. E.g. first staging net/ specific changes [1] and then
handling all conflicts on the io_uring side.
[1]
boe
Signed-off-by: Pavel Begunkov
---
io_uring/notif.c | 71 +++-
io_uring/notif.h | 3 ++
2 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/io_uring/notif.c b/io_uring/notif.c
index 26680176335f..d58cdc01e691 100644
--- a/io_uring/noti
io_notif_flush() is partially duplicating io_tx_ubuf_complete(), so
instead of duplicating it, make the flush call io_tx_ubuf_complete.
Reviewed-by: Jens Axboe
Signed-off-by: Pavel Begunkov
---
io_uring/notif.c | 6 +++---
io_uring/notif.h | 9 +++--
2 files changed, 6 insertions(+), 9
ubuf_info, otherwise we could end up in a situation
when the send would not be able to progress.
Reviewed-by: Jens Axboe
Reviewed-by: David Ahern
Signed-off-by: Pavel Begunkov
---
include/linux/skbuff.h | 2 ++
net/core/skbuff.c | 20 ++--
2 files changed, 16 insert
which is currently passed in struct msghdr.
Reviewed-by: Jens Axboe
Reviewed-by: David Ahern
Signed-off-by: Pavel Begunkov
---
drivers/net/tap.c | 2 +-
drivers/net/tun.c | 2 +-
drivers/net/xen-netback/common.h| 5 ++---
drivers/net/xen-netback/interfac
/notif-stacking-v2
First two patches based on net-next:
https://github.com/isilence/linux.git iou-sendzc/notif-stacking-v2-netonly
v2: convert xen-netback to ubuf_info_ops (patch 1)
drop two separately merged io_uring patches
Pavel Begunkov (4):
net: extend ubuf_info callback to ops struc
2) close the other end
3) send() fails, probably without SIGPIPE (because io-wq)
4) userspace retries send() and inline execution delivers SIGPIPE
But I guess we don't really care. In any case, let's drop stable tag,
maybe? I don't see a reason for it, considering that stable tries hard
to preserve ABI.
--
Pavel Begunkov
ret != expected_ret)
> + if (ret < min_ret)
> req_set_fail_links(req);
> __io_req_complete(req, issue_flags, ret, 0);
> return 0;
>
> Which means the default of min_ret = 0 would result in:
>
> if (ret < 0)
> req_set_fail_links(req);
>
> again...
>
>>>> Sounds like 2/2 might too, does it?
>>>
>>> Do you think any application really expects to get a SIGPIPE
>>> when calling io_uring_enter()?
>>
>> If it was about what I think I would remove lots of old garbage :)
>> I doubt it wasn't working well before, e.g. because of iowq, but
>> who knows
>
> Yes, it was inconsistent before and now it's reliable.
--
Pavel Begunkov
rn ret;
> iov_count = iov_iter_count(iter);
> - io_size = ret;
> + io_size = iov_count;
> req->result = io_size;
>
> /* Ensure we clear previously set non-block flag */
>
--
Pavel Begunkov
On 22/09/2020 12:01, Arnd Bergmann wrote:
> On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov wrote:
>> On 22/09/2020 10:23, Arnd Bergmann wrote:
>>> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov
>>> wrote:
>>>> On 22/09/2020 03:58, Andy Lutomirski wrote
On 22/09/2020 10:23, Arnd Bergmann wrote:
> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov wrote:
>> On 22/09/2020 03:58, Andy Lutomirski wrote:
>>> On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov
>>> wrote:
>>> I may be looking at a different kernel tha
On 22/09/2020 03:58, Andy Lutomirski wrote:
> On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov wrote:
>>>>>>> Ah, so reading /dev/input/event* would suffer from the same issue,
>>>>>>> and that one would in fact be broken by your patch in the hypoth
On 22/09/2020 02:51, Andy Lutomirski wrote:
> On Mon, Sep 21, 2020 at 9:15 AM Pavel Begunkov wrote:
>>
>> On 21/09/2020 19:10, Pavel Begunkov wrote:
>>> On 20/09/2020 01:22, Andy Lutomirski wrote:
>>>>
>>>>> On Sep 19, 2020, at 2:16 PM, Arnd
s the wrong 'mm'.
And how so? io_uring uses mm of a submitter. The exception is SQPOLL
mode, but it requires CAP_SYS_ADMIN or CAP_SYS_NICE anyway.
> I suspect there are some really horrid security holes in that area.
>
> David.
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
--
Pavel Begunkov
2-bit process, you don't get to use io_uring. Would
> any real users actually care about that?
There were .net and\or wine (which AFAIK often works in compat) guys
experimenting with io_uring, they might want it.
--
Pavel Begunkov
V to IORING_OP_READV32 and then the core
>> code can know what that user pointer is pointing to.
--
Pavel Begunkov
On 21/09/2020 19:10, Pavel Begunkov wrote:
> On 20/09/2020 01:22, Andy Lutomirski wrote:
>>
>>> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote:
>>>
>>> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote:
>>>>> On Fri, Sep 18, 2020 at 8:1
de from a kernel thread.
>
> As for the other direction: what exactly are the desired bitness/arch
> semantics of io_uring? Is the operation bitness chosen by the io_uring
> creation or by the io_uring_enter() bitness?
It's rather the second one. Even though AFAIR it wasn't discussed
specifically, that how it works now (_partially_).
--
Pavel Begunkov
iter.count on success.
>>> This allows a better interface to import_iovec().
Reviewed-by: Pavel Begunkov
>>
>> This looks generall sane, but a comment below:
>>
>>> @@ -3123,7 +3123,7 @@ static int io_read(struct io_kiocb *req, bool
>>> force_nonbl
19 matches
Mail list logo
