linux-kernel - Re: Change in splice() behaviour after 5.10?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 4 Jun 2024 06:50:30 +0200
From: Christoph Hellwig <hch@....de>
To: Terry Tritton <terry.tritton@...aro.org>
Cc: hch@....de, "ttritton@...gle.com" <ttritton@...gle.com>,
	edliaw@...gle.com, keescook@...omium.org,
	linux-kernel@...r.kernel.org
Subject: Re: Change in splice() behaviour after 5.10?

On Mon, Jun 03, 2024 at 10:59:15AM +0100, Terry Tritton wrote:
> Hi,
> We've found a change in behaviour while testing the splice07 LTP test.
> In versions before 5.10 the test will hang on certain combinations but after
> 5.10 the splice call will return.
> I bisected the change to the following commit:
>     36e2c7421f02a22f71c9283e55fdb672a9eb58e7
>     fs: don't allow splice read/write without explicit ops
> 
> There has been some discussion on the LTP github page already:
>     https://github.com/linux-test-project/ltp/issues/1156

In that case the return probably is an error because epoll doesn't
support read_iter/write_iter and thus completely expected.

If the underlying bug hasn't been fix in the mean time that probably
means it will be back if Jens' conversion of all misc file operations
to the iter based ones every gets merged.

If you are interested more in this please discuss it on the relevant
mailing lists instead of in private mail.