From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752294AbdK0Ltt (ORCPT ); Mon, 27 Nov 2017 06:49:49 -0500 Received: from foss.arm.com ([217.140.101.70]:36848 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752258AbdK0Ltr (ORCPT ); Mon, 27 Nov 2017 06:49:47 -0500 Date: Mon, 27 Nov 2017 11:49:48 +0000 From: Will Deacon To: Peter Zijlstra Cc: Sebastian Ott , Ingo Molnar , Martin Schwidefsky , Heiko Carstens , linux-kernel@vger.kernel.org Subject: Re: [bisected] system hang after boot Message-ID: <20171127114947.GA30679@arm.com> References: <20171122182659.GA22648@arm.com> <20171122202217.GO3326@worktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171122202217.GO3326@worktop> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote: > On Wed, Nov 22, 2017 at 06:26:59PM +0000, Will Deacon wrote: > > > Now, I can't see what the break_lock is doing here other than causing > > problems. Is there a good reason for it, or can you just try removing it > > altogether? Patch below. > > The main use is spin_is_contended(), which in turn ends up used in > __cond_resched_lock() through spin_needbreak(). > > This allows better lock wait times for PREEMPT kernels on platforms > where the lock implementation itself cannot provide 'contended' state. > > In that capacity the write-write race shouldn't be a problem though. I'm not sure why it isn't a problem: given that the break_lock variable can read as 1 for a lock that is no longer contended and 0 for a lock that is currently contended, then the __cond_resched_lock is likely to see a value of 0 (i.e. spin_needbreak always return false) more often than no since it's checked by the lock holder. > That said, I'd not be horribly sad to see this go, I've always found it > to be quite the ugly hack and taking it out should provide some > incentive for better lock implementations for the archs relying on this. Right, and they can always implement arch_spin_is_contended if they have a good way to do it. I'll post this diff as a full patch, since it's clearly needed to get some s390 systems booting against with 4.15. Will