public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: Dmitry Kadashev <[email protected]>
Cc: Jens Axboe <[email protected]>,
	Alexander Viro <[email protected]>,
	Christian Brauner <[email protected]>,
	linux-fsdevel <[email protected]>,
	io-uring <[email protected]>
Subject: Re: [PATCH v5 02/10] io_uring: add support for IORING_OP_MKDIRAT
Date: Mon, 12 Jul 2021 14:14:05 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOKbgA4XirCKFxC8EzURBJsEVXRmVTeqza0Rf5PW=ifB2H80_A@mail.gmail.com>

On 7/12/21 1:44 PM, Dmitry Kadashev wrote:
> On Wed, Jul 7, 2021 at 9:06 PM Pavel Begunkov <[email protected]> wrote:
>> On 6/28/21 9:17 AM, Dmitry Kadashev wrote:
>>> On Thu, Jun 24, 2021 at 7:22 PM Pavel Begunkov <[email protected]> wrote:
>>>> On 6/24/21 12:11 PM, Dmitry Kadashev wrote:
>>>>> On Wed, Jun 23, 2021 at 6:54 PM Pavel Begunkov <[email protected]> wrote:
>>>>>> On 6/23/21 7:41 AM, Dmitry Kadashev wrote:
>>>>>>> I'd imagine READ_ONCE is to be used in those checks though, isn't it? Some of
>>>>>>> the existing checks like this lack it too btw. I suppose I can fix those in a
>>>>>>> separate commit if that makes sense.
>>>>>>
>>>>>> When we really use a field there should be a READ_ONCE(),
>>>>>> but I wouldn't care about those we check for compatibility
>>>>>> reasons, but that's only my opinion.
>>>>>
>>>>> I'm not sure how the compatibility check reads are special. The code is
>>>>> either correct or not. If a compatibility check has correctness problems
>>>>> then it's pretty much as bad as any other part of the code having such
>>>>> problems, no?
>>>>
>>>> If it reads and verifies a values first, e.g. index into some internal
>>>> array, and then compiler plays a joke and reloads it, we might be
>>>> absolutely screwed expecting 'segfaults', kernel data leakages and all
>>>> the fun stuff.
>>>>
>>>> If that's a compatibility check, whether it's loaded earlier or later,
>>>> or whatever, it's not a big deal, the userspace can in any case change
>>>> the memory at any moment it wishes, even tightly around the moment
>>>> we're reading it.
>>>
>>> Sorry for the slow reply, I have to balance this with my actual job that
>>> is not directly related to the kernel development :)
>>>
>>> I'm no kernel concurrency expert (actually I'm not any kind of kernel
>>> expert), but my understanding is READ_ONCE does not just mean "do not
>>> read more than once", but rather "read exactly once" (and more than
>>> that), and if it's not applied then the compiler is within its rights to
>>> optimize the read out, so the compatibility check can effectively be
>>> disabled.
>>
>> Yep, as they say it's about all the "inventive" transformations
>> compilers can do, double read is just one of those that may turn very
>> nasty for us.
>>
>> One big difference for me is whether it have a potential to crash the
>> kernel or not, though it's just one side.
> 
> Ah, that makes sense.
> 
>> Compilers can't drop the check just because, it first should be proven
>> to be safe to do, and there are all sorts barriers around and
>> limitations on how CQEs and SQEs are used, making impossible to alias
>> memory. E.g. CQEs and SQEs can't be reused in a single syscall, they're
>> only written and read respectively, and so on. Maybe, the only one I'd
>> worry about is the call to io_commit_sqring(), i.e. for SQE reads not
>> happening after it, but we need to take a look whether it's
>> theoretically possible.
> 
> Thanks for the explanation, Pavel!

btw, that was for why we were rather reluctant about that. It could
be a good idea to add READ_ONCE as you mentioned, at least would be
less confusing. 

-- 
Pavel Begunkov

  reply	other threads:[~2021-07-12 13:14 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03  5:18 [PATCH v5 00/10] io_uring: add mkdir, [sym]linkat and mknodat support Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 01/10] fs: make do_mkdirat() take struct filename Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 02/10] io_uring: add support for IORING_OP_MKDIRAT Dmitry Kadashev
2021-06-22 11:41   ` Pavel Begunkov
2021-06-22 11:50     ` Pavel Begunkov
2021-06-23  6:41       ` Dmitry Kadashev
2021-06-23 11:53         ` Pavel Begunkov
2021-06-24 11:11           ` Dmitry Kadashev
2021-06-24 12:21             ` Pavel Begunkov
2021-06-28  8:17               ` Dmitry Kadashev
2021-07-07 14:06                 ` Pavel Begunkov
2021-07-12 12:44                   ` Dmitry Kadashev
2021-07-12 13:14                     ` Pavel Begunkov [this message]
2021-06-22 17:41   ` Pavel Begunkov
2021-06-23  0:41     ` Jens Axboe
2021-06-23  5:50     ` Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 03/10] fs: make do_mknodat() take struct filename Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 04/10] fs: make do_symlinkat() " Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 05/10] namei: add getname_uflags() Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 06/10] fs: make do_linkat() take struct filename Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 07/10] fs: update do_*() helpers to return ints Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 08/10] io_uring: add support for IORING_OP_SYMLINKAT Dmitry Kadashev
2021-06-22 11:36   ` Pavel Begunkov
2021-06-23  5:45     ` Dmitry Kadashev
2021-06-03  5:18 ` [PATCH v5 09/10] io_uring: add support for IORING_OP_LINKAT Dmitry Kadashev
2021-06-22 11:48   ` Pavel Begunkov
2021-06-23  6:09     ` Dmitry Kadashev
2021-06-23 13:13       ` Pavel Begunkov
2021-06-03  5:18 ` [PATCH v5 10/10] io_uring: add support for IORING_OP_MKNODAT Dmitry Kadashev
2021-06-22 11:52   ` Pavel Begunkov
2021-06-23  6:26     ` Dmitry Kadashev
2021-06-23 11:58       ` Pavel Begunkov
2021-06-24  2:36       ` Jens Axboe
2021-06-18  6:24 ` [PATCH v5 00/10] io_uring: add mkdir, [sym]linkat and mknodat support Dmitry Kadashev
2021-06-18 16:10   ` Jens Axboe
2021-06-21 15:21     ` Jens Axboe
2021-06-22  8:12       ` Christian Brauner
2021-06-22  8:34         ` Dmitry Kadashev
2021-06-29 13:06           ` Christian Brauner
2021-06-22 17:26         ` Jens Axboe
2021-06-22  8:26       ` Dmitry Kadashev
2021-06-21 15:57 ` Jens Axboe
2021-06-21 15:59   ` Jens Axboe
2021-06-22 11:56 ` Pavel Begunkov
2021-06-22 17:26   ` Jens Axboe
2021-06-22 17:28     ` Pavel Begunkov
2021-06-22 17:32       ` Jens Axboe
2021-06-23  5:37         ` Dmitry Kadashev
2021-06-23  5:49         ` Dmitry Kadashev
2021-06-24  2:37           ` Jens Axboe
2021-06-24 10:55             ` Dmitry Kadashev
2021-06-23  5:35   ` Dmitry Kadashev
2021-06-24  2:37     ` 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] \
    [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