Evgeniy Polyakov a écrit :

quoted text
> Hi Eric.

>

> On Sat, Jan 10, 2009 at 08:40:05AM +0100, Eric Dumazet (dada1@cosmosbay.com) wrote:

>>> Not to interrupt the discussion, but for the clarification, that

>>> release_sock/lock_sock is used to process the backlog accumulated while

>>> socket was locked. And while dropping additional pair before the final

>>> release is ok, but moving this itself should be thought of twice.

>>>

>> Hum... I just caught the release_sock(sk)/lock_sock(sk) done in skb_splice_bits()

>>

>> So :

>>

>> 1) the release_sock/lock_sock done in tcp_splice_read() is not necessary

>> to process backlog. Its already done in skb_splice_bits()

>

> Yes, in the tcp_splice_read() they are added to remove a deadlock.

Could you elaborate ? A deadlock only if !SPLICE_F_NONBLOCK ?
>

quoted text
>> 2) If we loop in tcp_read_sock() calling skb_splice_bits() several times

>> then we should perform the following tests inside this loop ?

>>

>> if (sk->sk_err || sk->sk_state == TCP_CLOSE || (sk->sk_shutdown & RCV_SHUTDOWN) ||

>>    signal_pending(current)) break;

>>

>> And removie them from tcp_splice_read() ?

>

> It could be done, but for what reason? To detect disconnected socket early?

> Does it worth the changes?

> 

I was thinking about the case your thread is doing a splice() from tcp socket to

 a pipe, while another thread is doing the splice from this pipe to something else.
Once patched, tcp_read_sock() could loop a long time...
--

To unsubscribe from this list: send the line "unsubscribe netdev" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html