From nobody Mon Dec 1 22:06:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 ED76C31ED8C; Fri, 28 Nov 2025 11:50:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330644; cv=none; b=IYAnwDHdMqykuvr1TlmSZYtK/6mUjbskG92XxegN/55g6ABYyG3hW2AxocLlFaxxT2MeAUc//C5DtHSdWGLsvBCUP/t7T/SvVFX+Sd36SGfJagh6wewCHWdD0qhKuZfOCrSEHNMmivqWCLOICgSE3m4CXglu5t9VJNOz6YwyhM4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330644; c=relaxed/simple; bh=w1nn91iVTHk8FXTeuhEl2nHnCcO17OkcU6tsnZL2XZ0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=TSZ45Guv00TCVIiNN7Nsr1GI6G1/R8H/IQwzwk9hvwCKj35b/8u+0mHh12c/mAZcx17QSZU7NuR+pe0nAb0qc8eN3d5HI2+F7yKABllxwetjM6M90AFMwPh5e/VA5pbntJ0gjm4ZjOdQ5pxqVpBE0FauYTRC8NcHrKHK1HHC6So= 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=RgD22dyc; arc=none smtp.client-ip=192.198.163.9 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="RgD22dyc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764330643; x=1795866643; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=w1nn91iVTHk8FXTeuhEl2nHnCcO17OkcU6tsnZL2XZ0=; b=RgD22dychSr9i3VSdFp48CMkCozHsy/ruaLvwIZqGbkJE0IUEFC6YYok aAOuNEqTwVGzpXDm8ywdrQPB1fW+XuURurZs2FGwZ6wTPGVYs6Zth91vu fbfF7Zr3Di49WPA1kVh9hsBgvL41hqWBQjxstu4PthTwBRW+pZ1vfJts2 UZ9CAOhXYBzJ1GtOLELb+Ntc2iH/PCIuw5nrC7+EGbRy/dcYyn5wAUubd Kw6TvH10s2NGVfHNr05fI8ip9QqLa+bIuUZCgQQXWGAMZUYFMrl3DYUlH 1l7of39wS1fNgjMpVfmWPlhQhiqhceEqKJ78fAUTavsDoQR3zfFQq95ZD Q==; X-CSE-ConnectionGUID: FcvEgb8mTdqt0Ui7MH6yoQ== X-CSE-MsgGUID: F34uvkkRTOS0CG4r3aH0kA== X-IronPort-AV: E=McAfee;i="6800,10657,11626"; a="77050427" X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="77050427" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:50:42 -0800 X-CSE-ConnectionGUID: J2ZKRN4+TMilXtqfppKkmQ== X-CSE-MsgGUID: +8SrmPYaT2CAx3ngTkl49Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="224149171" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.229]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:50:38 -0800 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: linux-pci@vger.kernel.org, Bjorn Helgaas , Benjamin Herrenschmidt , Wei Yang , =?UTF-8?q?Malte=20Schr=C3=B6der?= , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , stable@vger.kernel.org Subject: [PATCH 1/4] PCI: Fix bridge window alignment with optional resources Date: Fri, 28 Nov 2025 13:50:18 +0200 Message-Id: <20251128115021.4287-2-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.com> References: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.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="utf-8" Content-Transfer-Encoding: quoted-printable pbus_size_mem() has two alignments, one for required resources in min_align and another in add_align that takes account optional resources. The add_align is applied to the bridge window through the realloc_head list. It can happen, however, that add_align is larger than min_align but calculated size1 and size0 are equal due to extra tailroom (e.g., hotplug reservation, tail alignment), and therefore no entry is created to the realloc_head list. Without the bridge appearing in the realloc head, add_align is lost when pbus_size_mem() returns. The problem is visible in this log for 0000:05:00.0 which lacks add_size ... add_align ... line that would indicate it was added into the realloc_head list: pci 0000:05:00.0: PCI bridge to [bus 06-16] ... pci 0000:06:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 07] req= uires relaxed alignment rules pci 0000:06:06.0: bridge window [mem 0x00100000-0x001fffff] to [bus 0a] req= uires relaxed alignment rules pci 0000:06:07.0: bridge window [mem 0x00100000-0x003fffff] to [bus 0b] req= uires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x00800000-0x00ffffff 64bit pref] to [= bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] = requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] = requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] = add_size 100000 add_align 1000000 pci 0000:06:0c.0: bridge window [mem 0x00100000-0x001fffff] to [bus 15] req= uires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] req= uires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] req= uires relaxed alignment rules pci 0000:05:00.0: bridge window [mem 0xd4800000-0xd97fffff]: assigned pci 0000:05:00.0: bridge window [mem 0x1060000000-0x10607fffff 64bit pref]:= assigned pci 0000:06:08.0: bridge window [mem size 0x04900000]: can't assign; no spa= ce pci 0000:06:08.0: bridge window [mem size 0x04900000]: failed to assign While this bug itself seems old, it has likely become more visible after the relaxed tail alignment that does not grossly overestimate the size needed for the bridge window. Make sure add_align > min_align too results in adding an entry into the realloc head list. In addition, add handling to the cases where add_size is zero while only alignment differs. Fixes: d74b9027a4da ("PCI: Consider additional PF's IOV BAR alignment in si= zing and assigning") Reported-by: Malte Schr=C3=B6der Tested-by: Malte Schr=C3=B6der Signed-off-by: Ilpo J=C3=A4rvinen Cc: stable@vger.kernel.org --- drivers/pci/setup-bus.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 4a8735b275e4..70d021ffb486 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -14,6 +14,7 @@ * tighter packing. Prefetchable range support. */ =20 +#include #include #include #include @@ -452,7 +453,7 @@ static void reassign_resources_sorted(struct list_head = *realloc_head, "%s %pR: ignoring failure in optional allocation\n", res_name, res); } - } else if (add_size > 0) { + } else if (add_size > 0 || !IS_ALIGNED(res->start, align)) { res->flags |=3D add_res->flags & (IORESOURCE_STARTALIGN|IORESOURCE_SIZEALIGN); if (pci_reassign_resource(dev, idx, add_size, align)) @@ -1438,12 +1439,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsi= gned long type, =20 resource_set_range(b_res, min_align, size0); b_res->flags |=3D IORESOURCE_STARTALIGN; - if (bus->self && size1 > size0 && realloc_head) { + if (bus->self && realloc_head && (size1 > size0 || add_align > min_align)= ) { b_res->flags &=3D ~IORESOURCE_DISABLED; - add_to_list(realloc_head, bus->self, b_res, size1-size0, add_align); + add_size =3D size1 > size0 ? size1 - size0 : 0; + add_to_list(realloc_head, bus->self, b_res, add_size, add_align); pci_info(bus->self, "bridge window %pR to %pR add_size %llx add_align %l= lx\n", b_res, &bus->busn_res, - (unsigned long long) (size1 - size0), + (unsigned long long) add_size, (unsigned long long) add_align); } } --=20 2.39.5 From nobody Mon Dec 1 22:06:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 8A16B2F1FD3; Fri, 28 Nov 2025 11:50:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330654; cv=none; b=BFuhpXkCKjj5DTmBGX31ADCz5MglT9TaikeLtW4G9+0urDl356LuqFZ+9AdVKFm3DOQdBehpJm1cRghxYVbbPlvROXebsxXkpFQDsLwPvZZJlQP/fiEDDnglPaZAK+jKtp+0zkg2c82jvmwhy5DMWhe62NpxnSoh/MYYU16su2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330654; c=relaxed/simple; bh=J3EqdeNEnlMVvV/TxElDoaTOZx5Kx11YfAHlUJndQpQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=bbyx23wkNp1bc8XJOfiy8rodAxwmUKmro0RzCMMAO6aakYIkU9f13Xl3yE4nszeRn8ppxXbD8Kvh7r1Cn4JAb8yJP7+UsMS626/SZseDhNn9SNFq+T2kvaTNI5oQ/OBGaE0MaioWJdRcljs8J+2q6Gtyzl/jjoLOdNyKre3s9gE= 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=f9h3ippw; arc=none smtp.client-ip=192.198.163.15 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="f9h3ippw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764330652; x=1795866652; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=J3EqdeNEnlMVvV/TxElDoaTOZx5Kx11YfAHlUJndQpQ=; b=f9h3ippw1mcJkoTJUR1tx/wKeeHj0kfyyFsKOPWKUzhD1fQnQA23FXhK 4sohkeF5oy6u0hJM6aTwTknQds5MnnwAvwz7RagboCkbVuUREjv3giACs rjlWL6d4IJqJ7A3yzD6gZtQhlkajqvgo+cUSJphQXfbjJn6Nb7rOBc7aH PklDONF3Es/1Z4UrgU28GNVEmjfjk7TCuSO0XBzdic8RsBiCjcuq4/8cL Y7yQhAnhQcuR1nff6sLJhHdIeRaCUi6vooQFFGTZtpCdEK4Dvgwz5ErZO fuh+be/w17R1PlS7A/RqyZldIPmzXRb1XTXFTTS2kASeQD3Jts4HGcRpI A==; X-CSE-ConnectionGUID: ycel80B9Q+eXgtUnMD1pzQ== X-CSE-MsgGUID: tGgTyPxSS3uHpNxS1huAPw== X-IronPort-AV: E=McAfee;i="6800,10657,11626"; a="66437133" X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="66437133" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:50:51 -0800 X-CSE-ConnectionGUID: Y67/q+RZRqqSJrm6e/T0qQ== X-CSE-MsgGUID: ado3sna4RGKRGYinYh2Tzg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="230725425" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.229]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:50:48 -0800 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: linux-pci@vger.kernel.org, Bjorn Helgaas , Benjamin Herrenschmidt , Wei Yang , =?UTF-8?q?Malte=20Schr=C3=B6der?= , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , stable@vger.kernel.org Subject: [PATCH 2/4] PCI: Rewrite bridge window head alignment function Date: Fri, 28 Nov 2025 13:50:19 +0200 Message-Id: <20251128115021.4287-3-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.com> References: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.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="utf-8" Content-Transfer-Encoding: quoted-printable The calculation of bridge window head alignment is done by calculate_mem_align() [*]. With the default bridge window alignment, it is used for both head and tail alignment. The selected head alignment does not always result in tight-fitting resources (gap at d4f00000-d4ffffff): d4800000-dbffffff : PCI Bus 0000:06 d4800000-d48fffff : PCI Bus 0000:07 d4800000-d4803fff : 0000:07:00.0 d4800000-d4803fff : nvme d4900000-d49fffff : PCI Bus 0000:0a d4900000-d490ffff : 0000:0a:00.0 d4900000-d490ffff : r8169 d4910000-d4913fff : 0000:0a:00.0 d4a00000-d4cfffff : PCI Bus 0000:0b d4a00000-d4bfffff : 0000:0b:00.0 d4a00000-d4bfffff : 0000:0b:00.0 d4c00000-d4c07fff : 0000:0b:00.0 d4d00000-d4dfffff : PCI Bus 0000:15 d4d00000-d4d07fff : 0000:15:00.0 d4d00000-d4d07fff : xhci-hcd d4e00000-d4efffff : PCI Bus 0000:16 d4e00000-d4e7ffff : 0000:16:00.0 d4e80000-d4e803ff : 0000:16:00.0 d4e80000-d4e803ff : ahci d5000000-dbffffff : PCI Bus 0000:0c This has not been caused problems (for years) with the default bridge window tail alignment that grossly over-estimates the required tail alignment leaving more tail room than necessary. With the introduction of relaxed tail alignment that leaves no extra tail room whatsoever, any gaps will immediately turn into assignment failures. Introduce head alignment calculation that ensures no gaps are left and apply the new approach when using relaxed alignment. ([*] I don't understand the algorithm in calculate_mem_align().) Fixes: 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, = parisc) [2/2]") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D220775 Reported-by: Malte Schr=C3=B6der Tested-by: Malte Schr=C3=B6der Signed-off-by: Ilpo J=C3=A4rvinen Cc: stable@vger.kernel.org --- Little annoyingly, there's difference in what aligns array contains between the legacy alignment approach (which I dare not to touch as I really don't understand what the algorithm tries to do) and this new head aligment algorithm, both consuming stack space. After making the new approach the only available approach in the follow-up patch, only one array remains (however, that follow-up change is also somewhat riskier when it comes to regressions). That being said, the new head alignment could work with the same aligns array as the legacy approach, it just won't necessarily produce an optimal (the smallest possible) head alignment when if (r_size <=3D align) condition is used. Just let me know if that approach is preferred (to save some stack space). --- drivers/pci/setup-bus.c | 53 ++++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 70d021ffb486..93f6b0750174 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1224,6 +1224,45 @@ static inline resource_size_t calculate_mem_align(re= source_size_t *aligns, return min_align; } =20 +/* + * Calculate bridge window head alignment that leaves no gaps in between + * resources. + */ +static resource_size_t calculate_head_align(resource_size_t *aligns, + int max_order) +{ + resource_size_t head_align =3D 1; + resource_size_t remainder =3D 0; + int order; + + /* Take the largest alignment as the starting point. */ + head_align <<=3D max_order + __ffs(SZ_1M); + + for (order =3D max_order - 1; order >=3D 0; order--) { + resource_size_t align1 =3D 1; + + align1 <<=3D order + __ffs(SZ_1M); + + /* + * Account smaller resources with alignment < max_order that + * could be used to fill head room if alignment less than + * max_order is used. + */ + remainder +=3D aligns[order]; + + /* + * Test if head fill is enough to satisfy the alignment of + * the larger resources after reducing the alignment. + */ + while ((head_align > align1) && (remainder >=3D head_align / 2)) { + head_align /=3D 2; + remainder -=3D head_align; + } + } + + return head_align; +} + /** * pbus_upstream_space_available - Check no upstream resource limits alloc= ation * @bus: The bus @@ -1311,13 +1350,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsi= gned long type, { struct pci_dev *dev; resource_size_t min_align, win_align, align, size, size0, size1 =3D 0; - resource_size_t aligns[28]; /* Alignments from 1MB to 128TB */ + resource_size_t aligns[28] =3D {}; /* Alignments from 1MB to 128TB */ + resource_size_t aligns2[28] =3D {};/* Alignments from 1MB to 128TB */ int order, max_order; struct resource *b_res =3D pbus_select_window_for_type(bus, type); resource_size_t children_add_size =3D 0; resource_size_t children_add_align =3D 0; resource_size_t add_align =3D 0; - resource_size_t relaxed_align; resource_size_t old_size; =20 if (!b_res) @@ -1327,7 +1366,6 @@ static void pbus_size_mem(struct pci_bus *bus, unsign= ed long type, if (b_res->parent) return; =20 - memset(aligns, 0, sizeof(aligns)); max_order =3D 0; size =3D 0; =20 @@ -1378,6 +1416,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsign= ed long type, */ if (r_size <=3D align) aligns[order] +=3D align; + aligns2[order] +=3D align; if (order > max_order) max_order =3D order; =20 @@ -1402,9 +1441,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsign= ed long type, =20 if (bus->self && size0 && !pbus_upstream_space_available(bus, b_res, size0, min_align)) { - relaxed_align =3D 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align =3D max(relaxed_align, win_align); - min_align =3D min(min_align, relaxed_align); + min_align =3D calculate_head_align(aligns2, max_order); size0 =3D calculate_memsize(size, min_size, 0, 0, old_size, win_align); resource_set_range(b_res, min_align, size0); pci_info(bus->self, "bridge window %pR to %pR requires relaxed alignment= rules\n", @@ -1418,9 +1455,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsign= ed long type, =20 if (bus->self && size1 && !pbus_upstream_space_available(bus, b_res, size1, add_align)) { - relaxed_align =3D 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align =3D max(relaxed_align, win_align); - min_align =3D min(min_align, relaxed_align); + min_align =3D calculate_head_align(aligns2, max_order); size1 =3D calculate_memsize(size, min_size, add_size, children_add_size, old_size, win_align); pci_info(bus->self, --=20 2.39.5 From nobody Mon Dec 1 22:06:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 3331D2F1FD3; Fri, 28 Nov 2025 11:51:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330663; cv=none; b=JhNFcw0PzpMiZSeYzw/Oh44lXL2DxGwqUg+hgd5w2JLpJ8ByLiJ3E/s7yBxtb0kmnaGh/4Kei2StDZkqegg4n8KOp4GIsNPhfooHSn2cQW/SaTpvNTPy4u+6K7gUHe5j/eI+0JKMce9r9aYDWaE2zlvZRp2aKdNe7A7ucTt72zk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330663; c=relaxed/simple; bh=p1K7iuDhai8jqvLoc236iWaHbkXWlAAYEFEd5ZuRe0c=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=dGX8hNDTzLlKnUWkSr8WjcJINLQXmwxHpFNMLjxR5+oh80DxcatXG5BIOrX9MSiJZLZWpOO8kNi8gCEcRgjmTWfIkCOZy4x6PsXuUthUdPaIEMPrvzXfLPbHnbHkvFpxQ2nTuA41jPibXaFtp8CEB+ipjVaFP6NfHPlLwfO8x88= 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=D9cc+tEc; arc=none smtp.client-ip=192.198.163.15 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="D9cc+tEc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764330661; x=1795866661; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=p1K7iuDhai8jqvLoc236iWaHbkXWlAAYEFEd5ZuRe0c=; b=D9cc+tEc6zhslz2F5qDTkwpVRlejZ2EkI7014gj3vMNQ6tpmm/xrDIoS 5Np+ORPdyEvWP1m36JSPFuSf/Be+rsViDXuGu5jDM0SzLqHjNR+tPWC0e Hj45YByTOadaMV7f8NmsiTi3KpgUFwIJrt0l0m6e6Z2TGGRi+mU6Wnx/4 xfXpBWDGa9enyaK6M/ClImLZ8AxpD1AZjF7YnIChtVOD1NORg8iD9S9r9 /MySDBoDijY6z2A8RzMp51Hy/VjvW/O+6SCXNPoMyyoGwL+xX45DlqQeS OpcVDW/9hGtXuFMBc5PPEFaaAXmakbdgrKwaVUT+/QbOgzn6fkQ6RrZnJ A==; X-CSE-ConnectionGUID: mEm0Lx7JRAunKmPKZ4TDCQ== X-CSE-MsgGUID: v4BrHCx1TYOs532Ukg6Erw== X-IronPort-AV: E=McAfee;i="6800,10657,11626"; a="66437147" X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="66437147" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:51:00 -0800 X-CSE-ConnectionGUID: n1W1ctP5TxqRhXIEMC7iiA== X-CSE-MsgGUID: UaNtbjQ/T36y9w/W5OjahA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="230725467" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.229]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:50:57 -0800 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: linux-pci@vger.kernel.org, Bjorn Helgaas , Benjamin Herrenschmidt , Wei Yang , =?UTF-8?q?Malte=20Schr=C3=B6der?= , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Subject: [PATCH 3/4] PCI: Stop over-estimating bridge window size Date: Fri, 28 Nov 2025 13:50:20 +0200 Message-Id: <20251128115021.4287-4-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.com> References: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.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="utf-8" Content-Transfer-Encoding: quoted-printable New way to calculate the bridge window head alignment produces tight-fit, that is, it does not leave any gaps between the resources. Similarly, relaxed tail alignment does not leave extra tail room. Start to use bridge window calculation that does not over-estimate the size of the required window. pbus_upstream_space_available() can be removed. Tested-by: Malte Schr=C3=B6der Signed-off-by: Ilpo J=C3=A4rvinen --- This is relatively risky change when it comes to regressions. In static setups things are likely okay (in my own testing, many systems had zero differences or just one bridge window among many that was shrunk some, no resulting any issue). In cases where resources are discovered later (hotplug, pwrctrl, delayed enumeration, etc.) the difference might matter more, if a reduced size results in resources not fitting. Those might be addressable by provinding pci=3Dhp*size=3Dxx parameter which is the canonic= al way to prepare for unknown, instead of relying on artifacts of the bridge window alignment algorithm. drivers/pci/setup-bus.c | 97 +++-------------------------------------- 1 file changed, 5 insertions(+), 92 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 93f6b0750174..6f4bb2d19cc1 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1263,68 +1263,6 @@ static resource_size_t calculate_head_align(resource= _size_t *aligns, return head_align; } =20 -/** - * pbus_upstream_space_available - Check no upstream resource limits alloc= ation - * @bus: The bus - * @res: The resource to help select the correct bridge window - * @size: The size required from the bridge window - * @align: Required alignment for the resource - * - * Check that @size can fit inside the upstream bridge resources that are - * already assigned. Select the upstream bridge window based on the type of - * @res. - * - * Return: %true if enough space is available on all assigned upstream - * resources. - */ -static bool pbus_upstream_space_available(struct pci_bus *bus, - struct resource *res, - resource_size_t size, - resource_size_t align) -{ - struct resource_constraint constraint =3D { - .max =3D RESOURCE_SIZE_MAX, - .align =3D align, - }; - struct pci_bus *downstream =3D bus; - - while ((bus =3D bus->parent)) { - if (pci_is_root_bus(bus)) - break; - - res =3D pbus_select_window(bus, res); - if (!res) - return false; - if (!res->parent) - continue; - - if (resource_size(res) >=3D size) { - struct resource gap =3D {}; - - if (find_resource_space(res, &gap, size, &constraint) =3D=3D 0) { - gap.flags =3D res->flags; - pci_dbg(bus->self, - "Assigned bridge window %pR to %pR free space at %pR\n", - res, &bus->busn_res, &gap); - return true; - } - } - - if (bus->self) { - pci_info(bus->self, - "Assigned bridge window %pR to %pR cannot fit 0x%llx required for %s = bridging to %pR\n", - res, &bus->busn_res, - (unsigned long long)size, - pci_name(downstream->self), - &downstream->busn_res); - } - - return false; - } - - return true; -} - /** * pbus_size_mem() - Size the memory window of a given bus * @@ -1351,7 +1289,6 @@ static void pbus_size_mem(struct pci_bus *bus, unsign= ed long type, struct pci_dev *dev; resource_size_t min_align, win_align, align, size, size0, size1 =3D 0; resource_size_t aligns[28] =3D {}; /* Alignments from 1MB to 128TB */ - resource_size_t aligns2[28] =3D {};/* Alignments from 1MB to 128TB */ int order, max_order; struct resource *b_res =3D pbus_select_window_for_type(bus, type); resource_size_t children_add_size =3D 0; @@ -1410,13 +1347,8 @@ static void pbus_size_mem(struct pci_bus *bus, unsig= ned long type, continue; } size +=3D max(r_size, align); - /* - * Exclude ranges with size > align from calculation of - * the alignment. - */ - if (r_size <=3D align) - aligns[order] +=3D align; - aligns2[order] +=3D align; + + aligns[order] +=3D align; if (order > max_order) max_order =3D order; =20 @@ -1430,38 +1362,19 @@ static void pbus_size_mem(struct pci_bus *bus, unsi= gned long type, =20 old_size =3D resource_size(b_res); win_align =3D window_alignment(bus, b_res->flags); - min_align =3D calculate_mem_align(aligns, max_order); + min_align =3D calculate_head_align(aligns, max_order); min_align =3D max(min_align, win_align); - size0 =3D calculate_memsize(size, min_size, 0, 0, old_size, min_align); + size0 =3D calculate_memsize(size, min_size, 0, 0, old_size, win_align); =20 if (size0) { resource_set_range(b_res, min_align, size0); b_res->flags &=3D ~IORESOURCE_DISABLED; } =20 - if (bus->self && size0 && - !pbus_upstream_space_available(bus, b_res, size0, min_align)) { - min_align =3D calculate_head_align(aligns2, max_order); - size0 =3D calculate_memsize(size, min_size, 0, 0, old_size, win_align); - resource_set_range(b_res, min_align, size0); - pci_info(bus->self, "bridge window %pR to %pR requires relaxed alignment= rules\n", - b_res, &bus->busn_res); - } - if (realloc_head && (add_size > 0 || children_add_size > 0)) { add_align =3D max(min_align, add_align); size1 =3D calculate_memsize(size, min_size, add_size, children_add_size, - old_size, add_align); - - if (bus->self && size1 && - !pbus_upstream_space_available(bus, b_res, size1, add_align)) { - min_align =3D calculate_head_align(aligns2, max_order); - size1 =3D calculate_memsize(size, min_size, add_size, children_add_size, - old_size, win_align); - pci_info(bus->self, - "bridge window %pR to %pR requires relaxed alignment rules\n", - b_res, &bus->busn_res); - } + old_size, win_align); } =20 if (!size0 && !size1) { --=20 2.39.5 From nobody Mon Dec 1 22:06:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 89C333254B3; Fri, 28 Nov 2025 11:51:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330673; cv=none; b=XFS5i4pspJ9xtGC17wRfenRG0dOBwt+UVckZksPFGi/CtbPefW2KzcZlEygzDcHNvMfMuhUcW5+yWkECLB9TPolrayNIHMfAQ06xbqy0BFYbjGa9e63/I+AOV77r5JTEPRYiPS7XNOWmFs6eU9ZI5K9phVukn5szggboRzJqqv0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764330673; c=relaxed/simple; bh=f7e+ax9Ru72J3uJsHwCnUx8Tp2bSDJ1UUdD+RCIJtcs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=Oauy3tRBfgs8cTNbMAlV08di4mGYjlphsW2cCdopa+B9sWtgPisEqhHKRU+69iEvUnLw8/F7/uZNHfYu5a4R6jlT7zzoEZFeGVeq3bhpmjBkcdF31GwDc+xfrGL65AAhbDHeRTikinkUkP+Xr3fuoolF0K9z1orLgKI+gAzvyRw= 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=jYZNRsHO; arc=none smtp.client-ip=192.198.163.15 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="jYZNRsHO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764330671; x=1795866671; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=f7e+ax9Ru72J3uJsHwCnUx8Tp2bSDJ1UUdD+RCIJtcs=; b=jYZNRsHOtSF0AFrTc6OaPsAVkCiCgzHNjM7ZVzZQESeSs17F9OIfogA4 L4phaBlVv7xabg9YdTURLVTbRx1ha/jPEbDFMZ1J3VIWmY4bbNMliAcyb qKd39idQcAqkWVLn4AVcR9yYwLPJ1T0BGCkYyJMf8f2j6r39pgYvVP1oJ yE6OWBi3X2Vueo8VgPCfmo3Z21xP4vN23757xTpXQxCxVnBR8BtxbupLv ZErkrIGYC3OVRB33Fisk8ZJKykNAP+B5V+159XqWGfz2XPp3tnpsrHe15 7Z9b4WQgVXH5lrrcAudCmyTi+ScPAs/sD2Y29KR/mPdhoHij77YnzxcEF A==; X-CSE-ConnectionGUID: 1uI9/OnRR06scdPN/W7nNQ== X-CSE-MsgGUID: OhEMi9yNR5mLzT6fv3KJoA== X-IronPort-AV: E=McAfee;i="6800,10657,11626"; a="66437159" X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="66437159" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:51:10 -0800 X-CSE-ConnectionGUID: LnbTp9DGRl+1dwxMlrpg+g== X-CSE-MsgGUID: 5HOVqoyiSyO+TzAv3Uo30g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,232,1758610800"; d="scan'208";a="230725521" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.229]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2025 03:51:07 -0800 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: linux-pci@vger.kernel.org, Bjorn Helgaas , Benjamin Herrenschmidt , Wei Yang , =?UTF-8?q?Malte=20Schr=C3=B6der?= , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Subject: [PATCH 4/4] resource: Increase MAX_IORES_LEVEL to 8 Date: Fri, 28 Nov 2025 13:50:21 +0200 Message-Id: <20251128115021.4287-5-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.com> References: <20251128115021.4287-1-ilpo.jarvinen@linux.intel.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="utf-8" Content-Transfer-Encoding: quoted-printable While debugging a PCI resource allocation issue, the resources for many nested bridges and endpoints got flattened in /proc/iomem by MAX_IORES_LEVEL that is set to 5. This made the iomem output hard to read as the visual hierarchy cues were lost. Increase MAX_IORES_LEVEL to 8 to avoid flattening PCI topologies with nested bridges so aggressively (the case in the Link has the deepest resource at level 7 so 8 looks a reasonable limit). Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D220775 Signed-off-by: Ilpo J=C3=A4rvinen --- kernel/resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/resource.c b/kernel/resource.c index b9fa2a4ce089..c5c907b3236d 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -82,7 +82,7 @@ static struct resource *next_resource(struct resource *p,= bool skip_children, =20 #ifdef CONFIG_PROC_FS =20 -enum { MAX_IORES_LEVEL =3D 5 }; +enum { MAX_IORES_LEVEL =3D 8 }; =20 static void *r_start(struct seq_file *m, loff_t *pos) __acquires(resource_lock) --=20 2.39.5