public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: "Guozihua (Scott)" <guozihua@huawei.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Andrew Lutomirski <luto@kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	zhongguohua <zhongguohua1@huawei.com>
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random
Date: Mon, 19 Sep 2022 18:27:09 +0800	[thread overview]
Message-ID: <ca31cb51-30b8-e970-c33c-7b848ae5ed45@huawei.com> (raw)
In-Reply-To: <Yxm7OKZxT7tXsTgx@zx2c4.com>

On 2022/9/8 17:51, Jason A. Donenfeld wrote:
> Hi,
> 
> On Thu, Sep 08, 2022 at 11:31:31AM +0800, Guozihua (Scott) wrote:
>> For example:
>>
>>
>> -- 
>> Best
>> GUO Zihua
>>
>> -- 
>> Best
>> GUO Zihua
> 
> Looks like you forgot to paste the example...
> 
>> Thank you for the timely respond and your patient. And sorry for the
>> confusion.
>>
>> First of all, what we think is that this change (removing O_NONBLOCK) is
>> reasonable. However, this do cause issue during the test on one of our
>> product which uses O_NONBLOCK flag the way I presented earlier in the
>> Linux 4.4 era. Thus our colleague suggests that returning -EINVAL when
>> this flag is received would be a good way to indicate this change.
> 
> No, I don't think it's wise to introduce yet *new* behavior (your
> proposed -EINVAL). That would just exacerbate the (mostly) invisible
> breakage from the 5.6-era change.
> 
> The question now before us is whether to bring back the behavior that
> was there pre-5.6, or to keep the behavior that has existed since 5.6.
> Accidental regressions like this (I assume it was accidental, at least)
> that are unnoticed for so long tend to ossify and become the new
> expected behavior. It's been around 2.5 years since 5.6, and this is the
> first report of breakage. But the fact that it does break things for you
> *is* still significant.
> 
> If this was just something you noticed during idle curiosity but doesn't
> have a real impact on anything, then I'm inclined to think we shouldn't
> go changing the behavior /again/ after 2.5 years. But it sounds like
> actually you have a real user space in a product that stopped working
> when you tried to upgrade the kernel from 4.4 to one >5.6. If this is
> the case, then this sounds truly like a userspace-breaking regression,
> which we should fix by restoring the old behavior. Can you confirm this
> is the case? And in the meantime, I'll prepare a patch for restoring
> that old behavior.
> 
> Jason
> .

Hi Jason

Thank for your patience.

To answer your question, yes, we do have a userspace program reading 
/dev/random during early boot which relies on O_NONBLOCK. And this 
change do breaks it. The userspace program comes from 4.4 era, and as 
4.4 is going EOL, we are switching to 5.10 and the breakage is reported.

It would be great if the kernel is able to restore this flag for 
backward compatibility.

-- 
Best
GUO Zihua

  parent reply	other threads:[~2022-09-19 10:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  7:33 Inquiry about the removal of flag O_NONBLOCK on /dev/random Guozihua (Scott)
2022-07-18  8:52 ` Guozihua (Scott)
2022-07-19  3:47   ` Eric Biggers
2022-07-19  8:06     ` Guozihua (Scott)
2022-07-19 11:01 ` Jason A. Donenfeld
2022-07-21  3:50   ` Guozihua (Scott)
2022-07-21  4:07     ` Eric Biggers
2022-07-21  6:44       ` Guozihua (Scott)
2022-07-21  6:50         ` Eric Biggers
2022-07-21 10:37           ` Jason A. Donenfeld
2022-07-21 11:30             ` Guozihua (Scott)
2022-07-26  7:43             ` Guozihua (Scott)
2022-07-26 11:08               ` Jason A. Donenfeld
2022-07-26 11:33                 ` Guozihua (Scott)
2022-07-28  8:24                   ` Guozihua (Scott)
2022-09-06  7:14                     ` Guozihua (Scott)
2022-09-06 10:16                     ` Jason A. Donenfeld
2022-09-07 13:03                       ` Jason A. Donenfeld
2022-09-08  3:31                         ` Guozihua (Scott)
2022-09-08  9:51                           ` Jason A. Donenfeld
2022-09-08 10:40                             ` Jason A. Donenfeld
2022-09-08 14:26                               ` [PATCH] random: restore O_NONBLOCK support Jason A. Donenfeld
2022-09-19 10:27                             ` Guozihua (Scott) [this message]
2022-09-19 10:40                               ` Inquiry about the removal of flag O_NONBLOCK on /dev/random Jason A. Donenfeld
2022-09-19 10:45                                 ` Guozihua (Scott)
2022-07-21 11:09         ` Theodore Ts'o
2022-07-21 11:30           ` Guozihua (Scott)

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 \
    --in-reply-to=ca31cb51-30b8-e970-c33c-7b848ae5ed45@huawei.com \
    --to=guozihua@huawei.com \
    --cc=Jason@zx2c4.com \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=tytso@mit.edu \
    --cc=zhongguohua1@huawei.com \
    /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