linux-kernel - Re: (splice socket -> pipe) + EPOLLET -> epoll

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>] [day] [month] [year] [list]

Message-ID: <1318520635.2393.22.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date:	Thu, 13 Oct 2011 17:43:55 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Марк Коренберг 
	<socketpair@...il.com>
Cc:	netdev@...r.kernel.org, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: (splice socket -> pipe) + EPOLLET -> epoll_wait does not not
 wake up !

Le jeudi 13 octobre 2011 à 20:48 +0600, Марк Коренберг a écrit :
> The problem:
> 
> man 7 epoll said:
> For  stream-oriented  files  (e.g.,  pipe, FIFO, stream socket), the
> condition that the read/write I/O space is exhausted can also be
> detected by checking the amount of data read from / written to the
> target file descriptor.  For example, if you call read(2) by asking to
> read a certain amount of data and read(2) returns a lower number of
> bytes, you  can  be  sure of having exhausted the read I/O space for
> the file descriptor.
> 
> I decide to use splice socket -> pipe instead of recv. So I have
> registered socket's fd in epoll with EPOLLIN|EPOLLET.
> 
> When data appear in socket faster than I splice() it from socket, the
> following sometimes appear:
> 
> 1. in my code I sure, that pipe is empty.
> 2. my code do splice(socket, pipe, 65536)
> 3. splice return, say, 53248
> 4. my code accordingly to man, decide not to fire splice() again, as
> it thinks that it will return EWOULDBLOCK=EAGAIN.
> 5. so, my code go to epoll_wait to wait for EPOLLIN on socket
> 6. epoll hangs.
> 
> This is not appear if I do just recv(). But it may be because speed is
> lower, and some race condition in effect.
> 
> The hacked version of strace output is attached.

Your assumptions about splice() are false.

splice() can transfert partial pages.

So you can hit the 16 pages pipe limit, and splice() doesnt necessarly
returns 16*PAGE_SIZE.

With TCP frames, usually 1460 bytes per PAGE are used.

You must call splice() again and again, unless 0 bytes (EAGAIN) are
returned.



--
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/