Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <83183894-155a-efe7-ea0d-a3d88ebeadb1@kernel.dk>
Date:   Thu, 19 May 2022 13:55:26 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Subject: Re: [PATCHSET 0/2] Fix splice from random/urandom
Content-Language: en-US
To:     Christoph Hellwig <hch@lst.de>
Cc:     tytso@mit.edu, Jason@zx2c4.com, linux-kernel@vger.kernel.org
References: <20220519193133.194138-1-axboe@kernel.dk>
 <20220519194838.GA6361@lst.de>
From:   Jens Axboe <axboe@kernel.dk>
In-Reply-To: <20220519194838.GA6361@lst.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/19/22 1:48 PM, Christoph Hellwig wrote:
> On Thu, May 19, 2022 at 01:31:31PM -0600, Jens Axboe wrote:
>> Hi,
>>
>> We recently had a failure on a kernel upgrade because splice no longer
>> works on random/urandom. This is due to:
>>
>> 6e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
>>
>> which already has more than two handful of Fixes registered to its
>> name...
> 
> Yes.  It was a hard break to get rid of set_fs and it's abuse.

I'm a bit torn on this one, because I _really_ want us to get rid of
read/write and make everything use read_iter/write_iter. Firstly because
it's really stupid to have two interfaces, and secondly because even
basic things like "can we block here" doesn't work in the older
interface without fiddling with file flags which is a non-starter for
certain things.

However, it's also problematic that we end up breaking real applications
because of this change. Arguably we should've converted existing
read/write first and avoid this grey zone we are in now (best solution),
or provided splice read/write helpers that work with the non-iter based
read/write handlers.

-- 
Jens Axboe