From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 A53E81E8320 for ; Tue, 9 Dec 2025 15:33:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765294393; cv=none; b=qMRLVD23A9IwmoWXed0tMTuZK88Yb+Exr61tDaBlkO8AX54wwuTJKPbiacOGGjeOQatAXzpD8SjZwyz/vo05bAW3sEoDo35qSacFG4nF0JjeIIWWDGQcg6dVXMmTPEdxEWzHQhReLQk5NAwHtmxkZhTi/I+lSJdN5AQRcPlygdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765294393; c=relaxed/simple; bh=omt3k6XQVWARv1dphoEhI09ELDwcNnzuL6UhWhyys9M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C13bLd6SqoZEbx1M2icLQ4Y5+ihZZ9S0sboJXeDe5BsvyGEzZ7dSpmGjB/zBa2YuRp3UAY0Ov3+7zECmsWSXXArU7ecCm6kHZwm/28DDT5PAK+oOcpbVQaMjTGpQkMzFBJfWODNgn5pk8SDFOiYMS/cwd19VDQ6OzJtUMglsFTk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=IEKk50Hw; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="IEKk50Hw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765294392; x=1796830392; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=omt3k6XQVWARv1dphoEhI09ELDwcNnzuL6UhWhyys9M=; b=IEKk50HwAVJKpYcoURlDJn4WqxJzpN4/vHLm6fSJhLPI6hIqZylW6edh OOECMqJD6e+JXEKhs/dgZSUIcL6RECvPulclRtQTMnWhNFlC5Bi3Ybsov dZyILGeWhNyYsoSixEIDB6Tp94XKv+zpCDzyD5wQYHqDdGeK4s+HtbNDh Adp2mtSeUazP7uaOuytp4usEtsNymhGvfBNVBmPRR0KZbnCY/1QU7S7Fq y0wDr0RBh9MAKGc1q577byXkWVBUnhrUjxXOE/ADOBTR9AG2wqO/sgq4q zIw+1zlK2VNz+H37dz5h3wROU9D5oYJ6E6q+SuL9YMLbuWhX9qS8oDWQ3 w==; X-CSE-ConnectionGUID: tupHwOpoRlehKSUfMIcjbQ== X-CSE-MsgGUID: iS1YMfPbQLSXDww7YPbyoA== X-IronPort-AV: E=McAfee;i="6800,10657,11637"; a="77574795" X-IronPort-AV: E=Sophos;i="6.20,261,1758610800"; d="scan'208";a="77574795" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2025 07:33:11 -0800 X-CSE-ConnectionGUID: bR9N4poeSk+BSaBbXy7PmA== X-CSE-MsgGUID: +njiolRySkex7KyIpLYn8w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,261,1758610800"; d="scan'208";a="233654521" Received: from dhhellew-desk2.ger.corp.intel.com (HELO localhost) ([10.245.245.237]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2025 07:33:09 -0800 Date: Tue, 9 Dec 2025 17:33:07 +0200 From: Andy Shevchenko To: Christian Marangi Cc: Andrew Morton , linux-kernel@vger.kernel.org, Ilpo =?iso-8859-1?Q?J=E4rvinen?= Subject: Re: [PATCH v2] resource: add WARN_ON_ONCE for resource_size() and document misusage Message-ID: References: <20251209150150.9525-1-ansuelsmth@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251209150150.9525-1-ansuelsmth@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Tue, Dec 09, 2025 at 04:01:40PM +0100, Christian Marangi wrote: > Commit 900730dc4705 ("wifi: ath: Use > of_reserved_mem_region_to_resource() for "memory-region"") uncovered a > fragility in the usage of the resource_size() helper that might result > in its misusage as a way to check for initialization of a passed resource > descriptor. > > In the referenced commit, resource_size() is wrongly assumed to return > 0 when a resource descriptor is init to all zero while in reality it > would return 1. > > This is caused by the fact that resource_size() calculates the size > with the following logic: > > end - start + 1 > > that with an all zero resource descriptor: > > 0 - 0 + 1 > > returns 1. > > One reason the BUG in the reference commit might have been introduced > is a logic error in the actual usage of resource_size(). > > Historically, it was assumed that resource_size() was ALWAYS > used AFTER APIs filled the data of the resource descriptor (or in case of > any error from such APIs, resource descriptor set to an invalid state) > > But lack of comments on what should be the proper usage of > resource_size() might have introduced some confusion in the specific > case of passing a resource descriptor initialized to all zeros. > > As described in the example, using resource_size() for a resource > descriptor that has zero start and end yields to resource size of 1 > (this is correct and necessary behavior!) which may beconfusing to > some callers. > > Hence it's ALWAYS wrong to initialize (and use) a resource descriptor > to all zero following the usual pattern: > > struct resource res = {}; > > The correct way to initialize an "uninitialized" resource descriptor would > be to use DEFINE_RES macro ideally with a proper type set to it > (for example by initializing it to zero start/size and IORESOURCE_UNSET). > > To catch any possible misusage of resource_size() helper, emit a WARN if > we detect the passed resource descriptor have zeroed flags. This would > signal the resource descriptor is not correctly inizialized and will > probably result in resource_size() returning unexpected sizes (for > example returning 1 if the resource descriptor is all set to zero). > > Also add kernel doc to resource_size() that in conjunction of WARN > should prevent from now on any possible misusage of this helper and > permit to catch and fix any possible BUG caused by this logic confusion. > #ifndef __ASSEMBLY__ > #include > +#include Even though it's under non-assembly, please use asm/bug.h where the macro is defined. This is a wide used header and putting unrelated stuff into the chain is not good and tend to add tangled dependencies in the future (if not now). > #include > #include > #include ... Otherwise LGTM. -- With Best Regards, Andy Shevchenko