Received: by 10.192.165.148 with SMTP id m20csp2143942imm; Sun, 6 May 2018 07:57:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpMfO1f/W6vIRtcAaa1NdTwYaBjCNSJp1YhtW7yMR6eMA8cvAiO9PTAkjr/dDuUgUVAkGZj X-Received: by 2002:a65:40c9:: with SMTP id u9-v6mr15388129pgp.222.1525618679574; Sun, 06 May 2018 07:57:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525618679; cv=none; d=google.com; s=arc-20160816; b=0EHQKtjgb1mgFmGImTELMx4/N+u5mr218evtfTogsaC1/dpPCkV1z3abH0QDRPBnUl zW51O6r2We8PqIwSpU3ix31AAEa0IZJTRDtQgdMgoxs2WohNA90mK3bZh9zzN6IXmmzH 5Nlc6MFpuuWIK5db/Ujf85yOsVizk8n0yiPDSHNhhb1wIc/9wTuzOU7oA44nrI4+3Lqw ER262HzOULQBwknd7/yhVdg+TUgimZs/OogvaIjkBU+ePSIUWgYOOqM4AS8ynxYLtcy0 KY5+exzQMl7hkQGskAF8/e3tkP43dj4ewSx5a2JdykS3cz9Xst001blF3+tR6q1MLcx0 V5kQ== 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:dkim-signature:arc-authentication-results; bh=yUXKO+dzJvHevTOenGzi/I51seVtI6qdipicjqgiMYo=; b=ei1w5KtlfX6ArWXecj0npZjlTay1RuY3isg0pBOmgsr2eaIpgypF2Y+ZTcSVC+GxD4 MePKQss+2tvvZYiV+khGiAtvzj5mvO+D+Es4e9VuLviU0/KCyCIEAZEHaMiW3JC6mreU RjjoUEtOUalNVFWaDIt/BaCES8fhOjCvOrwIRL3+oz6qyH1lPraxRx4GHSlSz9pqr8H2 RywRUVf29sYVoJgt0050IHZCv9WBbW6rwpbOl8SoipKK3lFpcXjCd+/kxh2S+I/TGu6X nWqEw4qLn2Raj2xiqU6qfdy6OMTF+ub+XaX+1+VwfZ9ACRGxOEbJRBEyPP+RGBgpAap8 l2WA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Jb9kx4W2; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f96-v6si20006499plb.418.2018.05.06.07.57.45; Sun, 06 May 2018 07:57:59 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Jb9kx4W2; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751814AbeEFO5c (ORCPT + 99 others); Sun, 6 May 2018 10:57:32 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34309 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751800AbeEFO5b (ORCPT ); Sun, 6 May 2018 10:57:31 -0400 Received: by mail-wm0-f68.google.com with SMTP id a137-v6so12655271wme.1 for ; Sun, 06 May 2018 07:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yUXKO+dzJvHevTOenGzi/I51seVtI6qdipicjqgiMYo=; b=Jb9kx4W266gZhh3m9nfi6WiHiSGmew7A+uixRbxYVIK+RyxT1xS+lj3PBb1f7NnvdD noOrDCaJM2ZQv2eBMKST0IF1VHmotFnMSoeVR9pbuR2K06o+twjDg+p1YspXT1e8aR+w 2uTeEdyjAUQC+UxLxz9eAMcQJ89ZrWPsW00m04HodoqSOKu0gsDQHrTA6UVEAjnhjzA7 LrotGoW9VtKa6VFC5M398D1SFRTFD1ov7ZkSypWrnvpyiyLxWf7EZNhO6RbjJOWNMEvP Vy58UuoC8muZWW2ntpWuBwFLg6Inim6QNIXCP5dzPggG+nTtCsEdLnoQXhYlSKcjEdg8 r9iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=yUXKO+dzJvHevTOenGzi/I51seVtI6qdipicjqgiMYo=; b=N1teHA10UJ91vVAM8ciAq7ZGgP7awCDg+aTuWUCgrLU/fIly8QARB6s7GQP229iiLe JQnG6BmEFt+6Mf1T0NeR1HfNwNCNTpbiDVPtExwd83UbqPk3TMxw4wcezRoDoIZtmsXs pqFZrEUyjvi6RDWBnBzekAt0bnSPud6ers95UbNeEdsl8JlveFNJHwepGnGNJkd0ivR6 6D2iX8Q4jzzNjij+gn/TwGTcMCPMrZXGGF2qzuYWanX6v5fZks7my0VMNk73hYUABJQt 8MeqSbwVLzFu+1h4riex2dV3mjLB3xOuC29mfmAJAbkMFOUq3KyaVpCkfq0tzn90rbap gnYg== X-Gm-Message-State: ALQs6tDi7E4qJjbfxrDHWhJx0GnJBwQi1bw/PVIiwiMNSVRO15Ti3bPZ V2JvxWK+gQH0025FSe8mZZyzsQ== X-Received: by 10.28.218.80 with SMTP id r77mr19731689wmg.105.1525618650134; Sun, 06 May 2018 07:57:30 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id b57-v6sm32552018wra.9.2018.05.06.07.57.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 06 May 2018 07:57:29 -0700 (PDT) Date: Sun, 6 May 2018 16:57:27 +0200 From: Ingo Molnar To: Andrea Parri Cc: Mark Rutland , Peter Zijlstra , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, aryabinin@virtuozzo.com, boqun.feng@gmail.com, catalin.marinas@arm.com, dvyukov@google.com, will.deacon@arm.com, Linus Torvalds , Andrew Morton , "Paul E. McKenney" , Peter Zijlstra , Thomas Gleixner Subject: Re: [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more Message-ID: <20180506145726.y4jxhvfolzvbuft5@gmail.com> References: <20180504173937.25300-1-mark.rutland@arm.com> <20180504173937.25300-2-mark.rutland@arm.com> <20180504180105.GS12217@hirez.programming.kicks-ass.net> <20180504180909.dnhfflibjwywnm4l@lakrids.cambridge.arm.com> <20180505081100.nsyrqrpzq2vd27bk@gmail.com> <20180505083635.622xmcvb42dw5xxh@gmail.com> <20180506141249.GA28723@andrea> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180506141249.GA28723@andrea> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andrea Parri wrote: > Hi Ingo, > > > From 5affbf7e91901143f84f1b2ca64f4afe70e210fd Mon Sep 17 00:00:00 2001 > > From: Ingo Molnar > > Date: Sat, 5 May 2018 10:23:23 +0200 > > Subject: [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more > > > > Before: > > > > #ifndef atomic_fetch_dec_relaxed > > # ifndef atomic_fetch_dec > > # define atomic_fetch_dec(v) atomic_fetch_sub(1, (v)) > > # define atomic_fetch_dec_relaxed(v) atomic_fetch_sub_relaxed(1, (v)) > > # define atomic_fetch_dec_acquire(v) atomic_fetch_sub_acquire(1, (v)) > > # define atomic_fetch_dec_release(v) atomic_fetch_sub_release(1, (v)) > > # else > > # define atomic_fetch_dec_relaxed atomic_fetch_dec > > # define atomic_fetch_dec_acquire atomic_fetch_dec > > # define atomic_fetch_dec_release atomic_fetch_dec > > # endif > > #else > > # ifndef atomic_fetch_dec_acquire > > # define atomic_fetch_dec_acquire(...) __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__) > > # endif > > # ifndef atomic_fetch_dec_release > > # define atomic_fetch_dec_release(...) __atomic_op_release(atomic_fetch_dec, __VA_ARGS__) > > # endif > > # ifndef atomic_fetch_dec > > # define atomic_fetch_dec(...) __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__) > > # endif > > #endif > > > > After: > > > > #ifndef atomic_fetch_dec_relaxed > > # ifndef atomic_fetch_dec > > # define atomic_fetch_dec(v) atomic_fetch_sub(1, (v)) > > # define atomic_fetch_dec_relaxed(v) atomic_fetch_sub_relaxed(1, (v)) > > # define atomic_fetch_dec_acquire(v) atomic_fetch_sub_acquire(1, (v)) > > # define atomic_fetch_dec_release(v) atomic_fetch_sub_release(1, (v)) > > # else > > # define atomic_fetch_dec_relaxed atomic_fetch_dec > > # define atomic_fetch_dec_acquire atomic_fetch_dec > > # define atomic_fetch_dec_release atomic_fetch_dec > > # endif > > #else > > # ifndef atomic_fetch_dec > > # define atomic_fetch_dec(...) __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__) > > # define atomic_fetch_dec_acquire(...) __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__) > > # define atomic_fetch_dec_release(...) __atomic_op_release(atomic_fetch_dec, __VA_ARGS__) > > # endif > > #endif > > > > The idea is that because we already group these APIs by certain defines > > such as atomic_fetch_dec_relaxed and atomic_fetch_dec in the primary > > branches - we can do the same in the secondary branch as well. > > > > ( Also remove some unnecessarily duplicate comments, as the API > > group defines are now pretty much self-documenting. ) > > > > No change in functionality. > > > > Cc: Peter Zijlstra > > Cc: Linus Torvalds > > Cc: Andrew Morton > > Cc: Thomas Gleixner > > Cc: Paul E. McKenney > > Cc: Will Deacon > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Ingo Molnar > > This breaks compilation on RISC-V. (For some of its atomics, the arch > currently defines the _relaxed and the full variants and it relies on > the generic definitions for the _acquire and the _release variants.) I don't have cross-compilation for RISC-V, which is a relatively new arch. (Is there any RISC-V set of cross-compilation tools on kernel.org somewhere?) Could you please send a patch that defines those variants against Linus's tree, like the PowerPC patch that does something similar: 0476a632cb3a: locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs ? ... and I'll integrate it into the proper place to make it all bisectable, etc. Thanks, Ingo