linux-kernel - Re: [PATCH v2 3/3] io_uring: add splice(2) support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4d9c4fd2-d319-11bf-dfd2-e02e0f759a8b@gmail.com>
Date:   Mon, 17 Feb 2020 18:59:16 +0300
From:   Pavel Begunkov <asml.silence@...il.com>
To:     Stefan Metzmacher <metze@...ba.org>, Jens Axboe <axboe@...nel.dk>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        io-uring@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] io_uring: add splice(2) support

On 2/17/2020 6:54 PM, Stefan Metzmacher wrote:
> Am 17.02.20 um 16:40 schrieb Pavel Begunkov:
>> On 2/17/2020 6:18 PM, Stefan Metzmacher wrote:
>>> Hi Pavel,
>>>
>>>> +static int io_splice_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>>>> +{
>>>> +	struct io_splice* sp = &req->splice;
>>>> +	unsigned int valid_flags = SPLICE_F_FD_IN_FIXED | SPLICE_F_ALL;
>>>> +	int ret;
>>>> +
>>>> +	if (req->flags & REQ_F_NEED_CLEANUP)
>>>> +		return 0;
>>>> +
>>>> +	sp->file_in = NULL;
>>>> +	sp->off_in = READ_ONCE(sqe->off_in);
>>>> +	sp->off_out = READ_ONCE(sqe->off);
>>>> +	sp->len = READ_ONCE(sqe->len);
>>>> +	sp->flags = READ_ONCE(sqe->splice_flags);
>>>> +
>>>> +	if (unlikely(READ_ONCE(sqe->ioprio) || (sp->flags & ~valid_flags)))
>>>> +		return -EINVAL;
>>>
>>> Why is ioprio not supported?
>>
>> Because there is no way to set it without changing much of splice code.
>> It may be added later
>>
>> BTW, it seems, only opcodes cares about ioprio are read*/write*.
>> recv*() and send*() don't reject it, but never use.
> 
> I guess it's more like a hint, so should we just ignore it until
> it's passed down? Otherwise applications need to do some logic to
> find out if they can pass a value or not.

Then it probably needs to validate the value, but not just ignore it

> I'm not sure what's better, but I think it needs to be discussed...

meh, let's see what Jens think

-- 
Pavel Begunkov