From nobody Sat Oct 11 12:13:28 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 A187A28C5AB; Tue, 10 Jun 2025 10:21:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749550883; cv=none; b=GNPxKgGIaTBT632Q2ATSOu/EFKu8vVlH/RP2ZtkhTawq+b+CzKxiRzoOBlZhFXfPozaLFWhgOqc6S5A17ONssnvSzK5uSyVMoQlrrQ21LMUszCfa+ULBjAQF9MmnFn3ZLSTBaEyMO0ruqu2kITxwrVvdIEtSVE8u54U83PiuX9U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749550883; c=relaxed/simple; bh=qcdDHfnbKy3u6503ewGEShCVDp3LAsaF1Jy2SSxNrpM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=U7FVpgkPVMKHDgZ93Bn4I9t9zjhbWb1mwzKFnCXEvIhpx5eZt8YUK5x14kgYqzaoBDxTNy9Q8vBGk4LtiCXJ4aPrvmDj+ZS6C5XxXXmNlsgTZk3HWCyPTHd38uKgrsYpyM6qM4E1rZkztb98ebHb7NbyXGidb3qmDeojky1AX28= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=KqH/fSHL; arc=none smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="KqH/fSHL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1749550882; x=1781086882; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=qcdDHfnbKy3u6503ewGEShCVDp3LAsaF1Jy2SSxNrpM=; b=KqH/fSHLB4K4rGtrVA0p0OOg1bPi3/ElGiLnB/5RGjifz5DvvmaIvybk aImysMV67RX7Jg5APKYd/HPKhDi1p8NiMuaopDyfXK6uU3X9bgdoz1sGW vmUOKpuST74U5VtZEfSjVncT30heMJjR5vucwXFJ0bUf8GsCN5B5XM6+o LxrJWlM5dcofnz6PesIDb3b4PYtYAFtXZ3hrLU18H/Q/npBHAsOHUftO+ /Xp75uIFaN2Yi0Zj4yac0N0gOC5t9YtZ8kXmnwMu4KPO5dng0SfAZOz92 VvpC/pVZLLl5sdL3mjzseHGotePVHleKsU4bt0fcCG1Ri8to48RANGdjQ w==; X-CSE-ConnectionGUID: MTOvO12iSgWTIs48YxtU9Q== X-CSE-MsgGUID: iuu3TfE4Qd64Dm4BWbP3qQ== X-IronPort-AV: E=McAfee;i="6800,10657,11459"; a="51739092" X-IronPort-AV: E=Sophos;i="6.16,224,1744095600"; d="scan'208";a="51739092" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2025 03:21:22 -0700 X-CSE-ConnectionGUID: tkD/4BfORo+gfxtv07x4ZA== X-CSE-MsgGUID: QjMvb63cTXGtE8bbKUoO3Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,224,1744095600"; d="scan'208";a="147370217" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.196]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2025 03:21:18 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: Bjorn Helgaas , linux-pci@vger.kernel.org, Tudor Ambarus , Rio , =?UTF-8?q?Krzysztof=20Wilczy=C5=84ski?= , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Subject: [PATCH 1/2] PCI: Relaxed tail alignment should never increase min_align Date: Tue, 10 Jun 2025 13:21:00 +0300 Message-Id: <20250610102101.6496-2-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250610102101.6496-1-ilpo.jarvinen@linux.intel.com> References: <20250610102101.6496-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 When using relaxed tail alignment for the bridge window, pbus_size_mem() also tries to minimize min_align, which can under certain scenarios end up increasing min_align from that found by calculate_mem_align(). Ensure min_align is not increased by the relaxed tail alignment. Eventually, it would be better to add calculate_relaxed_head_align() similar to calculate_mem_align() which finds out what alignment can be used for the head without introducing any gaps into the bridge window to give flexibility on head address too. But that looks relatively complex algorithm so it requires much more testing than fixing the immediate problem causing a regression. Fixes: 67f9085596ee ("PCI: Allow relaxed bridge window tail sizing for opti= onal resources") Reported-by: Rio Tested-by: Rio Signed-off-by: Ilpo J=C3=A4rvinen Cc: --- drivers/pci/setup-bus.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 07c3d021a47e..f90d49cd07da 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1169,6 +1169,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigne= d long mask, 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; =20 if (!b_res) return -ENOSPC; @@ -1246,8 +1247,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigne= d long mask, if (bus->self && size0 && !pbus_upstream_space_available(bus, mask | IORESOURCE_PREFETCH, type, size0, min_align)) { - min_align =3D 1ULL << (max_order + __ffs(SZ_1M)); - min_align =3D max(min_align, win_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); size0 =3D calculate_memsize(size, min_size, 0, 0, resource_size(b_res), = win_align); pci_info(bus->self, "bridge window %pR to %pR requires relaxed alignment= rules\n", b_res, &bus->busn_res); @@ -1261,8 +1263,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigne= d long mask, if (bus->self && size1 && !pbus_upstream_space_available(bus, mask | IORESOURCE_PREFETCH, type, size1, add_align)) { - min_align =3D 1ULL << (max_order + __ffs(SZ_1M)); - min_align =3D max(min_align, win_align); + relaxed_align =3D 1ULL << (max_order + __ffs(SZ_1M)); + relaxed_align =3D max(min_align, win_align); + min_align =3D min(min_align, relaxed_align); size1 =3D calculate_memsize(size, min_size, add_size, children_add_size, resource_size(b_res), win_align); pci_info(bus->self, --=20 2.39.5 From nobody Sat Oct 11 12:13:28 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 F31F728C5AB; Tue, 10 Jun 2025 10:21:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749550893; cv=none; b=eWrq5lWVCORrL9C2SvjVrIDQYdYHU4seNgXpaLDAcUwbuQNx34rRzRABmdU4IxNxbpr1UTi26o9EVoKyuEDOf+6jhSK7K8Gr/yoFZeMPk335jZBzlOjtqllG4pyh8bsnatVmkjAR1bcQWkf2dOhayfg1U8wxruuPldICtVNtbqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749550893; c=relaxed/simple; bh=+j8zMJW2Wcl191iL6HqEJHAtauDOyM2xYMzu/jk0I2g=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=Elg2VP880OH7nt3I/dghybeyVcNMRbRIHxEMiIhdruOmVXQGN3koyeK8USRowTmMXjXFn2YBe/r6TnrlLCaPSdBiyLqCN0WVlaqxuqBlzPYuusnrCZKLofW96Gj9ODBioB1TiYYmhz/A3/6WQFUOBWzhinCqrX6sZ1B5VAm7fLk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=GGIES0IX; arc=none smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="GGIES0IX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1749550892; x=1781086892; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+j8zMJW2Wcl191iL6HqEJHAtauDOyM2xYMzu/jk0I2g=; b=GGIES0IXyyhoQqYeSbE/3AZyjdK+8RaSPAhq2IPISwNXZyTX6k7cEJMw skcwIcDCn13OCnl9SAhc9i0fLcjXWQ/xiPlRApBTrIw/kMlfdTRjUNDF6 0Ooc7U/Jb7FEqnm/T/DU0wPnkQg83Ip/hHF7D8L4W0aqBWodt48B2lJN6 BGESh6j0JgXS2uiZUiMQEm0CW8tuQFqZ6h9GUN/n7gb4TcdwrBxjdw2C8 AYq8UFjl5OfWxy6aG54p6qHDWjZc5UvSUKAF6OQXvoiigTVAGMNADph2B f8omGFJMVoCF4KJ7kkXm9Bhi0Mg9+YxpVuyXLcyVL07rP28sw7tbN3Ygs Q==; X-CSE-ConnectionGUID: Ho7Z4CxaReuR4N0IFYS8qQ== X-CSE-MsgGUID: M915R6yIQuaZvm3/Uz20oA== X-IronPort-AV: E=McAfee;i="6800,10657,11459"; a="51739106" X-IronPort-AV: E=Sophos;i="6.16,224,1744095600"; d="scan'208";a="51739106" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2025 03:21:32 -0700 X-CSE-ConnectionGUID: 5HoJXnS4SZGzW5uZ3skH8g== X-CSE-MsgGUID: 1mkblKhkQTugaNQT0+OXJA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,224,1744095600"; d="scan'208";a="147370287" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.196]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2025 03:21:29 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: Bjorn Helgaas , linux-pci@vger.kernel.org, Tudor Ambarus , Rio , =?UTF-8?q?Krzysztof=20Wilczy=C5=84ski?= , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Subject: [PATCH 2/2] PCI: Fix pdev_resources_assignable() disparity Date: Tue, 10 Jun 2025 13:21:01 +0300 Message-Id: <20250610102101.6496-3-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250610102101.6496-1-ilpo.jarvinen@linux.intel.com> References: <20250610102101.6496-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 pdev_sort_resources() uses pdev_resources_assignable() helper to decide if device's resources cannot be assigned. pbus_size_mem(), on the other hand, does not do the same check. This could lead into a situation where a resource ends up on realloc_head list but is not on the head list, which is turn prevents emptying the resource from the realloc_head list in __assign_resources_sorted(). A non-empty realloc_head is unacceptable because it triggers an internal sanity check as show in this log with a device that has class 0 (PCI_CLASS_NOT_DEFINED): pci 0001:01:00.0: [144d:a5a5] type 00 class 0x000000 PCIe Endpoint pci 0001:01:00.0: BAR 0 [mem 0x00000000-0x000fffff 64bit] pci 0001:01:00.0: ROM [mem 0x00000000-0x0000ffff pref] pci 0001:01:00.0: enabling Extended Tags pci 0001:01:00.0: PME# supported from D0 D3hot D3cold pci 0001:01:00.0: 15.752 Gb/s available PCIe bandwidth, limited by 8.0 GT/s= PCIe x2 link at 0001:00:00.0 (capable of 31.506 Gb/s with 16.0 GT/s PCIe x= 2 link) pcieport 0001:00:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 01= -ff] add_size 100000 add_align 100000 pcieport 0001:00:00.0: bridge window [mem 0x40000000-0x401fffff]: assigned Reported-by: Tudor Ambarus ------------[ cut here ]------------ kernel BUG at drivers/pci/setup-bus.c:2532! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP ... Call trace: pci_assign_unassigned_bus_resources+0x110/0x114 (P) pci_rescan_bus+0x28/0x48 Use pdev_resources_assignable() also within pbus_size_mem() to skip processing of non-assignable resources which removes the disparity in between what resources pdev_sort_resources() and pbus_size_mem() consider. As non-assignable resources are no longer processed, they are not added to the realloc_head list, thus the sanity check no longer triggers. This disparity problem is very old but only now became apparent after the commit 2499f5348431 ("PCI: Rework optional resource handling") that made the ROM resources optional when calculating bridge window sizes which required adding the resource to the realloc_head list. Previously, bridge windows were just sized larger than necessary. Fixes: 2499f5348431 ("PCI: Rework optional resource handling") Reported-by: Tudor Ambarus Signed-off-by: Ilpo J=C3=A4rvinen Cc: --- The reporter was perhaps not happy with this fix as behavior of PCI core isn't identical after this fix even if this patch fixes the problem on the PCI core side which causes the internal sanity check to fire. It seems that in the reporter's case, an out-of-tree driver was involved that performed things and made assumptions a driver should not do in its probe function such as assuming a bridge window is assigned even if there are not child resources to be put into it (the child device in reporter's case doesn't have a valid class and gets therefore skipped by the resource fitting/assignment): https://lore.kernel.org/all/bd579412-d07c-476d-8932-55c1f69adc9f@linaro.org/ In other words, the out-of-tree driver relies on the disparity in the PCI core's resource fitting code which is now eliminated by this fix. drivers/pci/setup-bus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index f90d49cd07da..24863d8d0053 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1191,6 +1191,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigne= d long mask, resource_size_t r_size; =20 if (r->parent || (r->flags & IORESOURCE_PCI_FIXED) || + !pdev_resources_assignable(dev) || ((r->flags & mask) !=3D type && (r->flags & mask) !=3D type2 && (r->flags & mask) !=3D type3)) --=20 2.39.5