From: Christian Marangi <ansuelsmth@gmail.com>
To: Christian Marangi <ansuelsmth@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Magnus Damm <damm@igel.co.jp>,
linux-kernel@vger.kernel.org
Cc: "Rob Herring (Arm)" <robh@kernel.org>, stable@vger.kernel.org
Subject: [PATCH] resource: handle wrong resource_size value on zero start/end resource
Date: Sun, 7 Dec 2025 22:53:48 +0100 [thread overview]
Message-ID: <20251207215359.28895-1-ansuelsmth@gmail.com> (raw)
Commit 900730dc4705 ("wifi: ath: Use
of_reserved_mem_region_to_resource() for "memory-region"") uncovered a
massive problem with the usage of resource_size() helper.
The reported commit caused a regression with ath11k WiFi firmware
loading and the change was just a simple replacement of duplicate code
with a new helper of_reserved_mem_region_to_resource().
On reworking this, in the commit also a check for the presence of the
node was replaced with resource_size(&res). This was done following the
logic that if the node wasn't present then it's expected that also the
resource_size is zero, mimicking the same if-else logic.
This was also the reason the regression was mostly hard to catch at
first sight as the rework is correctly done given the assumption on the
used helpers.
BUT this is actually not the case. On further inspection on
resource_size() it was found that it NEVER actually returns 0.
Even if the resource value of start and end are 0, the return value of
resource_size() will ALWAYS be 1, resulting in the broken if-else
condition ALWAYS going in the first if condition.
This was simply confirmed by reading the resource_size() logic:
return res->end - res->start + 1;
Given the confusion, also other case of such usage were searched in the
kernel and with great suprise it seems LOTS of place assume
resource_size() should return zero in the context of the resource start
and end set to 0.
Quoting for example comments in drivers/vfio/pci/vfio_pci_core.c:
/*
* The PCI core shouldn't set up a resource with a
* type but zero size. But there may be bugs that
* cause us to do that.
*/
if (!resource_size(res))
goto no_mmap;
It really seems resource_size() was tought with the assumption that
resource struct was always correctly initialized before calling it and
never set to zero.
But across the year this got lost and now there are lots of driver that
assume resource_size() returns 0 if start and end are also 0.
To better handle this and make resource_size() returns correct value in
such case, add a simple check and return 0 if both resource start and
resource end are zero.
Cc: Rob Herring (Arm) <robh@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 1a4e564b7db9 ("resource: add resource_size()")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
include/linux/ioport.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 9afa30f9346f..1b8ce62255db 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -288,6 +288,9 @@ static inline void resource_set_range(struct resource *res,
static inline resource_size_t resource_size(const struct resource *res)
{
+ if (!res->start && !res->end)
+ return 0;
+
return res->end - res->start + 1;
}
static inline unsigned long resource_type(const struct resource *res)
--
2.51.0
next reply other threads:[~2025-12-07 21:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-07 21:53 Christian Marangi [this message]
2025-12-07 23:12 ` [PATCH] resource: handle wrong resource_size value on zero start/end resource Andy Shevchenko
2025-12-07 23:20 ` Christian Marangi
2025-12-07 23:46 ` Andy Shevchenko
2025-12-07 23:23 ` Andy Shevchenko
2025-12-07 23:33 ` Christian Marangi
2025-12-07 23:57 ` Andy Shevchenko
2025-12-08 0:00 ` Andy Shevchenko
2025-12-08 13:29 ` Ilpo Järvinen
2025-12-08 13:47 ` Christian Marangi
2025-12-08 15:03 ` Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251207215359.28895-1-ansuelsmth@gmail.com \
--to=ansuelsmth@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=damm@igel.co.jp \
--cc=dan.j.williams@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox