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
| ||
|
Date: Tue, 17 Jun 2008 20:37:03 -0700 (PDT) From: David Miller <davem@...emloft.net> To: yanmin_zhang@...ux.intel.com Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org Subject: Re: IPF Montvale machine panic when running a network-relevent testing From: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com> Date: Wed, 18 Jun 2008 11:27:43 +0800 > 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 > 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 > to access the listen sock. > > Below patch against 2.6.26-rc6 fixes the issue. > > Signed-off-by: Zhang Yanmin <yanmin.zhang@...el.com> We reverted the guilty defer accept changes, please test Linus's current tree.
Powered by blists - more mailing lists