From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752850AbdF2UsF (ORCPT ); Thu, 29 Jun 2017 16:48:05 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:39459 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751776AbdF2UsD (ORCPT ); Thu, 29 Jun 2017 16:48:03 -0400 Date: Thu, 29 Jun 2017 13:48:00 -0700 From: "Paul E. McKenney" To: Tejun Heo Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()? Reply-To: paulmck@linux.vnet.ibm.com References: <20170629181057.GA5228@linux.vnet.ibm.com> <20170629195322.GB9745@htj.duckdns.org> <20170629201443.GD2393@linux.vnet.ibm.com> <20170629201754.GC9745@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170629201754.GC9745@htj.duckdns.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17062920-0044-0000-0000-00000360B225 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007294; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00880543; UDB=6.00438974; IPR=6.00660695; BA=6.00005447; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016012; XFM=3.00000015; UTC=2017-06-29 20:48:01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062920-0045-0000-0000-0000078EB23D Message-Id: <20170629204800.GF2393@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-29_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706290333 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 29, 2017 at 04:17:54PM -0400, Tejun Heo wrote: > Hello, > > On Thu, Jun 29, 2017 at 01:14:43PM -0700, Paul E. McKenney wrote: > > On Thu, Jun 29, 2017 at 03:53:22PM -0400, Tejun Heo wrote: > > > Hello, Paul. > > > > > > On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote: > > > > If this code fragment doesn't deadlock, then CPU 0's spin_unlock_wait() > > > > must have executed before CPU 1's spin_lock(). However, even on x86, > > > > CPU 0's prior writes can be reordered with its subsequent reads, which > > > > means that r1 == 0 is possible, which means that the above condition > > > > could hold, even on x86. > > > > > > I see. Ah, that's a mind bender. > > > > It has indeed been providing at least its share of entertainment over > > the past little while. ;-) > > lol :) > > > > That part of the code should be dead now. I don't think we no longer > > > have any driver which doesn't have error handler set. I should rip > > > out that if/else. Also, ACQUIRE semantics should be enough there. > > > Nothing changes from the EH side there. > > > > It looks like we actually might get rid of spin_unlock_wait entirely. > > But how about if I just pull the spin_lock_irqsave() before the "if" > > and the spin_lock_irqrestore() after the "if"? Same effect, only > > difference is that the "if" and the "ap->eh_tries = ATA_EH_MAX_TRIES" > > end up under the lock, and I bet that you won't be able to measure > > the difference. (Please see below.) > > > > I will do this because I just now happened to be editing that file on > > my "eradicate spin_unlock_wait()" quest, but can easily rework the > > patch as desired. If you want something different, just let me know! > > Sounds good to me. That path isn't hot at all. No change made at > this level is gonna have any actual impact. Please go for whatever is > the simplest. For moving out the lock/unlock outside if/else, > > Acked-by: Tejun Heo Applied, and thank you! Thanx, Paul