Re: race in skb_splice_bits?
From: Octavian Purdila <hidden>
Date: 2008-05-27 12:54:59
On Tuesday 27 May 2008, Evgeniy Polyakov wrote:
quoted
quoted
However, from Octavian's later mail it seems we can't let the skb go away at all. So some wider changes seem to be required.Yes, I misread the original message. Octavian, could you please decode where bug occured via gdb: gdb $ l *(skb_splice_bits+0x130)It is lock_sock()?
Yes it is lock_sock(). The crash in lock_sock() occurs with the following
sequence:
release_sock(__skb->sk);
ret = splice_to_pipe(pipe, &spd);
lock_sock(__skb->sk);
0x8010c94c is in skb_splice_bits (include/net/sock.h:837).
832
833 extern void lock_sock_nested(struct sock *sk, int subclass);
834
835 static inline void lock_sock(struct sock *sk)
836 {
837 lock_sock_nested(sk, 0);
838 }
839
840 extern void release_sock(struct sock *sk);
841
And also please show what tcp_read_sock+0x108 tcp_read_sock+0x138 are.
This crash occurs with the following sequence:
struct sock *sk= __skb->sk;
release_sock(sk);
ret = splice_to_pipe(pipe, &spd);
lock_sock(sk);
0x8014d090 is in tcp_read_sock (net/ipv4/tcp.c:1225).
1220 used = recv_actor(desc, skb, offset, len);
1221 if (used < 0) {
1222 if (!copied)
1223 copied = used;
1224 break;
1225 } else if (used <= len) {
1226 seq += used;
1227 copied += used;
1228 offset += used;
1229 }
And do you have a test case for that?
Yes. I've attached my test program which triggers both crashes. To improve the reproducibility rate you need to use a relatively high buffer for splice (I used 16384) and a small MTU (I used 128). This will make the 1st splice on the receive side block (due to not enough PIPE_BUFFERS it seems), and will give plenty of time to the race condition to manifest itself. When you interrupt the program, the system will crash. Thanks, tavi