From nobody Sun Feb 8 05:47:00 2026 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 CB7AE1E8332 for ; Tue, 9 Dec 2025 15:02:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765292526; cv=none; b=PNmIkmcCXd9PsyaERBD7vH5Dp+4YHiOeuLAqqVllXrbfDE+W+zUgj/KDgUYb4A5aixog/HvUpky+vfIc5YSiYZMTT+9axs7d9RpqBhudVmXFhja7+salptCWvm3JxcO7BiLmH1QQydOePdoTRtKJBWOMp8o1a58AkPCvDInf4d0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765292526; c=relaxed/simple; bh=YSsxaJu0unobYN7sd/gzLGzlXqgcTyofSUrtfnjv4fg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=nZ9iNHeomkcWSoGUKe7yNWAfYHqLdEtiBREArN8qRqOS0ou5GObkkqiIWMKmhrcFIvdIsSs0CrjPwKKBLFIjKkVaUDwjUye5DmpGjPfm5mmM5t1RYImBe2SsOmT1sq1obz8GGpJoyo9ocm0pfoAjLzOlnL564pCJU+HcbcDzzfU= 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=eX2CHGEZ; arc=none smtp.client-ip=209.85.128.47 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="eX2CHGEZ" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-477ba2c1ca2so75006585e9.2 for ; Tue, 09 Dec 2025 07:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765292523; x=1765897323; 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=+4VilXVW2oEFjs67tFTEMF35jls+rLJ6aSz8LVZU2CA=; b=eX2CHGEZL2nPgx3HVX1sMp99rmHqk2JBcmuAu6cKuDzfrzk6YXBaD3oR8vtCQYrTFg m6ejc+pjcC4pblaBe3ri2lknupIqHoUTzkeTmD+kaWEnauIlnTgFhZpVM4eCBYnJ3+F5 nC+4Hb8oR4rK9lvFlCYmw+D3fUvoHjpuu2pcDh/FwSlHZDOkrByhD8e5EW5UsIaWeHcG C0UwAbS0kUSLv03FYaB/2Eb89Itcrgc71PVR4A/jrH4jzuSsaPS3tf7+zQcnbk4+VeuY t/3mnEBkwZKcXhQOA8Bss4aA682trwSwtmM1gGDdFQbMjLl2UZUXhBTUd3pLXubJ+a2f zK7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765292523; x=1765897323; 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=+4VilXVW2oEFjs67tFTEMF35jls+rLJ6aSz8LVZU2CA=; b=jddpN/TU7E1RUe5clkZjcokds3oNgYNN75CsBOedq4rdFM107CvKJFPAT2mv0iPDUe FuLZfV1kqETDiWs8GI7XRIq6vai65jMCyZJjSRAe3B52cGsK+9ahqphGvYO48XD/M/t8 oRIQBogoO7UwxTb/SJ67u4wQ2XWV6RS9XPs1bARNyV71PK6sN3OWC5LHtIYUvQk5RieA h5/aIqjten9VZmhPCZJpbiw29jLHLA7CXhZAy+q7RHeDKRi5d4qq8UnOsr3dKZh5agL8 fafY1PyDM5fdzNcIigsp0dD+SL+gL7Nlkwdey4iB6yPpdDfHCI+PLRRfMEjKSNuCtqqd hnLQ== X-Forwarded-Encrypted: i=1; AJvYcCVnw7CYZzgmtaWOPIznPb4V33k2rg/kjQHFCTI1GIDICKqhiVqvLrFpCPOy633o+g4ePTNYT1hLXXI/X+8=@vger.kernel.org X-Gm-Message-State: AOJu0YzEdgBwawS2O1tCC2bic6BOrEVMnLYCqFxfCYjoTR6D1tlOMBSJ 8w7HaRnxKfxpg3a9SXNVE/kGqViPTceKhiZHSNRPUXqQrqz2bLzDAXQA X-Gm-Gg: ASbGnctyiOG3qYTdDL/Oa37vHj1Cf7x4pi1DoJMND+6qd7k2ab9gBDs1IO5MrCkfkn8 TbaevvQuxZKaxsh2fU8HbXfYER6UMC0h1FsbMZxy6rLXkZ5ir0aFgscrstHe7icuUrcy/3iEIDq gU4C/flMUoeVKSrNGuY6J2g9IpnsCjEXnSBG+5VDWbjb8eoHSSvRSe9IgPWV2+XyTeEWQgWsFhr XMsqH31DopiRA5eb6nG5Hl4r94kqMmZCxicdmkTKTLa0K8JMr4/lp/D7zEN2mGRDeb6CVe5SHUp M6jdQ0ahE43gTytBMbMQbmplITOD7ttEg/UHtwRgnm3FCWi4ni8rzh8PG2SQfHjqRHtwTcTPLOX VoFXhwO7Fgs+VdD3OZ3fR4xoIOw3B2Vf79X43DPs9ouQN330jxFZMdUDPI7PB6GLoUhLHzS5HDs woNcjN3Hldq0Ak0sUDNo2PuzUmNrKUewNOD4MF6A7L X-Google-Smtp-Source: AGHT+IEScdm+LJgeHvAhzvh+hDFdxJ7fWY96+nSwefzdlXsZtRCHSL5VOoOPh0LV2gA4fvfGptGVHA== X-Received: by 2002:a05:600c:1c07:b0:477:9cc3:7971 with SMTP id 5b1f17b1804b1-47939e2464fmr125179915e9.20.1765292522722; Tue, 09 Dec 2025 07:02:02 -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-47a7d9b5c73sm20283095e9.6.2025.12.09.07.02.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Dec 2025 07:02:02 -0800 (PST) From: Christian Marangi To: Andrew Morton , Andy Shevchenko , Christian Marangi , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Subject: [PATCH v2] resource: add WARN_ON_ONCE for resource_size() and document misusage Date: Tue, 9 Dec 2025 16:01:40 +0100 Message-ID: <20251209150150.9525-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 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 =3D {}; 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. 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 v2: - Improve commit description - Improve kdoc - Add bug.h include include/linux/ioport.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index e8b2d6aa4013..c087e49e1927 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -11,6 +11,7 @@ =20 #ifndef __ASSEMBLY__ #include +#include #include #include #include @@ -286,8 +287,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 + * + * This MUST be used ONLY with correctly initialized @res descriptor. + * + * 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). + * + * The caller MUST ensure @res is properly initialized, 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