From nobody Fri Dec 19 11:48:17 2025 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 865142D6E4A for ; Sun, 7 Dec 2025 21:54:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765144475; cv=none; b=iVEXoVdGcCWtTKLfmtoMspr8LOZxJuBXuN1oY6cryifuNS7caBvxGSQSbpL8nQ/o0GtyI4Uz62PIRJM8ljYfI4A/seIuMdaZyRdmR/Ii+BExVSY6e/uhD7LAT3O1N09y/WMiYBNKOI8cK1xCPotzDEdoSTsSCFX0vp6TI4IRPvQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765144475; c=relaxed/simple; bh=AdhRAFHV9c2s18NEnbHQC+HaN48HeN5SJALQidN+AdI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Zh8mgxOqFm58BNUStzYxHxmvaJHDO+qK5eGt1FMjA0Cii8XX5Akwhm1RkeeWrmjRjSRSB1SswWo9Z6/VNp9GEPIv2Px9NvhpxEl4INdcugv4GeEiSaH1CSVyuIIv6Nzxn0NVmJsyaCHwpNK5Lh6+XpD5mxnsa8B2hRiRPDb1Dvg= 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=e58rC0Fj; arc=none smtp.client-ip=209.85.221.53 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="e58rC0Fj" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-42e2e47be25so1947434f8f.2 for ; Sun, 07 Dec 2025 13:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765144472; x=1765749272; 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=seehIcUlZDs6BYGs0hU80TpGfT+I0h0bj/3G3OxXFOc=; b=e58rC0FjZNRNGg4gba37YWd1MBARdCbA45NQcYaPUX//28cD2YZYq/iPOQR6k/rLlI fLnx6RkEuvQj7kaBZtrYOS7StXEoOIVh38e36cxH7ZSTZn8uV2r6HtQKPI9S8n2QRzcJ FJDPy4ATpfzzf5SAFBkpjBMxj2erOfH3T0jdlmK1jd33T/4LQyq9xxX2zvSjiO5GbZaM LvaWs10QeChafFWr1RxxlB9U7rLl+RX0BTMH5lC965im6glmssH4vE4KbdxRIrHY9QIy HeVgfCCvTuHhidkIbuMcg+6mCN0laNAon2JmSNQxwXz/ssBsE/0DQDVIHQ0n/dnZo+1V S6hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765144472; x=1765749272; 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=seehIcUlZDs6BYGs0hU80TpGfT+I0h0bj/3G3OxXFOc=; b=I3YIZHB5c3nUAnZcdiAsX8VxChWIwEANltmMNJwIn/1CbRpOIYtook3Col5c6pt+qz GDpw9h9UsZkAQHPpE+cnS43ncbfRksn7cwhDJ8WnS5vzmqu2/Bc1EOzBo9AzEmlLA26w 04GG2HGqdF6Kb/aeywOYu1tGoLutCsWvQH1eCnjiEC62cr8FvqPeWG6k78z00HFE8vP3 Wlgv31Z4pq2PHcilMh4RadJPGdRIcCZuklpoYDIQuFyC4rWXGecETg0Sj+7oOp/dR5NH XjmAJvy/5fyKJboHwrd2wOFGlchLrfsc732+2RLLtpHHMmZjmZK86wX8HNavsnbP7dlk LJPg== X-Forwarded-Encrypted: i=1; AJvYcCW4jxhwGgwotHyem9Ma++PuOk6abTwXAL0K4/06Q9zax6MSEkNYLkzN7PrvhhhqhD45EECjnMYrHD5LJwo=@vger.kernel.org X-Gm-Message-State: AOJu0YyMqfUo/JEQnfjj4nFcc0b0VTg3miVpDjwe852xOVuvUvjjUq+Q +rbDcOLH3DKV1LIgFVLDy2MWAnTM4IiuW+AWEbKb3cvCUG7xzdtZYhSB X-Gm-Gg: ASbGnctsGgyLbywAAWwvzeqrFcYKPUh3HE7HSfULUPWJsTMd4Jgeyy8OQZNa+JmfOpZ rjHud7Gkw2TSl1MJDpjoGRMVRaRXTIqQ+ZFRpkHE1UH01AIAWqbmffqA2oYLjzKZk7Do1rmeJsn KeUyb/+sPST4Tp2/uxK0MsD2boFZtby67oQCpsxyOfFma4gbLw5wiXQPV1Zk520ayq1cQ2L4aKR PwKPyufAH6s+34B9znCcC5zWdi1TtvUN44QATxGf8ma59MBgqPAawODjqrpm0itlOReuHuoZ+2i EU3lpDhPolRbDlpFewaKy8yP/Byl871H2onvsB3drkeahtLZ/Ie5FL55Hc8vOLBZWAfbTUvRvb/ Sp47ovh3f98J1H7SDbkNRb0pdWhiKWuasbqn503PlcS/D+HurPKV+KrrtP0SBPJ8BX6hAsfQn3y /y4GjSexugLKubLBbb5iDvmtUQfONaxoHOoPhj9fe6 X-Google-Smtp-Source: AGHT+IFBmBH0JVJNS1MBHESeReeFzpHfm00YM7XF4JRXD6VjlzpUx3cmNN5Uc6+oYaxIStG9Ci/t2A== X-Received: by 2002:a5d:588d:0:b0:42b:40b5:e683 with SMTP id ffacd0b85a97d-42f89f0be4cmr6892463f8f.23.1765144471660; Sun, 07 Dec 2025 13:54:31 -0800 (PST) Received: from Ansuel-XPS24 (93-34-88-81.ip49.fastwebnet.it. [93.34.88.81]) by smtp.googlemail.com with ESMTPSA id ffacd0b85a97d-42f7d331a4fsm24327184f8f.33.2025.12.07.13.54.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Dec 2025 13:54:30 -0800 (PST) From: Christian Marangi To: Christian Marangi , Andrew Morton , Dan Williams , Andy Shevchenko , Jonathan Cameron , Magnus Damm , linux-kernel@vger.kernel.org Cc: "Rob Herring (Arm)" , 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 Message-ID: <20251207215359.28895-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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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) Cc: stable@vger.kernel.org Fixes: 1a4e564b7db9 ("resource: add resource_size()") Signed-off-by: Christian Marangi --- 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, =20 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) --=20 2.51.0