Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022/9/19 18:40, Jason A. Donenfeld wrote:
Hi,

On Mon, Sep 19, 2022 at 11:27 AM Guozihua (Scott) <guozihua@xxxxxxxxxx> wrote:

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.

Alright then. Sounds like a clear case of userspace being broken. I'll
include https://git.zx2c4.com/linux-rng/commit/?id=b931eaf6ef5cef474a1171542a872a5e270e3491
or similar in my pull for 6.1, if that's okay with you. For 6.0, we're
already at rc6, so maybe better to let this one stew for a bit longer,
given the change, unless you feel strongly about having it earlier, I
guess.

Jason
.

Hi Jason

That's OK with us. Thanks.

--
Best
GUO Zihua



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux