From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 16EA71459F6; Thu, 19 Mar 2026 15:49:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773935373; cv=none; b=h02Eob4XOGJmtMM/2ISE1ZIpRLXYKxxdc7SA9ki4qFN5brfpiZQXlcwhIoouTFiKd/svGz9qymkTmJoYeINBSCf+eqsu4hvOQYPN72GmQjYUaHfaRHzGSy69vyEaZpLMXrvlljrf7TN9hZC/OLiHk1ToBnKV34kz184IUvUo4kM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773935373; c=relaxed/simple; bh=cGkr+p16Ngs8vie3raqWm7LPgNZ8uve+QEs9dd/iT7g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X4yAEA5R0AyahPRPX9nxMHRz/rutgzQVqJsKgelk5RLH7ES13hFT02ltfGTX0C2SARY8HH6Bxev7PQ+V4Hem57zTc+dJ1u2c8f3HBn2GJlNJp3ZuV0GLkpsKJeyDEefPf8CLtRtQInT7+B2t9VKV532kogMytD4mNh2VHsSeGyQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ecSR50Mc; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ecSR50Mc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773935372; x=1805471372; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=cGkr+p16Ngs8vie3raqWm7LPgNZ8uve+QEs9dd/iT7g=; b=ecSR50Mc+7/Pfx8nNvQkjjMYdiL6ziTnRX9M+TYXWlt3XSWIU05JFyvN VFywkXRh1BbUbGgDYWmfJSd/P565NqvtJmIfePfFVE1tS7/zcMF9xZjRB ysANOI7E6OnUC+KqatJR/9ZnaMJg5sqFVs1GhTSe7+CYPeKXr1hi0lTjw G4tD/xoaTO6q9F2o8JSLxm/8gIwEAA1KkbUEcgmArcYsCcGGD9e5yJ5Dm TGzMk5lCk4ZhvwDVKKZK1mlHa7hceyv18UO1V+g9gjpMfcDNiKFZrmbIZ i6KWS83xsjbmfb7GY4PwDx7p5PYJFh85XBiawPd8AxvfLH9dh5OR1K8zZ A==; X-CSE-ConnectionGUID: QaMSATjeQvyMAgAasDyvnw== X-CSE-MsgGUID: eCEO59ivS3mSeQ0NOpu0vA== X-IronPort-AV: E=McAfee;i="6800,10657,11734"; a="86373816" X-IronPort-AV: E=Sophos;i="6.23,129,1770624000"; d="scan'208";a="86373816" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2026 08:49:32 -0700 X-CSE-ConnectionGUID: WKBqTyx9T3uNo1IiDQyJiw== X-CSE-MsgGUID: r1ZGyPPGRs6pANxhD0qq8Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,129,1770624000"; d="scan'208";a="218444375" Received: from klitkey1-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.120]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2026 08:49:29 -0700 Date: Thu, 19 Mar 2026 17:49:27 +0200 From: Andy Shevchenko To: Sean Chang Cc: Andrew Lunn , Chuck Lever , David Laight , Anna Schumaker , netdev@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, kernel test robot Subject: Re: [PATCH v3 3/3] nfs: refactor nfs_errorf macros and remove unused ones Message-ID: References: <20260319141846.78222-1-seanwascoding@gmail.com> <20260319141846.78222-4-seanwascoding@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Thu, Mar 19, 2026 at 10:59:02PM +0800, Sean Chang wrote: > On Thu, Mar 19, 2026 at 10:41 PM Andy Shevchenko > wrote: > > On Thu, Mar 19, 2026 at 10:18:46PM +0800, Sean Chang wrote: ... > > > #define nfs_invalf(fc, fmt, ...) ((fc)->log.log ? \ > > > invalf(fc, fmt, ## __VA_ARGS__) : \ > > > > > invalf(fc, fmt, ## __VA_ARGS__) : \ > > > ({ dfprintk(fac, fmt "\n", ## __VA_ARGS__); -EINVAL; })) > > > > Why not all of them? > > I initially only refactored nfs_errorf because it doesn't return a value. > For nfs_invalf, it will always return -EINVAL. Would you prefer me to > refactor it using the ({ ... }) statement expression pattern to keep the > return value, or is it better to leave it as is ? I don't think in this case it improves the situation. Yeah, it's unfortunate. > #define nfs_invalf(fc, fmt, ...) ({ \ > if ((fc)->log.log) \ > invalf(fc, fmt, ## __VA_ARGS__); \ I believe this already has an error code inside, that's why it's only added to the 'else' branch. > else \ > dfprintk(fac, fmt "\n", ## __VA_ARGS__);\ > -EINVAL; \ > }) Okay, let's go with your original approach (ideally these all probably should be replaced by static inline:s). Reviewed-by: Andy Shevchenko Tested-by: Andy Shevchenko Unrelated to the series, but if you want to address these: nfs/super.c:1170:49: warning: incorrect type in initializer (different address spaces) nfs/super.c:1170:49: expected struct rpc_xprt *xprt1 nfs/super.c:1170:49: got struct rpc_xprt [noderef] __rcu *cl_xprt nfs/super.c:1171:49: warning: incorrect type in initializer (different address spaces) nfs/super.c:1171:49: expected struct rpc_xprt *xprt2 nfs/super.c:1171:49: got struct rpc_xprt [noderef] __rcu *cl_xprt nfs/./nfstrace.h:1488:1: warning: dereference of noderef expression nfs/./nfs4trace.h:2168:1: error: too long token expansion nfs/./nfs4trace.h:2234:1: error: too long token expansion -- With Best Regards, Andy Shevchenko