diff for duplicates of <1213759663.25608.33.camel@ymzhang> diff --git a/a/1.txt b/N1/1.txt index c426ce4..5e48c7e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -32,30 +32,30 @@ On Fri, 2008-06-13 at 16:19 +0800, Zhang, Yanmin wrote: > > Call Trace: > [<a000000100014de0>] show_stack+0x40/0xa0 -> spà000003d45379c0 bspà000003d4531440 +> sp=e0000003d45379c0 bsp=e0000003d4531440 > [<a0000001000156f0>] show_regs+0x850/0x8a0 -> spà000003d4537b90 bspà000003d45313e0 +> sp=e0000003d4537b90 bsp=e0000003d45313e0 > [<a000000100038d10>] die+0x230/0x360 -> spà000003d4537b90 bspà000003d4531398 +> sp=e0000003d4537b90 bsp=e0000003d4531398 > [<a00000010005cec0>] ia64_do_page_fault+0x8e0/0xa40 -> spà000003d4537b90 bspà000003d4531348 +> sp=e0000003d4537b90 bsp=e0000003d4531348 > [<a00000010000b120>] ia64_leave_kernel+0x0/0x280 -> spà000003d4537c20 bspà000003d4531348 +> sp=e0000003d4537c20 bsp=e0000003d4531348 > [<a00000010087a4b0>] tcp_rcv_established+0x1450/0x16e0 -> spà000003d4537df0 bspà000003d45312d8 +> sp=e0000003d4537df0 bsp=e0000003d45312d8 > [<a000000100888370>] tcp_v4_do_rcv+0x70/0x500 -> spà000003d4537df0 bspà000003d4531298 +> sp=e0000003d4537df0 bsp=e0000003d4531298 > [<a00000010088cd30>] tcp_v4_rcv+0xfb0/0x1060 -> spà000003d4537e00 bspà000003d4531248 +> sp=e0000003d4537e00 bsp=e0000003d4531248 > > > > As a matter of fact, kernel paniced at statement -> "queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add, because -> queue->rskq_accept_tail is NULL. The call chain is: -> tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add. +> "queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add, because +> queue->rskq_accept_tail is NULL. The call chain is: +> tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add. The call chain is: -tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add +tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add > > As I was running an initial specweb2005(configured 3500 sessions) testing between @@ -68,16 +68,16 @@ The call chain is: This issue is caused by tcp defer accept. Mostly, process context calls lock_sock to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply for the sk->sk_lock.slock without sleeping, then do appropriate processing based on -if sk->sk_lock.owned=0. That works well if both process context and BH context operate -the same sk at the same time. But with tcp defer accept, it doesn't, because +if sk->sk_lock.owned==0. That works well if both process context and BH context operate +the same sk at the same time. But with tcp defer accept, it doesn't, because process context(for example, in inet_csk_accept) locks the listen sk, while BH context (in tcp_v4_rcv, for example) locks the child sk and calls -tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race +tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race to access the listen sock. Below patch against 2.6.26-rc6 fixes the issue. -Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> +Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> --- @@ -113,7 +113,7 @@ Below patch against 2.6.26-rc6 fixes the issue. + bh_lock_sock_nested(tp->defer_tcp_accept.listen_sk); + if (queued_data && - tp->defer_tcp_accept.listen_sk->sk_state = TCP_LISTEN) { + tp->defer_tcp_accept.listen_sk->sk_state == TCP_LISTEN) { if (sock_flag(sk, SOCK_KEEPOPEN)) { @@ -4568,6 +4570,8 @@ static int tcp_defer_accept_check(struct tp->defer_tcp_accept.request, diff --git a/a/content_digest b/N1/content_digest index 766e281..1b43909 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,7 +1,7 @@ "ref\01213345160.25608.3.camel@ymzhang\0" "From\0Zhang, Yanmin <yanmin_zhang@linux.intel.com>\0" - "Subject\0Re: IPF Montvale machine panic when running a network-relevent\0" - "Date\0Wed, 18 Jun 2008 03:27:43 +0000\0" + "Subject\0Re: IPF Montvale machine panic when running a network-relevent testing\0" + "Date\0Wed, 18 Jun 2008 11:27:43 +0800\0" "To\0netdev@vger.kernel.org" " David Miller <davem@davemloft.net>\0" "Cc\0LKML <linux-kernel@vger.kernel.org>" @@ -42,30 +42,30 @@ "> \n" "> Call Trace:\n" "> [<a000000100014de0>] show_stack+0x40/0xa0\n" - "> sp\303\240000003d45379c0 bsp\303\240000003d4531440\n" + "> sp=e0000003d45379c0 bsp=e0000003d4531440\n" "> [<a0000001000156f0>] show_regs+0x850/0x8a0\n" - "> sp\303\240000003d4537b90 bsp\303\240000003d45313e0\n" + "> sp=e0000003d4537b90 bsp=e0000003d45313e0\n" "> [<a000000100038d10>] die+0x230/0x360\n" - "> sp\303\240000003d4537b90 bsp\303\240000003d4531398\n" + "> sp=e0000003d4537b90 bsp=e0000003d4531398\n" "> [<a00000010005cec0>] ia64_do_page_fault+0x8e0/0xa40\n" - "> sp\303\240000003d4537b90 bsp\303\240000003d4531348\n" + "> sp=e0000003d4537b90 bsp=e0000003d4531348\n" "> [<a00000010000b120>] ia64_leave_kernel+0x0/0x280\n" - "> sp\303\240000003d4537c20 bsp\303\240000003d4531348\n" + "> sp=e0000003d4537c20 bsp=e0000003d4531348\n" "> [<a00000010087a4b0>] tcp_rcv_established+0x1450/0x16e0\n" - "> sp\303\240000003d4537df0 bsp\303\240000003d45312d8\n" + "> sp=e0000003d4537df0 bsp=e0000003d45312d8\n" "> [<a000000100888370>] tcp_v4_do_rcv+0x70/0x500\n" - "> sp\303\240000003d4537df0 bsp\303\240000003d4531298\n" + "> sp=e0000003d4537df0 bsp=e0000003d4531298\n" "> [<a00000010088cd30>] tcp_v4_rcv+0xfb0/0x1060\n" - "> sp\303\240000003d4537e00 bsp\303\240000003d4531248\n" + "> sp=e0000003d4537e00 bsp=e0000003d4531248\n" "> \n" "> \n" "> \n" "> As a matter of fact, kernel paniced at statement\n" - "> \"queue->rskq_accept_tail->dl_next = req\" in function \303\257\302\273\302\277reqsk_queue_add, because\n" - "> \303\257\302\273\302\277queue->rskq_accept_tail is NULL. The call chain is:\n" - "> \303\257\302\273\302\277\303\257\302\273\302\277tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add.\n" + "> \"queue->rskq_accept_tail->dl_next = req\" in function \357\273\277reqsk_queue_add, because\n" + "> \357\273\277queue->rskq_accept_tail is NULL. The call chain is:\n" + "> \357\273\277\357\273\277tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add.\n" "The call chain is:\n" - "\303\257\302\273\302\277tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add\n" + "\357\273\277tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add\n" "\n" "> \n" "> As I was running an initial specweb2005(configured 3500 sessions) testing between\n" @@ -78,16 +78,16 @@ "This issue is caused by tcp defer accept. Mostly, process context calls lock_sock\n" "to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply\n" "for the sk->sk_lock.slock without sleeping, then do appropriate processing based on\n" - "if sk->sk_lock.owned=0. That works well if both process context and BH context operate\n" - "the same sk at the same time. But with \303\257\302\273\302\277tcp defer accept, it doesn't, because\n" + "if sk->sk_lock.owned==0. That works well if both process context and BH context operate\n" + "the same sk at the same time. But with \357\273\277tcp defer accept, it doesn't, because\n" "process context(for example, in inet_csk_accept) locks the listen sk, while BH\n" "context (in tcp_v4_rcv, for example) locks the child sk and calls\n" - "\303\257\302\273\302\277tcp_defer_accept_check\303\257\302\273\302\277 => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race\n" + "\357\273\277tcp_defer_accept_check\357\273\277 => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race\n" "to access the listen sock.\n" "\n" "Below patch against 2.6.26-rc6 fixes the issue.\n" "\n" - "\303\257\302\273\302\277\303\257\302\273\302\277Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>\n" + "\357\273\277\357\273\277Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>\n" "\n" "---\n" "\n" @@ -123,7 +123,7 @@ "+\t\tbh_lock_sock_nested(tp->defer_tcp_accept.listen_sk);\n" "+\n" " \t\tif (queued_data &&\n" - " \t\t tp->defer_tcp_accept.listen_sk->sk_state = TCP_LISTEN) {\n" + " \t\t tp->defer_tcp_accept.listen_sk->sk_state == TCP_LISTEN) {\n" " \t\t\tif (sock_flag(sk, SOCK_KEEPOPEN)) {\n" "@@ -4568,6 +4570,8 @@ static int tcp_defer_accept_check(struct\n" " \t\t\t\ttp->defer_tcp_accept.request,\n" @@ -156,4 +156,4 @@ " #define bh_lock_sock(__sk)\tspin_lock(&((__sk)->sk_lock.slock))\n" " #define bh_lock_sock_nested(__sk) \\" -12a123be78621dbcc2c9b915e57c5cf3a922af441e10ed27f3ce24b606ee22a6 +12866107941c1589acdcc5de7c4afe81df4e1e3f5663e58ef4197ea3be1e616b
diff --git a/a/1.txt b/N2/1.txt index c426ce4..04b4019 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -32,30 +32,30 @@ On Fri, 2008-06-13 at 16:19 +0800, Zhang, Yanmin wrote: > > Call Trace: > [<a000000100014de0>] show_stack+0x40/0xa0 -> spà000003d45379c0 bspà000003d4531440 +> sp=e0000003d45379c0 bsp=e0000003d4531440 > [<a0000001000156f0>] show_regs+0x850/0x8a0 -> spà000003d4537b90 bspà000003d45313e0 +> sp=e0000003d4537b90 bsp=e0000003d45313e0 > [<a000000100038d10>] die+0x230/0x360 -> spà000003d4537b90 bspà000003d4531398 +> sp=e0000003d4537b90 bsp=e0000003d4531398 > [<a00000010005cec0>] ia64_do_page_fault+0x8e0/0xa40 -> spà000003d4537b90 bspà000003d4531348 +> sp=e0000003d4537b90 bsp=e0000003d4531348 > [<a00000010000b120>] ia64_leave_kernel+0x0/0x280 -> spà000003d4537c20 bspà000003d4531348 +> sp=e0000003d4537c20 bsp=e0000003d4531348 > [<a00000010087a4b0>] tcp_rcv_established+0x1450/0x16e0 -> spà000003d4537df0 bspà000003d45312d8 +> sp=e0000003d4537df0 bsp=e0000003d45312d8 > [<a000000100888370>] tcp_v4_do_rcv+0x70/0x500 -> spà000003d4537df0 bspà000003d4531298 +> sp=e0000003d4537df0 bsp=e0000003d4531298 > [<a00000010088cd30>] tcp_v4_rcv+0xfb0/0x1060 -> spà000003d4537e00 bspà000003d4531248 +> sp=e0000003d4537e00 bsp=e0000003d4531248 > > > > As a matter of fact, kernel paniced at statement -> "queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add, because -> queue->rskq_accept_tail is NULL. The call chain is: -> tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add. +> "queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add, because +> queue->rskq_accept_tail is NULL. The call chain is: +> tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add. The call chain is: -tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add +tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add > > As I was running an initial specweb2005(configured 3500 sessions) testing between @@ -68,16 +68,16 @@ The call chain is: This issue is caused by tcp defer accept. Mostly, process context calls lock_sock to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply for the sk->sk_lock.slock without sleeping, then do appropriate processing based on -if sk->sk_lock.owned=0. That works well if both process context and BH context operate -the same sk at the same time. But with tcp defer accept, it doesn't, because +if sk->sk_lock.owned==0. That works well if both process context and BH context operate +the same sk at the same time. But with tcp defer accept, it doesn't, because process context(for example, in inet_csk_accept) locks the listen sk, while BH context (in tcp_v4_rcv, for example) locks the child sk and calls -tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race +tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race to access the listen sock. Below patch against 2.6.26-rc6 fixes the issue. -Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> +Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> --- @@ -113,7 +113,7 @@ Below patch against 2.6.26-rc6 fixes the issue. + bh_lock_sock_nested(tp->defer_tcp_accept.listen_sk); + if (queued_data && - tp->defer_tcp_accept.listen_sk->sk_state = TCP_LISTEN) { + tp->defer_tcp_accept.listen_sk->sk_state == TCP_LISTEN) { if (sock_flag(sk, SOCK_KEEPOPEN)) { @@ -4568,6 +4570,8 @@ static int tcp_defer_accept_check(struct tp->defer_tcp_accept.request, @@ -145,3 +145,9 @@ Below patch against 2.6.26-rc6 fixes the issue. /* BH context may only use the following locking interface. */ #define bh_lock_sock(__sk) spin_lock(&((__sk)->sk_lock.slock)) #define bh_lock_sock_nested(__sk) \ + + +-- +To unsubscribe from this list: send the line "unsubscribe linux-ia64" in +the body of a message to majordomo@vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index 766e281..9674a63 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\01213345160.25608.3.camel@ymzhang\0" "From\0Zhang, Yanmin <yanmin_zhang@linux.intel.com>\0" - "Subject\0Re: IPF Montvale machine panic when running a network-relevent\0" - "Date\0Wed, 18 Jun 2008 03:27:43 +0000\0" + "Subject\0Re: IPF Montvale machine panic when running a network-relevent testing\0" + "Date\0Wed, 18 Jun 2008 11:27:43 +0800\0" "To\0netdev@vger.kernel.org" " David Miller <davem@davemloft.net>\0" "Cc\0LKML <linux-kernel@vger.kernel.org>" @@ -42,30 +42,30 @@ "> \n" "> Call Trace:\n" "> [<a000000100014de0>] show_stack+0x40/0xa0\n" - "> sp\303\240000003d45379c0 bsp\303\240000003d4531440\n" + "> sp=e0000003d45379c0 bsp=e0000003d4531440\n" "> [<a0000001000156f0>] show_regs+0x850/0x8a0\n" - "> sp\303\240000003d4537b90 bsp\303\240000003d45313e0\n" + "> sp=e0000003d4537b90 bsp=e0000003d45313e0\n" "> [<a000000100038d10>] die+0x230/0x360\n" - "> sp\303\240000003d4537b90 bsp\303\240000003d4531398\n" + "> sp=e0000003d4537b90 bsp=e0000003d4531398\n" "> [<a00000010005cec0>] ia64_do_page_fault+0x8e0/0xa40\n" - "> sp\303\240000003d4537b90 bsp\303\240000003d4531348\n" + "> sp=e0000003d4537b90 bsp=e0000003d4531348\n" "> [<a00000010000b120>] ia64_leave_kernel+0x0/0x280\n" - "> sp\303\240000003d4537c20 bsp\303\240000003d4531348\n" + "> sp=e0000003d4537c20 bsp=e0000003d4531348\n" "> [<a00000010087a4b0>] tcp_rcv_established+0x1450/0x16e0\n" - "> sp\303\240000003d4537df0 bsp\303\240000003d45312d8\n" + "> sp=e0000003d4537df0 bsp=e0000003d45312d8\n" "> [<a000000100888370>] tcp_v4_do_rcv+0x70/0x500\n" - "> sp\303\240000003d4537df0 bsp\303\240000003d4531298\n" + "> sp=e0000003d4537df0 bsp=e0000003d4531298\n" "> [<a00000010088cd30>] tcp_v4_rcv+0xfb0/0x1060\n" - "> sp\303\240000003d4537e00 bsp\303\240000003d4531248\n" + "> sp=e0000003d4537e00 bsp=e0000003d4531248\n" "> \n" "> \n" "> \n" "> As a matter of fact, kernel paniced at statement\n" - "> \"queue->rskq_accept_tail->dl_next = req\" in function \303\257\302\273\302\277reqsk_queue_add, because\n" - "> \303\257\302\273\302\277queue->rskq_accept_tail is NULL. The call chain is:\n" - "> \303\257\302\273\302\277\303\257\302\273\302\277tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add.\n" + "> \"queue->rskq_accept_tail->dl_next = req\" in function \357\273\277reqsk_queue_add, because\n" + "> \357\273\277queue->rskq_accept_tail is NULL. The call chain is:\n" + "> \357\273\277\357\273\277tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add.\n" "The call chain is:\n" - "\303\257\302\273\302\277tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add\n" + "\357\273\277tcp_rcv_established => tcp_defer_accept_check => inet_csk_reqsk_queue_add => reqsk_queue_add\n" "\n" "> \n" "> As I was running an initial specweb2005(configured 3500 sessions) testing between\n" @@ -78,16 +78,16 @@ "This issue is caused by tcp defer accept. Mostly, process context calls lock_sock\n" "to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply\n" "for the sk->sk_lock.slock without sleeping, then do appropriate processing based on\n" - "if sk->sk_lock.owned=0. That works well if both process context and BH context operate\n" - "the same sk at the same time. But with \303\257\302\273\302\277tcp defer accept, it doesn't, because\n" + "if sk->sk_lock.owned==0. That works well if both process context and BH context operate\n" + "the same sk at the same time. But with \357\273\277tcp defer accept, it doesn't, because\n" "process context(for example, in inet_csk_accept) locks the listen sk, while BH\n" "context (in tcp_v4_rcv, for example) locks the child sk and calls\n" - "\303\257\302\273\302\277tcp_defer_accept_check\303\257\302\273\302\277 => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race\n" + "\357\273\277tcp_defer_accept_check\357\273\277 => inet_csk_reqsk_queue_add => reqsk_queue_add, so there is a race\n" "to access the listen sock.\n" "\n" "Below patch against 2.6.26-rc6 fixes the issue.\n" "\n" - "\303\257\302\273\302\277\303\257\302\273\302\277Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>\n" + "\357\273\277\357\273\277Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>\n" "\n" "---\n" "\n" @@ -123,7 +123,7 @@ "+\t\tbh_lock_sock_nested(tp->defer_tcp_accept.listen_sk);\n" "+\n" " \t\tif (queued_data &&\n" - " \t\t tp->defer_tcp_accept.listen_sk->sk_state = TCP_LISTEN) {\n" + " \t\t tp->defer_tcp_accept.listen_sk->sk_state == TCP_LISTEN) {\n" " \t\t\tif (sock_flag(sk, SOCK_KEEPOPEN)) {\n" "@@ -4568,6 +4570,8 @@ static int tcp_defer_accept_check(struct\n" " \t\t\t\ttp->defer_tcp_accept.request,\n" @@ -154,6 +154,12 @@ "+\n" " /* BH context may only use the following locking interface. */\n" " #define bh_lock_sock(__sk)\tspin_lock(&((__sk)->sk_lock.slock))\n" - " #define bh_lock_sock_nested(__sk) \\" + " #define bh_lock_sock_nested(__sk) \\\n" + "\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-ia64\" in\n" + "the body of a message to majordomo@vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -12a123be78621dbcc2c9b915e57c5cf3a922af441e10ed27f3ce24b606ee22a6 +9b46c76f088971c5164cabfcb1897e483a3bfa4c7b4139fe5ec7a6eed081ba42
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.