Date: Tue, 17 Jun 2008 20:37:03 -0700 (PDT)
Message-Id: <20080617.203703.254889774.davem@davemloft.net>
To: yanmin_zhang@linux.intel.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
       linux-ia64@vger.kernel.org
Subject: Re: IPF Montvale machine panic when running a network-relevent
 testing
From: David Miller <davem@davemloft.net>
In-Reply-To: <1213759663.25608.33.camel@ymzhang>
References: <1213345160.25608.3.camel@ymzhang>
	<1213759663.25608.33.camel@ymzhang>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 1158
Lines: 20

From: "Zhang, Yanmin" <yanmin_zhang@linux.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@intel.com>

We reverted the guilty defer accept changes, please test Linus's
current tree.
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?