From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Subject: Re: sctp: hang in sctp_remaddr_seq_show Date: Mon, 18 Mar 2013 11:31:06 -0400 Message-ID: <5147333A.3010907@gmail.com> References: <51434D78.9030308@oracle.com> <20130318110415.GA9478@hmsreliant.think-freely.org> <1363620340.29475.132.camel@edumazet-glaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Neil Horman , Sasha Levin , sri@us.ibm.com, "David S. Miller" , linux-sctp@vger.kernel.org, netdev@vger.kernel.org, Dave Jones , "linux-kernel@vger.kernel.org" To: Eric Dumazet Return-path: In-Reply-To: <1363620340.29475.132.camel@edumazet-glaptop> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.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