2022-05-21 11:12:39

by Jens Axboe

[permalink] [raw]
Subject: Re: [PATCH v4 0/3] random: convert to using iters, for Al Viro

On 5/20/22 9:47 AM, Al Viro wrote:
> On Fri, May 20, 2022 at 09:34:46AM -0600, Jens Axboe wrote:
>
>> I'm very sure, otherwise we're just accepting that we're breaking real
>> world applications.
>
> "Breaking" as in "it used to work with earlier kernels, doesn't work with
> recent ones"? Details, please...

Yes, as in exactly that. This is what drove this addition of
->read_iter() for urandom. See commit:

ommit 36e2c7421f02a22f71c9283e55fdb672a9eb58e7
Author: Christoph Hellwig <[email protected]>
Date: Thu Sep 3 16:22:34 2020 +0200

fs: don't allow splice read/write without explicit ops

related to the set_fs() changes, and now go look for any commit that
has:

Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")

in it and see that this isn't an isolated incident at all.

tldr - splice from /dev/urandom used to work, and I recently got a
report internally on an application that broke on upgrade from 5.6 to
5.12 exactly because it now just just -EINVAL's instead.

--
Jens Axboe



2022-05-21 17:52:17

by Al Viro

[permalink] [raw]
Subject: Re: [PATCH v4 0/3] random: convert to using iters, for Al Viro

On Fri, May 20, 2022 at 09:53:30AM -0600, Jens Axboe wrote:
> On 5/20/22 9:47 AM, Al Viro wrote:
> > On Fri, May 20, 2022 at 09:34:46AM -0600, Jens Axboe wrote:
> >
> >> I'm very sure, otherwise we're just accepting that we're breaking real
> >> world applications.
> >
> > "Breaking" as in "it used to work with earlier kernels, doesn't work with
> > recent ones"? Details, please...
>
> Yes, as in exactly that. This is what drove this addition of
> ->read_iter() for urandom. See commit:
>
> ommit 36e2c7421f02a22f71c9283e55fdb672a9eb58e7
> Author: Christoph Hellwig <[email protected]>
> Date: Thu Sep 3 16:22:34 2020 +0200
>
> fs: don't allow splice read/write without explicit ops
>
> related to the set_fs() changes, and now go look for any commit that
> has:
>
> Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
>
> in it and see that this isn't an isolated incident at all.
>
> tldr - splice from /dev/urandom used to work, and I recently got a
> report internally on an application that broke on upgrade from 5.6 to
> 5.12 exactly because it now just just -EINVAL's instead.

IIRC, Linus' position at the time had been along the lines of
"splice is not so good ABI anyway, so let's do it and fix up
the places that do get real-world complaints once such appear".
So /dev/urandom is one such place...