Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4568208pxf; Tue, 30 Mar 2021 10:54:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzeKIcnKfLayjY0mEI6NXNyAgFYmqDrpRl610leQFUCjl1Sow54RGJYQpiH4wq1zddXwpr8 X-Received: by 2002:a17:906:f88a:: with SMTP id lg10mr35374874ejb.39.1617126875111; Tue, 30 Mar 2021 10:54:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617126875; cv=none; d=google.com; s=arc-20160816; b=dHYGRlejqBIUEa5U47rHMJmnqZxHO+2BVnu6zR8cVogGcaeusuSs/iSdL/OgCjK2J6 XWrbHBr1ut8yQ90HHp+PD5HfmfGalmLFm3hlHwaG70oAV6oE9emVSi0BeQ0apV11o8lr zyhLSvJxctwBknQrQASv0ezhtcbUXJWaJ4+YhcrBvh7tMiA/DuPemOnJn0HhtAjpmgO5 uIuiUfrkPCG0TUubHC5T440t3OuNIbdjVYtlYRGLhVQ/W3/j1w+yh5G63ji7MSKZh2FL EfkeiuyAP8X+dLf3QLUsSo8qj1ON8GfYrWE5NqkvtFdTEta3yzVnX3jVS29gK5ITxR7y Qj2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=YjgPknUpx6ijub4GHdEiRvZSDU1FqZwlL7wT3fyQ/R4=; b=BCnZ4Q4HcGGxMpZ7Vw9++2gcotfAP19n17YPi7uwA+GZh3h4Hk/U2GsU6TI/Jvlkn9 H/UAziAsLwePNwbIhKtVrwZkcpTs6rB6aTO0tfQCXRLYb6qJJm7mTFH2AMGcni8x3DPW 5DOrv+cDQ9krX2OzEjFiHxG2vQfrkoqYnF8EWXzuucWS/+KC2qC+hgqZmL5UG3NIKF5w Rc+EnOc26Fh+vxGQwxlCgFzbG5ZJ5zv2/cyk1hA1+LMKwe6/GOM9WBzj6m04a5wKqMXW qqxnDfYVHBtERkIDcFX3VCUYkpHv2sPPj029/60KoWURdYV1h4vbjp6CaG8QiA+6LrG/ 31uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@protocubo.io header.s=google header.b="AFRnX/BT"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protocubo.io Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g23si15241111ejx.623.2021.03.30.10.54.12; Tue, 30 Mar 2021 10:54:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@protocubo.io header.s=google header.b="AFRnX/BT"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protocubo.io Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231579AbhC3RxO (ORCPT + 99 others); Tue, 30 Mar 2021 13:53:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232059AbhC3RxK (ORCPT ); Tue, 30 Mar 2021 13:53:10 -0400 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38FD2C061574 for ; Tue, 30 Mar 2021 10:53:08 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id g20so16743864qkk.1 for ; Tue, 30 Mar 2021 10:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protocubo.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=YjgPknUpx6ijub4GHdEiRvZSDU1FqZwlL7wT3fyQ/R4=; b=AFRnX/BToqNeJ7jBkT+A78U2/chMo1d1iQamFxcc5m+JIO9wEEJNcUr3IeT/jIo3dh PjZcZjwHTexZQVpdF3aR7BXE1dL4zjhH0LHrRoDx+F843c5Tk3Qq4V7Mt/qeS3ZcyKla nKRu+TIXlRqQBCuIknbRXQbSkWy7xoS2hdY9zIHnakVwRqecXILONz/kmXDtIBOvbI63 VvKOs4cC80QdzFQVvWbq0AK3uXlcHe1CLObQfzhzmZTfXHExj+6SpQg8Ph5Kcz77N3ql kvH/Xw6viGxZkYoTvz08zyQAmKrjU4yiQjKa+Qd60aJtVBKKyFTklk77sOn9sOsuNm7m ESvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YjgPknUpx6ijub4GHdEiRvZSDU1FqZwlL7wT3fyQ/R4=; b=DRSArWyDsx3VXVK+8V+JWeXDzgXB1cBnsc6S9mzhJm5pydA1q+9CPSRGsawz0bDQIg v0bWqjsgTB9sT+AzMD5NIwiv2oHT903Swqz+qNbGyiCjFS5i9rRVcbXMmS8bFc8BPd3A S0zpHXnffUfpM7G/QYPVfjoV/lq3yWHjodDQpZhlfy6oIZVTOuqcdVeNQ3Hqd1gQ1Eee QGT6ly8P8iQSbU3Trsp/rx2YscpUBzeQEAqD9Ea/qUAIPMlEjLk6GZ+MwMoCUX3y4Zh5 4QzwTv3oSE+UmBidxO6yhpAEEOXhFw00KGECHgcseiJh+arXlrlc52fKlp/P+Dsn8hH2 ivpg== X-Gm-Message-State: AOAM533HTypS20sDXw5PfDBgfEmcR9K/Jk7G7sOBy9OjTzeWZQfdDcaq Lyccd80zXq28++21yXY8xrXqaRVNgTR/fQ== X-Received: by 2002:a37:a8d3:: with SMTP id r202mr32849486qke.383.1617126787406; Tue, 30 Mar 2021 10:53:07 -0700 (PDT) Received: from calvin.localdomain ([2804:14d:5c5a:802e:bdc9:ded9:cc08:a4e9]) by smtp.gmail.com with ESMTPSA id d68sm16446012qkf.93.2021.03.30.10.53.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Mar 2021 10:53:06 -0700 (PDT) Date: Tue, 30 Mar 2021 14:53:02 -0300 From: Jonas Malaco To: Guenter Roeck Cc: Jean Delvare , linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] hwmon: (nzxt-kraken2) mark and order concurrent accesses Message-ID: <20210330175302.ihsmijnidxjhmcqa@calvin.localdomain> References: <20210329082211.86716-1-jonas@protocubo.io> <20210329215339.GH220164@roeck-us.net> <20210330002131.s2qz3dr6bwr6jz25@calvin.localdomain> <56ebbf0f-cdcb-d5af-e1ad-c7604597566e@roeck-us.net> <20210330031652.zhhxft4trli6zqtw@calvin.localdomain> <37e5b3d3-8868-c70e-4c01-2d3d777df4de@roeck-us.net> <20210330062749.tcscp2kzxqugbtiv@calvin.localdomain> <38c76eb1-808a-1c9a-2494-208270a66e14@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <38c76eb1-808a-1c9a-2494-208270a66e14@roeck-us.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 30, 2021 at 03:51:21AM -0700, Guenter Roeck wrote: > [ ... ] > > Then please explain why _this_ use of time_after() is wrong but all > others in the kernel are not. Also, please note that we are not > concerned with code generation by the compiler as long as the > generated code is correct (and I don't see any indication that > it isn't). The accesses to priv->temp_input[], ->fan_input[] and ->updated (where this relates to your question about time_after()) are not wrong, but undefined. But if we are not concerned with code that is currently generated correctly, which indeed is the case in the five arch x compiler combinations I tested, then there simply is no point to this patch. Thanks for going through this with me, Jonas P.S. Admittedly from a sample way too small, but in the kernel time_after(jiffies, x) calls do not generally appear to involve an expression x with a data race. And there are a few calls where READ_ONCE() is indeed used in x.