From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B306C433E0 for ; Sun, 9 Aug 2020 23:17:12 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8181C206D8 for ; Sun, 9 Aug 2020 23:17:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8181C206D8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BPw3T2bjkzDqPl for ; Mon, 10 Aug 2020 09:17:09 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=telegraphics.com.au (client-ip=98.124.60.144; helo=kvm5.telegraphics.com.au; envelope-from=fthain@telegraphics.com.au; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by lists.ozlabs.org (Postfix) with ESMTP id 4BPw1k5RWhzDqLF for ; Mon, 10 Aug 2020 09:15:38 +1000 (AEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 9F8A729B87; Sun, 9 Aug 2020 19:15:28 -0400 (EDT) Date: Mon, 10 Aug 2020 09:15:18 +1000 (AEST) From: Finn Thain To: Guenter Roeck Subject: Re: [PATCH 1/9] macintosh/via-macii: Access autopoll_devs when inside lock In-Reply-To: <20200809190138.GA133890@roeck-us.net> Message-ID: References: <5952dd8a9bc9de90f1acc4790c51dd42b4c98065.1593318192.git.fthain@telegraphics.com.au> <20200809190138.GA133890@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Laurent Vivier , Mark Cave-Ayland , linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Geert Uytterhoeven , linuxppc-dev@lists.ozlabs.org, Joshua Thompson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sun, 9 Aug 2020, Guenter Roeck wrote: > Hi, > > On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote: > > The interrupt handler should be excluded when accessing the > > autopoll_devs variable. > > > > I am quite baffled by this patch. Other than adding an unnecessary lock > / unlock sequence, The new lock/unlock sequence means that the expression (autopoll_devs && !current_req) can be understood to be atomic. That makes it easier for me to follow (being that both variables are shared state). > accessing a variable (which is derived from another variable) from > inside or outside a lock does not make a difference. If autopoll_devs = > devs & 0xfffe is 0 inside the lock, it will just as much be 0 outside > the lock, and vice versa. > > Can you explain this in some more detail ? Not that is matters much > since the change already made it into mainline, but I would like to > understand what if anything I am missing here. > I think the new code is more readable and is obviously free of race conditions. It's not obvious to me why the old code was free of race conditions but if you can easily establish that by inspection then you are a better auditor than I am. Regardless, I'll stick with "Keep It Simple, Stupid".