From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753964Ab3CRPbN (ORCPT <rfc822;w@1wt.eu>);
	Mon, 18 Mar 2013 11:31:13 -0400
Received: from mail-oa0-f53.google.com ([209.85.219.53]:36068 "EHLO
	mail-oa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751889Ab3CRPbL (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 18 Mar 2013 11:31:11 -0400
Message-ID: <5147333A.3010907@gmail.com>
Date: Mon, 18 Mar 2013 11:31:06 -0400
From: Vlad Yasevich <vyasevich@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Eric Dumazet <eric.dumazet@gmail.com>
CC: Neil Horman <nhorman@tuxdriver.com>, Sasha Levin <sasha.levin@oracle.com>,
        sri@us.ibm.com, "David S. Miller" <davem@davemloft.net>,
        linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
        Dave Jones <davej@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: sctp: hang in sctp_remaddr_seq_show
References: <51434D78.9030308@oracle.com>  <20130318110415.GA9478@hmsreliant.think-freely.org> <1363620340.29475.132.camel@edumazet-glaptop>
In-Reply-To: <1363620340.29475.132.camel@edumazet-glaptop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/18/2013 11:25 AM, Eric Dumazet wrote:
> On Mon, 2013-03-18 at 07:04 -0400, Neil Horman wrote:
>
>> I'm not sure why the process would never get back to the schedule, but looking
>> at the sctp_remaddr_seq_show function, I think that we should convert this
>> sequence:
>> 	sctp_local_bh_disable();
>> 	read_lock(&head->lock);
>> 	rcu_read_lock();
>>
>> to this:
>> 	read_lock(&head->lock);
>> 	rcu_read_lock_bh();
>>
>> Neil
>
> I dont think so.
>
> BH needs to be disabled before read_lock(&head->lock);
>
> or else, write_lock() could deadlock (assuming it can be called from BH)
>
>

If anything, this should probably be done like this:

rcu_read_lock();
read_lock_bh(&head->lock)
...

read_unlock_bh(&head->lock)
rcu_read_unlock();

-vlad