From nobody Tue Dec 16 16:39:11 2025 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B3B22E7657 for ; Wed, 10 Dec 2025 17:39:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765388350; cv=none; b=ZXjidkAQEuwi+QfjVgPsOIWBQH6c423ztfWnsvI7pIJQTZb+M7Vx6aQi6HskXbxSoI3zm2uPcwwmVQO2Lhmx/M1JBsfTGkO+mnvG1Tn1lKV6s8fP6505fLfQVgqTNGx8roJ5T5qGVclimQ7jaOIm+qnQERqGrVCiFt84ZSgX+7c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765388350; c=relaxed/simple; bh=JAxOJcxVkCMLviHeiquuA25//jeREPGXW4XBSqCrF+o=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=TrWJqsIjRTJxKqa11rL7QvuE9FqB1CE0e5HOz+LQ2qywOx+M9/mSrm9tH3W7a9KCHamgQDx8ouxyS6Jh0uwpasNZ6BasyUHOY/evjPKodhYTJJkRjhhlDNDtT57KFOu5VAIqoc1glNIUi7A0Y5gid9VSacrms3GHcTMwST2jc48= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YZUhNwfI; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YZUhNwfI" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-477770019e4so336605e9.3 for ; Wed, 10 Dec 2025 09:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765388347; x=1765993147; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=IShKfbwBJvRiRBCjSU8bZ/gtOv+/XlDreO8YWpURiiE=; b=YZUhNwfIvX0hpwN9BtqiQ+qvLLZBdDPR/NVK26CX0rAGVryjCXuVFxltQPRmC6+GYX eSZAyTuPH1ouXjRbXn7WzAROOMJtGoFNn1mMTDh93rbO0T44EYhakQb56Hl4v07OylQN bDgdzgrztSVYZUGoxeYAElMu0PZ+mxC00VjCbjCUbo1BbpE5qRhT93R1OAcQqrIM1jnA ZR/JAl7HgJ2IrUphGtyiO9dN3pyda6f3O34a7ZqJ0u5UfCyLQ+NJjTjbAh+xE/Q12a1E 8nDh10lK1U+FW+yKLd7txVqIhpWGNynRYlkMdte5ElJUH7B4w5T3kczbs0iUhlzxOcwl OZxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765388347; x=1765993147; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IShKfbwBJvRiRBCjSU8bZ/gtOv+/XlDreO8YWpURiiE=; b=RHyTsGvgigCj4Ste7M3aAZbRW5Z8fdtcAV/e5yZ6tMWFCGMDxK9X4cpa3zBDKDRsPV ieGHLakuH9HkiZ+IMXKI3JHg3JRm7YXAKWyyZNFWpUuekx8uZJyOZUl9OUCXrLqA3GMI geJSZnAxXWrzRzZEWL3wp9JcRAZpjp4j/AeOeJtHmVymHtbN+cru3Jde3z4Y09lLhsIk sVlv6De1VbYUnnKjVqxaQ+HzSIMMcjMeFuaBXhF44MwE3zTGewrWLbJZ15x/lQetwp+H Ms3d+oN+cXQGi4UYdQ/spjTi+jdTND9tSNpQ5Qex3dmAadvwHVqs4Y8fYPX8bxb4+NW4 ShZQ== X-Forwarded-Encrypted: i=1; AJvYcCWkDjKJoOrGJ3P6T9f0jrJEYYSq+xs/0e3RR/kiGeNPBtKKK9r6IoYqrovY7cgrob/ixHriWm3X7fOAxZU=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0qJBqzfbpIq2Eym0gpP9H0DJP5d6bOpy5PeeHwy3IQS6weCRw x1yPA1ookSe++omQI6DIHmMA0NyFkJOpPms0X0KwWILKg5tgvHi4Gwgc X-Gm-Gg: ASbGncs4F1xFS5oz1hlWuGc2AOmew72OLcaYaFPu+xFIn0t/f4Z6dKsrVmp3J09N9Dg RRE3Zj3FhXohrKMj+bB1iqk4Zf0pjYwttPkpnqqtzr9sdBqs5/E0YchN0R1DjTtNkJf6sqc2+U7 Vv58ZxI5rN+ga0tBuLZQPShxiM9AX2VHK5F4Ol6b4XZvAVmsO12FPB5tlv05X/mT+G4evkCkUTl aBhN1Xm3eV0suKKQ1UqPkwnrdijNROlM4SWGuqSgIdgRcRI1rKmakCcZbml8ylmkN5QKZlGQwcm rsdod7RHqlUgQ9QfkO1atIQn2M2nfUaQfTd5kZ4DDcIE6wMPfn3BRn3nQ8OUpqmSUfj6TX2n+34 0uyXTlGyzOZbjN5SLbc0WxigTX8w6bgghXoseEr6i62zbeD7LD1YXxKBlmEXUc22u6S3zBghgS3 rsyj3vhTmIj0GFCNImjFyjf3nO2pq6zWz0ZmCghvxB X-Google-Smtp-Source: AGHT+IG95T4OiqH/oWCKwKzdMhUYIl8GUdrS7486+/275Rwsiy9/UwnZum+JShbUeGP/d8ZllH6ipw== X-Received: by 2002:a05:600c:4ec6:b0:477:9cc3:7971 with SMTP id 5b1f17b1804b1-47a838438a6mr31385905e9.20.1765388346547; Wed, 10 Dec 2025 09:39:06 -0800 (PST) Received: from Ansuel-XPS24 (93-34-88-81.ip49.fastwebnet.it. [93.34.88.81]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-47a886bec80sm1176675e9.1.2025.12.10.09.39.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Dec 2025 09:39:05 -0800 (PST) From: Christian Marangi To: Andy Shevchenko , Christian Marangi , Andrew Morton , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Subject: [PATCH v3] resource: add WARN_ON_ONCE for resource_size() and document misusage Date: Wed, 10 Dec 2025 18:38:41 +0100 Message-ID: <20251210173848.30786-1-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.51.0 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="utf-8" Content-Transfer-Encoding: quoted-printable 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 be confusing 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 =3D {}; The correct way to initialize an "uninitialized" resource descriptor would be to use the DEFINE_RES macro that correctly set the start and end resource descriptior values. 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 initialized and will probably result in resource_size() returning unexpected sizes. 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. Link: https://lore.kernel.org/all/20251207215359.28895-1-ansuelsmth@gmail.c= om/T/#m990492684913c5a158ff0e5fc90697d8ad95351b Suggested-by: Ilpo J=C3=A4rvinen Signed-off-by: Christian Marangi --- Changes v3: - More wording fixup - Use asm/bug.h Changes v2: - Improve commit description - Improve kdoc - Add bug.h include include/linux/ioport.h | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index e8b2d6aa4013..d3e837eb8760 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -14,6 +14,9 @@ #include #include #include + +#include + /* * Resources are tree-like, allowing * nesting etc.. @@ -286,8 +289,30 @@ static inline void resource_set_range(struct resource = *res, resource_set_size(res, size); } =20 +/** + * resource_size - Get the size of the resource + * @res: Resource descriptor + * + * Calculated size is derived from @res end and start values following + * the logic: + * + * end - start + 1 + * + * The caller MUST ensure @res is properly initialized. + * + * Do NOT use resource_size() as a proxy for checking validity of @res or + * for checking if @res is in a resource tree (use flags checks or call + * resource_assigned() instead). + * + * Passing a @res descriptor with zeroed flags will produce a WARN + * signaling a misusage of this helper and probably a BUG in the user of + * this helper. + * + * Return: size of the resource. + */ static inline resource_size_t resource_size(const struct resource *res) { + WARN_ON_ONCE(!res->flags); return res->end - res->start + 1; } static inline unsigned long resource_type(const struct resource *res) --=20 2.51.0