Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2399969ybi; Thu, 18 Jul 2019 07:50:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqzgu0YLe/CI1iAJTtPfPFl2TcJYEm6qBb1/Hj1TZh3orer3byBp7zovsu0t5yqqROjjz35B X-Received: by 2002:a17:902:306:: with SMTP id 6mr51214835pld.148.1563461444431; Thu, 18 Jul 2019 07:50:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563461444; cv=none; d=google.com; s=arc-20160816; b=wtq0+OaVX2K+hRzq4vj9yfQnU5wD73AeGi/n/76nC8alIj1zfk63FeXOMd8P19NZVs ddzTePuyroeQpNzfL0Zjj41qkHVRrPox8C5yG5S3hFJNNlDNNB8rK02t1QE5kDwVN7O/ 4FLvSN9yMn6bYd3gU7HsiuecdO+qE1ub4iP6XQCTBOkPeuubblHX1Zr/x53oZzZU76o1 RKHcessnZZo6GsbUYXUJcH8E4tv6U4/57Ooow1cuFhqn/AGai+Buf5A5BLnFmBdsRqY1 abhUJtl2cPrTmE9fkIHLEHHK52eYgIiZiM9Uju4KxYxHM+yPt/f2Ax2FqKbLfoS4AoN3 bq4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=eGMuvOti0ZekWFQKpaTkbYnGOHCdcIkIiuyLw/awL6s=; b=M58mP4raPwpOD51Ez8+1j1eP9X8qbxhRqbVPp8oOSfcgLfDtBdroOp5tnBcuK6tv4i EaJe40MxOixMCOkBNEfkQsx8G1n//+d0XI34VGSHUxg1xsFHobIenvhKAbnnuQawhoVG Y5DNaP9PMZGusmmUMUpptZvcrk93S2PbLWtWDvK51bvMXSIG58Hv60XsbXGslrNplgMF nHC7c8KL8J1Ts93CDhA5+6R2nVXODWpWltwT2Xsq9Q05Ork1ESjpbLVrlKR+gePVubKu PxHy1hVSYwuqUHk8ZR8INs/RhNr1mbWM4HLAwlu83TFJIj8rx2QFgNPuf2trHeDT95uS cUyw== 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 u24si1876957plq.430.2019.07.18.07.50.28; Thu, 18 Jul 2019 07:50:44 -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 S2390705AbfGROuG (ORCPT + 99 others); Thu, 18 Jul 2019 10:50:06 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:52118 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727812AbfGROuF (ORCPT ); Thu, 18 Jul 2019 10:50:05 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1ho7jI-0000EU-Ch; Thu, 18 Jul 2019 22:49:56 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1ho7jC-0006I8-IG; Thu, 18 Jul 2019 22:49:50 +0800 Date: Thu, 18 Jul 2019 22:49:50 +0800 From: Herbert Xu To: Daniel Jordan Cc: Steffen Klassert , Andrea Parri , Boqun Feng , "Paul E . McKenney" , Peter Zijlstra , linux-arch@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Mathias Krause Subject: Re: [PATCH] padata: Replace delayed timer with immediate workqueue in padata_reorder Message-ID: <20190718144950.yc6sambgdsz7vrvq@gondor.apana.org.au> References: <20190716163253.24377-1-daniel.m.jordan@oracle.com> <20190717111147.t776zlyhdqyl5dhc@gondor.apana.org.au> <20190717232136.pboms73sqf6fdzic@ca-dmjordan1.us.oracle.com> <20190718033008.wle67s7esg27mrtz@gondor.apana.org.au> <20190718142515.teinr4da3gps5r7a@ca-dmjordan1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190718142515.teinr4da3gps5r7a@ca-dmjordan1.us.oracle.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 18, 2019 at 10:25:15AM -0400, Daniel Jordan wrote: > > Which memory barrier do you mean? I think you're referring to the one that > atomic_inc might provide? If so, the memory model maintainers can correct me > here, but my understanding is that RMW atomic ops that don't return values are > unordered, so switching the lines has no effect. > > Besides, the smp_mb__after_atomic is what orders the list insertion with the > trylock of pd->lock. The primitive smp_mb__after_atomic only provides a barrier when used in conjunction with atomic_inc (and similar atomic ops). The actual barrier may either be in smp_mb__after_atomic or the atomic op itself (which is the case on x86). Since we need the barrier to occur after the list insertion we must move both of these after the list_add_tail. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt