Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5505102pxb; Wed, 26 Jan 2022 13:38:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJxdFgvTFo8sC8HYFdUO5YRsedy1IPH3tk9cQmAoSN9gUA5BQkrnGD/pDH2peHZuQ9DjNNIn X-Received: by 2002:a17:907:d29:: with SMTP id gn41mr532351ejc.45.1643233080238; Wed, 26 Jan 2022 13:38:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643233080; cv=none; d=google.com; s=arc-20160816; b=sza//GBtCyp7KApTe/odAq1L/3+NIGhfJTep8gWMZfLyZxqKQXgp8HBzaodhLz9FZ1 A4/aR0bAjxaIIlj/i3kDPx+7tAfW/kL30u9qoDEvO1T1dXqJasOGlfXU/glOeUWhZ+a+ abSfGc5sHYFnepO3nvFL+cYLaxxYKYHAZboUoz9Mmtt/98RawqnydxqCl7Se4mMv0DlI XbIf1NU2OPbnfmQ09O2zTEqTPL0kSW9E9ph6bIFVVxVf2keeJgNtcmj0vSR8jqDqh+tS +aGBhWoIqoDgpnuiO+wR5FkeEjo0/Dw2YyMSAqltZkOg+H7vHqwQQ8NjzqwzYpTsE+w1 AnYw== 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=hqZ5S1prQcULJgjev4pMri/oRUOkdQMRX3yC6zfVtIg=; b=DFvLtL7OqiGZRzF+qWyFgAHLLiIbsgSEXm2OoBqoa4Jg3Q1k2bCD54g1D6pzfJfE3J KYQUOJxUpB6ukLub+SPSoHmvES+aR0hs2g/PZ43azaaS6DUYuD02CCDadqT7PgRXSSnR ggdNyCn8hiz7RDDkveqGfq7Zg8EDhgVSOFQBKvjl9y4DiOprxiAzCFspseUAeylhXxOm 1gzvi3NDhogCDBZeFBa3V50n5HQsIWkwVHQjmN0G4tu1uu4iLHFK2ELa6phwd5GZv722 k0kJbwdVVHksmVJzmZo8RWUSSdbO+RuUdCGvXc+/5aGaOl3UbNsO9SIU992nAfqC9o2g 4fAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hNs0q2Z0; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hs36si202803ejc.463.2022.01.26.13.37.34; Wed, 26 Jan 2022 13:38:00 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=hNs0q2Z0; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242255AbiAZOkH (ORCPT + 99 others); Wed, 26 Jan 2022 09:40:07 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:48871 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242203AbiAZOkF (ORCPT ); Wed, 26 Jan 2022 09:40:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643208005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hqZ5S1prQcULJgjev4pMri/oRUOkdQMRX3yC6zfVtIg=; b=hNs0q2Z0TximkBB1XVshKnU1hfjHIbesIYizb2XA9iqE1JevkntJXHsSSjvwphrk2GEoZE 1oNVHG1TRjJsXjVjmYa8B6SweF5bApEEe6Kcym2egOpwM//V8xvCjrV6AcDwfTBarWGwyL VGHIAwTMeeNxV0jFvNjWs3hxg8o/aSQ= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-582-MJC7PAZ1PYGh85kqV5HCqg-1; Wed, 26 Jan 2022 09:40:03 -0500 X-MC-Unique: MJC7PAZ1PYGh85kqV5HCqg-1 Received: by mail-qk1-f200.google.com with SMTP id q5-20020a05620a0d8500b004738c1b48beso17301190qkl.7 for ; Wed, 26 Jan 2022 06:40:03 -0800 (PST) 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=hqZ5S1prQcULJgjev4pMri/oRUOkdQMRX3yC6zfVtIg=; b=8Efjqwv0UwRaSEi3UhMoXBrTgXuXSBATdET9HhyzZndINK31t73WpmuEdpATL3Tf/l 1lHpbeHZOIHiaJxtq6YAr/HtYCDP36KEUK3lnCpkY5okd2yMbwQIBNbovVCxkZNpOA/G YaPDxQQhc8Z41RWR5Iwnmn/bk2jZZCVugpqWm9hMkyZjTrnD1XWuKN80137gKZjmnoQ/ tVdqcTIr+7R5yHdFEAo7ORfWS9zK3GuzQa3qHfzVT55R6wwBVFOAUox9KTJhFKzX282z dzn+mFfnogmmaJ5lsbVmx+U2TwEt7ry5xrWUoUvd3OJH3f4kOgbSN4oUVis+SLQNDi3X qK2g== X-Gm-Message-State: AOAM530sSswyQo5Qx9NyI2M5CLzCsSw21BD8JPtc56XyLWm3dWbqLEvk 3GYIXmJ4mZGu2UN+Kvct/UF7avIicaCHPEGKSfjpVnnRDx6xVmeyTCbUg/kuo8+F9TCj516yl09 OgWSfOaQ1jpNu1CxD0bviy78+xXx8XlIrDsprTGpv X-Received: by 2002:a05:6214:21ef:: with SMTP id p15mr17778184qvj.92.1643208003253; Wed, 26 Jan 2022 06:40:03 -0800 (PST) X-Received: by 2002:a05:6214:21ef:: with SMTP id p15mr17778166qvj.92.1643208003014; Wed, 26 Jan 2022 06:40:03 -0800 (PST) MIME-Version: 1.0 References: <202201221028.YKA8kSdm-lkp@intel.com> <91901e7b-7d82-116c-aaf2-c74c6a6b999c@infradead.org> <20220124124530.GS1951@kadam> <20220124201417.GI4285@paulmck-ThinkPad-P17-Gen-1> <20220124220628.GL4285@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: From: Alexander Aring Date: Wed, 26 Jan 2022 09:39:51 -0500 Message-ID: Subject: Re: fs/dlm/midcomms.c:913:22: sparse: sparse: restricted __le32 degrades to integer To: paulmck@kernel.org Cc: Dan Carpenter , Randy Dunlap , kernel test robot , kbuild-all@lists.01.org, linux-kernel@vger.kernel.org, David Teigland , cluster-devel , linux-sparse@vger.kernel.org, rcu@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Jan 25, 2022 at 5:35 PM Alexander Aring wrote: > > Hi, > > On Mon, Jan 24, 2022 at 5:14 PM Paul E. McKenney wrote: > > > > On Mon, Jan 24, 2022 at 04:36:55PM -0500, Alexander Aring wrote: > > > Hi, > > > > > > On Mon, Jan 24, 2022 at 3:23 PM Paul E. McKenney wrote: > > > > > > > > On Mon, Jan 24, 2022 at 12:41:04PM -0500, Alexander Aring wrote: > > > > > Hi, > > > > > > > > > > On Mon, Jan 24, 2022 at 12:36 PM Alexander Aring wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Mon, Jan 24, 2022 at 12:21 PM Alexander Aring wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Jan 24, 2022 at 7:46 AM Dan Carpenter wrote: > > > > > > > > > > > > > > > > On Sun, Jan 23, 2022 at 01:41:52PM -0500, Alexander Aring wrote: > > > > > > > > > > > > > > > > > > I see also: > > > > > > > > > > > > > > > > > > fs/dlm/midcomms.c:213:1: sparse: sparse: symbol > > > > > > > > > '__srcu_struct_nodes_srcu' was not declared. Should it be static? > > > > > > > > > > > > > > > > > > > > > > > > > Why not just do this? (Untested. Maybe I don't understand?) > > > > > > > > > > > > > > > > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h > > > > > > > > index cb1f4351e8ba..a164089abec4 100644 > > > > > > > > --- a/include/linux/srcutree.h > > > > > > > > +++ b/include/linux/srcutree.h > > > > > > > > @@ -121,7 +121,7 @@ struct srcu_struct { > > > > > > > > #ifdef MODULE > > > > > > > > # define __DEFINE_SRCU(name, is_static) \ > > > > > > > > is_static struct srcu_struct name; \ > > > > > > > > - struct srcu_struct * const __srcu_struct_##name \ > > > > > > > > + is_static struct srcu_struct * const __srcu_struct_##name \ > > > > > > > > __section("___srcu_struct_ptrs") = &name > > > > > > > > #else > > > > > > > > # define __DEFINE_SRCU(name, is_static) \ > > > > > > > > > > > > > > > > > > > > > > I tried it and yes it will fix the issue and introduce another one > > > > > > > about "is_static struct srcu_struct * const __srcu_struct_##name" is > > > > > > > unused ("-Wunused-const-variable"). > > > > > > > I added a __maybe_unused after the introduced is_static and it seems > > > > > > > to fix the introduced issue, now it compiles and sparse is happy. I am > > > > > > > not sure if this is the right fix? > > > > > > > > > > > > it is obviously unused, but it has something to do with > > > > > > "__section("___srcu_struct_ptrs")" and during module loading it, I > > > > > > suppose, srcu tries to access it to find whatever needs to be > > > > > > registered? > > > > > > > > > > Sorry, but if this is true then it can't be declared as static... and > > > > > we are at the beginning again. > > > > > > > > Welcome to my world!!! ;-) > > > > > > > > More seriously, thank you for chasing this down. But would it work to > > > > add a declaration just before? > > > > > > > > > > only if I add an "extern" in front of the declaration before, so it looks like: > > > > > > extern struct srcu_struct * const __srcu_struct_##name; > > > > > > (compile and sparse tested only) > > > > If that works for everyone, it seems worth persuing. > > > > One way to test this is as follows: > > > > 1. Build a kernel with CONFIG_RCU_TORTURE_TEST=m. Boot this and > > type "modprobe rcutorture torture_type=srcu". > > > > If you want to stop the torture test, type "rmmod rcutorture". > > > > This will test DEFINE_SRCU() for the module case. > > > > I tested this case, I still need to do the 2. case. Sorry I am quite > busy with something else, but I am still working on it. > I did the 2. test successful...: "tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 3 --configs 'SRCU-N' --trust-make" but I was required to hack it because my "qemu-system-x86_64" did not exist, it was "/usr/libexec/qemu-kvm" (it was able to run by just doing a symlink). I think I already cc'd the right people to report this issue (rcu subsystem)... I will send a patch for the export declaration soon as possible. - Alex