From: Eric Dumazet <hidden> Date: 2012-05-25 20:45:31
On Fri, 2012-05-25 at 21:25 +0100, Jack Stone wrote:
Hi All,
The following warning keeps hitting me. I couldn't get the first one - it had already left dmesg hence the W taint.
The C taint is from r8712u from staging.
I've seen it with 3.4.0-076444-g07acfc2 (recent Linus tree) and 3.4.0-rc3-00089-gc6f5c93.
I am going to attempt to bisect it now.
From: Eric Dumazet <hidden> Date: 2012-05-25 20:55:39
On Fri, 2012-05-25 at 22:45 +0200, Eric Dumazet wrote:
On Fri, 2012-05-25 at 21:25 +0100, Jack Stone wrote:
quoted
Hi All,
The following warning keeps hitting me. I couldn't get the first one - it had already left dmesg hence the W taint.
The C taint is from r8712u from staging.
I've seen it with 3.4.0-076444-g07acfc2 (recent Linus tree) and 3.4.0-rc3-00089-gc6f5c93.
I am going to attempt to bisect it now.
From: Jack Stone <hidden> Date: 2012-05-26 11:22:34
On 05/25/2012 09:55 PM, Eric Dumazet wrote:
On Fri, 2012-05-25 at 22:45 +0200, Eric Dumazet wrote:
quoted
On Fri, 2012-05-25 at 21:25 +0100, Jack Stone wrote:
quoted
Hi All,
The following warning keeps hitting me. I couldn't get the first one - it had already left dmesg hence the W taint.
The C taint is from r8712u from staging.
I've seen it with 3.4.0-076444-g07acfc2 (recent Linus tree) and 3.4.0-rc3-00089-gc6f5c93.
I am going to attempt to bisect it now.
I'm still getting this with da89fb1 which includes the above
Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
From: Eric Dumazet <hidden> Date: 2012-05-27 13:59:51
On Sat, 2012-05-26 at 12:22 +0100, Jack Stone wrote:
I'm still getting this with da89fb1 which includes the above
Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
From: Jack Stone <hidden> Date: 2012-05-27 15:35:05
On 05/27/2012 02:59 PM, Eric Dumazet wrote:
quoted hunk
On Sat, 2012-05-26 at 12:22 +0100, Jack Stone wrote:
quoted
I'm still getting this with da89fb1 which includes the above
Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
From: Eric Dumazet <hidden> Date: 2012-05-27 17:36:08
On Sun, 2012-05-27 at 16:34 +0100, Jack Stone wrote:
On 05/27/2012 02:59 PM, Eric Dumazet wrote:
quoted
On Sat, 2012-05-26 at 12:22 +0100, Jack Stone wrote:
quoted
I'm still getting this with da89fb1 which includes the above
Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
@@ -1606,8 +1606,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,if(tcp_hdr(skb)->fin)gotofound_fin_ok;WARN(!(flags&MSG_PEEK),-"recvmsg bug 2: copied %X seq %X rcvnxt %X fl %X\n",-*seq,TCP_SKB_CB(skb)->seq,tp->rcv_nxt,flags);+"recvmsg bug 2: copied %X seq %X end_seq %X rcvnxt %X fl %X offset %u len %u syn %d\n",+*seq,TCP_SKB_CB(skb)->seq,TCP_SKB_CB(skb)->end_seq,+tp->rcv_nxt,flags,offset,skb->len,tcp_hdr(skb)->syn);}/* Well, if we have backlog, try to process it now yet. */
uname: Linux hover1 3.4.0-07822-g786f02b-dirty #1 SMP Sun May 27 15:23:39 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
Here's the new output:
May 27 16:32:30 hover1 kernel: [ 1907.804613] ------------[ cut here ]------------
May 27 16:32:30 hover1 kernel: [ 1907.804622] WARNING: at net/ipv4/tcp.c:1611 tcp_recvmsg+0xb36/0xc90()
May 27 16:32:30 hover1 kernel: [ 1907.804624] Hardware name: System Product Name
May 27 16:32:30 hover1 kernel: [ 1907.804626] recvmsg bug 2: copied 8F322DEB seq 8F322DEB end_seq 8F322F2A rcvnxt 8F322F2A fl 0 offset 4294967295 len 319 syn 1
So it seems we can queue in sk_receive_queue a packet with SYN flag set.
(A SYN or SYNACK packet contains DATA payload...)
The sequence number of such frames should be tweaked (seq++) instead of
games we do in fast path :
if (tcp_hdr(skb)->syn)
offset--;
Oh well this can wait linux-3.6, please test following patch in the
meantime.
@@ -4553,7 +4553,7 @@ static bool tcp_try_coalesce(struct sock *sk,*fragstolen=false;-if(tcp_hdr(from)->fin)+if(tcp_hdr(from)->fin||tcp_hdr(to)->syn)returnfalse;/* Its possible this segment overlaps with prior segment in queue */
From: Jack Stone <hidden> Date: 2012-05-27 19:13:47
On 05/27/2012 06:35 PM, Eric Dumazet wrote:
quoted hunk
So it seems we can queue in sk_receive_queue a packet with SYN flag set.
(A SYN or SYNACK packet contains DATA payload...)
The sequence number of such frames should be tweaked (seq++) instead of
games we do in fast path :
if (tcp_hdr(skb)->syn)
offset--;
Oh well this can wait linux-3.6, please test following patch in the
meantime.
@@ -4553,7 +4553,7 @@ static bool tcp_try_coalesce(struct sock *sk,*fragstolen=false;-if(tcp_hdr(from)->fin)+if(tcp_hdr(from)->fin||tcp_hdr(to)->syn)returnfalse;/* Its possible this segment overlaps with prior segment in queue */
From: Eric Dumazet <hidden> Date: 2012-05-27 19:36:20
On Sun, 2012-05-27 at 20:13 +0100, Jack Stone wrote:
On 05/27/2012 06:35 PM, Eric Dumazet wrote:
quoted
So it seems we can queue in sk_receive_queue a packet with SYN flag set.
(A SYN or SYNACK packet contains DATA payload...)
The sequence number of such frames should be tweaked (seq++) instead of
games we do in fast path :
if (tcp_hdr(skb)->syn)
offset--;
Oh well this can wait linux-3.6, please test following patch in the
meantime.
@@ -4553,7 +4553,7 @@ static bool tcp_try_coalesce(struct sock *sk,*fragstolen=false;-if(tcp_hdr(from)->fin)+if(tcp_hdr(from)->fin||tcp_hdr(to)->syn)returnfalse;/* Its possible this segment overlaps with prior segment in queue */
Still seems to fire with the above applied, it also sets of the warn just above it...
Could it be something to do with my staging network driver?
Yes it could be memory corruption.
(making tcp _think_ tcp_hdr(skb)->syn is set, while it was not at all.
Please replace debugging patch by following, because tcp flags are
copied elsewhere, so we can double check.
From: Eric Dumazet <hidden> Date: 2012-05-28 00:25:36
On Sun, 2012-05-27 at 20:13 +0100, Jack Stone wrote:
Could it be something to do with my staging network driver?
drivers/staging/rtl8712/rtl8712_recv.c
line 1096
precvframe->u.hdr.pkt = skb_clone(pskb, GFP_ATOMIC);
This looks very wrong.
Make sure you never _never_ hit this path.
From: Jack Stone <hidden> Date: 2012-05-28 08:34:10
On 05/28/2012 01:25 AM, Eric Dumazet wrote:
On Sun, 2012-05-27 at 20:13 +0100, Jack Stone wrote:
quoted
Could it be something to do with my staging network driver?
drivers/staging/rtl8712/rtl8712_recv.c
line 1096
precvframe->u.hdr.pkt = skb_clone(pskb, GFP_ATOMIC);
This looks very wrong.
Make sure you never _never_ hit this path.
I've applied the following debugging patch. Thanks for the suggestion.
@@ -1082,23 +1082,16 @@ static int recvbuf2recvframe(struct _adapter *padapter, struct sk_buff *pskb)*4isforskb->data4bytesalignment.*/alloc_sz+=6;pkt_copy=netdev_alloc_skb(padapter->pnetdev,alloc_sz);-if(pkt_copy){-pkt_copy->dev=padapter->pnetdev;-precvframe->u.hdr.pkt=pkt_copy;-skb_reserve(pkt_copy,4-((addr_t)(pkt_copy->data)-%4));-skb_reserve(pkt_copy,shift_sz);-memcpy(pkt_copy->data,pbuf,tmp_len);-precvframe->u.hdr.rx_head=precvframe->u.hdr.rx_data=-precvframe->u.hdr.rx_tail=pkt_copy->data;-precvframe->u.hdr.rx_end=pkt_copy->data+alloc_sz;-}else{-precvframe->u.hdr.pkt=skb_clone(pskb,GFP_ATOMIC);-precvframe->u.hdr.rx_head=pbuf;-precvframe->u.hdr.rx_data=pbuf;-precvframe->u.hdr.rx_tail=pbuf;-precvframe->u.hdr.rx_end=pbuf+alloc_sz;-}+WARN_ON(!pkt_copy)+pkt_copy->dev=padapter->pnetdev;+precvframe->u.hdr.pkt=pkt_copy;+skb_reserve(pkt_copy,4-((addr_t)(pkt_copy->data)+%4));+skb_reserve(pkt_copy,shift_sz);+memcpy(pkt_copy->data,pbuf,tmp_len);+precvframe->u.hdr.rx_head=precvframe->u.hdr.rx_data=+precvframe->u.hdr.rx_tail=pkt_copy->data;+precvframe->u.hdr.rx_end=pkt_copy->data+alloc_sz;recvframe_put(precvframe,tmp_len);recvframe_pull(precvframe,drvinfo_sz+RXDESC_SIZE);/* because the endian issue, driver avoid reference to the