Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp656127iog; Mon, 13 Jun 2022 10:00:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxngvOlKBSc/polZ4BQxvKx+BTirzBMiaHM7ZbnSa95ZpDcrp2rR0t6Q11yOWwpN9EMs7ln X-Received: by 2002:a63:88c8:0:b0:3fd:5229:a49f with SMTP id l191-20020a6388c8000000b003fd5229a49fmr473673pgd.199.1655139611260; Mon, 13 Jun 2022 10:00:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655139611; cv=none; d=google.com; s=arc-20160816; b=qJiRPF0C2ggmf4tLJCV9QJHIpBj/l0tYPAmaCzMLmsmybq1aXGS+P/bC8dGoRNKWfr Kywhut/nLXI9GySxs+OM5bDb2zAgLWsG0tU0N9efxPPob+1jvNJZ9+rTBNiUxLlBAJe8 7P00hGdUu4Mjig/E7hYtMmOp5xojNkq/BU3T5IFnurE7sJdREUEfzkgS2ENRQaOWLBa/ wbrJRBgkVs/afgRYqX/e010efudMM1QH+shdyiTamMkr6tUtj5JfLpWW2cHgadu8UOo8 Nj6dRHoWkX68TlrO3Dd71n1HM+b/pTgAoGgan770TNR8XISSET93UZ6Ig6xwI5GhsSMI T/Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=KQCwIkwNzwt5T2z3wlATn5QZJXZyj8/g94B/Y2n7Ov8=; b=1BaxH+8eQNgyWxZnx4lBL7wXaGYyq1Bg7jXZ7BHFiUJ4Ith+bXT4250v7obVhxxWXb D8g1ZJoPjwEumitLzYJ3MTsuNqh073exTE8g99uHRQmjV4YseBfepaPET8z1+oaydSUW neyGUG8Gnrd/CuuPndQbG/GlAaLX2JIquP7T38Z1jvh4+jZiP8Xnw8BObcobBRkEAVB+ 4a+RCsfQg5ZV5IzCZjcoWO4LNo54U+3+C9lGKkxQazlyFATtF/J+FkjC5m8/txGccX8j sVi1N+5Tc9O/Zs3RfvyieOO3uJoExMjXfSiPSSJPNRLW2qIzT2KWkAw12JrJrMKepglE HZuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RsztUVvq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j6-20020a056a00174600b0050e082dea07si10175348pfc.189.2022.06.13.09.59.58; Mon, 13 Jun 2022 10:00:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RsztUVvq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240254AbiFMQp3 (ORCPT + 99 others); Mon, 13 Jun 2022 12:45:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240005AbiFMQo7 (ORCPT ); Mon, 13 Jun 2022 12:44:59 -0400 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FEC21E4BE1 for ; Mon, 13 Jun 2022 07:33:56 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id t32so10118656ybt.12 for ; Mon, 13 Jun 2022 07:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KQCwIkwNzwt5T2z3wlATn5QZJXZyj8/g94B/Y2n7Ov8=; b=RsztUVvqZtKDuLU8Lf83jCg2FonaZq3j7tha/V+O/QezKPXwlEvSEPOQX3hz9T78C3 3I6j6z1A/Cq6rSJmdFgt0oN6wG+e9xT+Ae9I57CN7NuNV7UAGESXGdpL/0qjMFr6J1AO j5S+6qJRX5emBJ2bfvZ0aKKWa1x9S44BcdWCp78aC5PfePta2erze8nysaY1ttyVO7kx fWJ7ZvaryKTY+6zAJ5UhVNSOJgi3zgc40qe+mrW1Ay0ECDOBytM0OUitt40J2PFHczlR Z86EN3athSadQP2xV0dv7LzAY+7OnBLrfmhcH8PuFvJX/KIQYWgquzO8svWkc7MbNA5h H1mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KQCwIkwNzwt5T2z3wlATn5QZJXZyj8/g94B/Y2n7Ov8=; b=i0S+Gwiz64TSkG6DSgj9bujoBfFcHGSVTcC7JPlzES49/Xl3t3jdLWBCatdmkJ/Mvz 85hyQTiHENxqdTNdQ44HXNQ0l88qIjVypH9xWK1ar9lnUGpuww2CC0JzaZ6uMNL9+0q0 v3K2dfeLTZPeFSKRrNNnldHi6O6G/kxlk39KO7VXgjT6oldcul4KZblBnphRHCN6YAT4 U5vXLhf07cUraxdwJxSFSaB2mEPCjI88okk8FvA6Ao7OcAul841P4+4WetI5FcPpWp8G Z8D0ZxHNnnOy37r+TgVOtgmBIri9iUTGnDLChZsW6+wK6dKlz5YKqxSUC1D7jn8A0VBZ GOow== X-Gm-Message-State: AOAM533oHha7AbsDsmExpXDVG+71Rytd85bQfT44mAQ+nX4dLSERAsm+ +j/Nlj4pu91ylzprNqtlQrRsKgiNXrxEgzQNAgjYTw== X-Received: by 2002:a05:6902:102c:b0:663:32b8:4b24 with SMTP id x12-20020a056902102c00b0066332b84b24mr51076390ybt.1.1655130835059; Mon, 13 Jun 2022 07:33:55 -0700 (PDT) MIME-Version: 1.0 References: <20220610113427.908751-1-alexandr.lobakin@intel.com> <20220610113427.908751-3-alexandr.lobakin@intel.com> <22042c14bc6a437d9c6b235fbfa32c8a@intel.com> <20220613141947.1176100-1-alexandr.lobakin@intel.com> In-Reply-To: <20220613141947.1176100-1-alexandr.lobakin@intel.com> From: Marco Elver Date: Mon, 13 Jun 2022 16:33:17 +0200 Message-ID: Subject: Re: [PATCH v2 2/6] bitops: always define asm-generic non-atomic bitops To: Alexander Lobakin Cc: Tony Luck , Andy Shevchenko , Arnd Bergmann , Yury Norov , Mark Rutland , Matt Turner , Brian Cain , Geert Uytterhoeven , Yoshinori Sato , Rich Felker , "David S. Miller" , Kees Cook , "Peter Zijlstra (Intel)" , Borislav Petkov , Greg Kroah-Hartman , "linux-alpha@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-ia64@vger.kernel.org" , "linux-m68k@lists.linux-m68k.org" , "linux-sh@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Jun 2022 at 16:21, Alexander Lobakin wrote: > > From: Marco Elver > Date: Fri, 10 Jun 2022 18:32:36 +0200 > > > On Fri, 10 Jun 2022 at 18:02, Luck, Tony wrote: > > > > > > > > +/** > > > > > + * generic_test_bit - Determine whether a bit is set > > > > > + * @nr: bit number to test > > > > > + * @addr: Address to start counting from > > > > > + */ > > > > > > > > Shouldn't we add in this or in separate patch a big NOTE to explain that this > > > > is actually atomic and must be kept as a such? > > > > > > "atomic" isn't really the right word. The volatile access makes sure that the > > > compiler does the test at the point that the source code asked, and doesn't > > > move it before/after other operations. > > > > It's listed in Documentation/atomic_bitops.txt. > > Oh, so my memory was actually correct that I saw it in the docs > somewhere. > WDYT, should I mention this here in the code (block comment) as well > that it's atomic and must not lose `volatile` as Andy suggested or > it's sufficient to have it in the docs (+ it's not underscored)? Perhaps a quick comment in the code (not kerneldoc above) will be sufficient, with reference to Documentation/atomic_bitops.txt.