Received: by 10.213.65.68 with SMTP id h4csp551297imn; Tue, 27 Mar 2018 04:36:15 -0700 (PDT) X-Google-Smtp-Source: AG47ELtqgzYA17vjD9jwte32OoDPMU9nPwOp8pDDz+f9mzWYjbuzBp2cI+iBKO3NwA1WKqUrsV1V X-Received: by 2002:a17:902:2be4:: with SMTP id l91-v6mr40591165plb.102.1522150575846; Tue, 27 Mar 2018 04:36:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522150575; cv=none; d=google.com; s=arc-20160816; b=Wx6dr3mO7MUr5Vx40ZIUpL+EaWIRZC1vfq+KxJbwwxe8/Ok9IQvmuon3fwsRmIwvla mPVZkTcm6+fVU3ZfmIa9EMbX063fgshQJ9C90Zj7H77Q6k2pd9GBCXINiHXKYzlFpwx2 8KvbR6b0lzq1snJVn3uT5+9d5eKsw+q0CqHXPCHRF7i47HxjtUSrnuDZzkxzOzCiawBf FNyGhPl54zAXR9XI5A9TFHNo4yFXqc5H5L87hGwv7lH0lKk0vQt0YD5R0jmJ3bsdmCuG xBC8o6c0Sg8Ml+zHChQkEuycJRm1gZ3wkQLj6PEdIEJGNhham12qr+L1PAFJPsukmjJI h9gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=pMOof9IOsZuydXrVOX1dgbTqSBp0WRuDalnk0aYpxDc=; b=dNI7f4FygQqx+zCVHB+Fv8WC1dF/7ZcQEssyy3+7JA6pMmtBU8GgKFM4xscBi/SseX 6lnRR5SeKceplOE0rTKPwdpE7My/DpW4T6/ir9sun3/9jpk43gOpYkl0PecSCXdTDmGx QeBmuIrqSu19Hb/66c4TLjJBT/jyOc4U730jI77dBk0ZC51pblOgJUb9BrsAxj/IX2Bv 8/RIXlZ69dE3FRfAzqtUGpGfnVjpHa/SYUyrcxaduKgxAFGMSgXq6s9vM1YVBRC/Dwq1 V3T03bxO0KQN8b9ZQJscuj++1NiX2+Yuypi3oYqULpC/tv5t59pa/rohjN7EtmpmJiwi NHCQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a12-v6si1022761plp.690.2018.03.27.04.36.01; Tue, 27 Mar 2018 04:36:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752128AbeC0Ldt (ORCPT + 99 others); Tue, 27 Mar 2018 07:33:49 -0400 Received: from gate.crashing.org ([63.228.1.57]:37689 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751124AbeC0Ldp (ORCPT ); Tue, 27 Mar 2018 07:33:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w2RBX7sW029920; Tue, 27 Mar 2018 06:33:08 -0500 Message-ID: <1522150386.7364.53.camel@kernel.crashing.org> Subject: Re: [PATCH for-4.17 2/2] powerpc: Remove smp_mb() from arch_spin_is_locked() From: Benjamin Herrenschmidt To: Andrea Parri Cc: Paul Mackerras , Michael Ellerman , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Linus Torvalds Date: Tue, 27 Mar 2018 22:33:06 +1100 In-Reply-To: <20180327102521.GA7347@andrea> References: <1522060667-7034-1-git-send-email-andrea.parri@amarulasolutions.com> <1522109216.7364.30.camel@kernel.crashing.org> <20180327102521.GA7347@andrea> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 (3.26.6-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2018-03-27 at 12:25 +0200, Andrea Parri wrote: > > I would rather wait until it is properly documented. Debugging that IPC > > problem took a *LOT* of time and energy, I wouldn't want these issues > > to come and bite us again. > > I understand. And I'm grateful for this debugging as well as for the (IMO) > excellent account of it you provided in 51d7d5205d338. > > Said this ;) I cannot except myself from saying that I would probably have > resisted that solution (adding an smp_mb() in my arch_spin_is_locked), and > instead "blamed"/suggested that caller to fix his memory ordering... This is debatable. I tend go for the conservative approach assuming most people using fairly high level APIs such as spin_is_locked() are not fully cognisant of the subtleties of our memory model. After all, it works on x86 ... The fact that the load can leak into the internals of spin_lock() implementation and re-order with the lock word load itself is quite hard to fathom for somebody who doesn't have years of experience dealing with that sort of issue. So people will get it wrong. So unless it's very performance sensitive, I'd rather have things like spin_is_locked be conservative by default and provide simpler ordering semantics. Cheers, Ben.