From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD07F7DA82 for ; Thu, 27 Mar 2025 20:17:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743106636; cv=none; b=dhJ+WjnClNKSN2NyT2cbzN3Tw7bETkuXfunRKLKUwVUbqs4Y5yG5/UIbPFgt379iJUX17KUL/PbNrsbQXxb01E82S/nLwCqMBg53nQiKeVyqLXbTH7ikejJitO4qDfbbZoDvHBZgZZqIRw6wbE560pQhaXeOR0L+o54H+Bpb+v0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743106636; c=relaxed/simple; bh=SbVauLt5vagTUcaUFRJFtbbcHoJHFUXawYx5boh4whc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lYmFfPIQPjWeuqXu8HWbK+eBNY7A3v1Gn8kRxFtGuw7pXTtxJFzT9OvUbl5ZhshKmH2/uLHTjcMOQNoFQeTFm26/wvUBUWQzPzqCQzTMVcY94aSioomzmwKydeGeK3gMKaQDkpxRSYp4Fm9tNBbnWhTvkYBrK2FGqu3Zuzzn7bY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IwYTilgV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IwYTilgV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D718EC4CEDD; Thu, 27 Mar 2025 20:17:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743106636; bh=SbVauLt5vagTUcaUFRJFtbbcHoJHFUXawYx5boh4whc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IwYTilgV/6Ei/pfDd0o6uFkrT+s9a2/FD6zjUxFHjneHloVmfBuR8yMgs+gFRKL15 Ql+1wZF9cVWqmZNR4+rFjNr3gAPeAx18HUh20zCunSG4JJ2jVG2wsgklDfrkERJclt do44APNojdwrPFzMMRPw1Zlno+ujlU9dnHk/RAtGZ49D0Ly1fqy6A8g3Ybkar2W4Ml ZX4b0j6ZX83G6PU/fPY8js8HVdnhs98Ixy+SoIpC96pqnK2yyPltWp9X/kV7W2Com1 sq5mYWeFW71Zf79R0VugOvmbaiqe9FdOsL7/xZo8nGxm0NhQ0fDakGFUV6AJFPat5o S4crFf3+jT/JA== Date: Thu, 27 Mar 2025 16:17:14 -0400 From: Mike Snitzer To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Jeff Johnson , Chuck Lever , linux-nfs@vger.kernel.org Subject: Re: nfs: add dummy definition for nfsd_file Message-ID: References: <20250215165100.jlibe46qwwdfgau5@pali> <20250223182746.do2irr7uxpwhjycd@pali> <20250318190520.efwb45jarbyacnw4@pali> <20250326205919.gdxxtcejde2jpil7@pali> <20250327082833.l2w3cdlgjdzixskp@pali> Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250327082833.l2w3cdlgjdzixskp@pali> On Thu, Mar 27, 2025 at 09:28:33AM +0100, Pali Rohár wrote: > On Wednesday 26 March 2025 22:00:02 Mike Snitzer wrote: > > On Wed, Mar 26, 2025 at 09:59:19PM +0100, Pali Rohár wrote: > > > On Wednesday 26 March 2025 08:33:32 Jeff Johnson wrote: > > > > On 3/26/2025 8:09 AM, Mike Snitzer wrote: > > > > > Add dummy definition for nfsd_file in both nfslocalio.c and localio.c > > > > > so older gcc (e.g. EL8's 8.5.0) can be used. Older gcc causes RCU > > > > > code (rcu_dereference and rcu_access_pointer) to dereference what > > > > > should just be an opaque pointer with its use of typeof. > > > > > > > > > > So without the dummy definition compiling with older gcc fails. > > > > > > > > > > Link: https://lore.kernel.org/all/Zsyhco1OrOI_uSbd@kernel.org/ > > > > > Fixes: 55a9742d02eff ("nfs: cache all open LOCALIO nfsd_file(s) in client") > > > > > > As this change is fixing compile error, should not be there also cc: stable line? > > > > Any commit with a Fixes: tag will automatically be picked up by > > stable@ once it is merged. An explicit cc: sttable@ would be > > redundant. > > From my experience, when the backporting of commit with both Fixes:+Cc: > fails then the committer of the patch and also other is informed by > robot email. If there is only Fixes: without Cc: then people are not > informed. > > So I used the Fixes:+Cc: for such build issues or important issues to > ensure that the change is really backported. If a Fixes commit isn't able to be easily backported then mail is sent giving notice to the author. That has always been sufficient for anything I have authored. > > > > > > > > I saw this issue using crosstools/gcc-13.3.0-nolibc and this patch fixes it. > > > > > > So maybe the commit message can be adjusted, so it does not say only > > > "older gcc"? > > > > I don't see the need to list all compilers, I documented the compiler > > that motivated my fix. Fact that it applicable for > > crosstools/gcc-13.3.0-nolibc (which I don't have context for what it > > is.. but if this commit is needed for it then it is a suspect "new" > > compiler). > > My impression was that the commit is fixing just the compilation with > old gcc versions. But it seems that also new are affected. That is why I > suggested to adjust it, so it would be clear that it applies for new gcc > versions too. Really not sure why you're being so pedantic. I submitted what I developed as a fix for my needs with an old gcc (from EL8) and so I submitted what I had. We don't need to impose every compiler be covered in a commit header (especially when the new case occurred 4 months later). crosstools/gcc-13.3.0-nolibc is not something I'm going to hunt down and pick apart to prove that it is using old compiler technology, but I'm inclined to think it is. Mike