linux-kernel - Re: Data corruption issue with splice() on 2.6.27.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]

Message-ID: <20090106185012.GA30322@1wt.eu>
Date:	Tue, 6 Jan 2009 19:50:12 +0100
From:	Willy Tarreau <w@....eu>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: Data corruption issue with splice() on 2.6.27.10

Hi Evgeniy,

On Tue, Jan 06, 2009 at 09:32:23PM +0300, Evgeniy Polyakov wrote:
> Hi Willy.
> 
> Unfortunately I can not work on this problem right now, but will do if
> things are not resolved after Jan 11 (long vacations will be finished in
> Russia and I will return to my test machines :) But right now I have
> one quesstion: I read several times your mail but still can not figure
> out if receiving or sending side is broken?
> 
> I.e. can you splice from socket into the file, check the file, and then
> splice to the another socket and check received data to find out which
> side is broken? Or did I just missed that in the problem description?

Maybe I wasn't very clear. It's only when splicing from a socket to another
socket that it breaks. Splicing from a file to a socket is OK (sendfile is
OK too BTW). Splicing from a socket to a file is OK.

And BTW, the receiving side must be on a real interface, not loopback. Here
are my observations :
  - splice data from lo to lo     => no corruption at all
  - splice data from lo to eth0   => no corruption at all
  - splice data from eth0 to lo   => occasional corruption
  - splice data from eth0 to eth0 => massive corruption

I think this may ring a bell for someone.

> Thanks a lot for the test application, it will greatly help to resolve
> this issue.

I figured it was an absolute necessity. The original code in my proxy is in
an experimental state and far too hard to debug for these purposes. It was
enough to detect the problem, but I could run a lot more tests with this
small test app ! An who know, maybe it will serve as an example for
non-blocking splice ;-)

Cheers,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/