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
