From nobody Fri Oct 3 23:02:05 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (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 300F91A01BF; Fri, 22 Aug 2025 12:34:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755866065; cv=none; b=XcMJKugVgzVW1GCre7LqqSqesFkg1nLb99PFXDsAt62TFzc4BF5Mwagfgfkc8yVTvMHbbRIMuK6G+929xV9PZ/KDqPvtKwW9Jh6pnJbHRcqFxR1H91ne426ckWOY9iW5PDiAdrYGbXV23uKuUNxfNnpYjI8Pid4PZ/7aexFSAyo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755866065; c=relaxed/simple; bh=K44nXn+2YaS890q9Kr4KiGxSXGC4Gk3/nni3cyZeO20=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=i3cgOQBcpvIvNSmt3Uxf/OCMabE7tY2je7thAQHllrTQiVnds1tLnrKnrPUFr1dra+0rn6NJYMPgwvbx6t7jCvTU1LlyKTsNeKrhwwPJyZop0pi4pmXiRgK/lIzsk+vLNcGaeQWzbzL69Hj/AuSZnvvTSgamYTcYQd6oiptMgak= 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=jkHPu2Dt; arc=none smtp.client-ip=192.198.163.7 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="jkHPu2Dt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1755866064; x=1787402064; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=K44nXn+2YaS890q9Kr4KiGxSXGC4Gk3/nni3cyZeO20=; b=jkHPu2DtRbvPNjdZMiow8CzdgQ7tCzDA3jRzwQcSUjhZJN9aD3n/W/7S ckuovbWFqRiBtxYd86GwmFZ2oKOSkUBVcB/GpVypOjhQwAGtgtQq1n3T4 TmgnpNVfSpuDKDnTvsZPvTsgDzSPzjNMgIdfgKwwxIdYtXzXgh/ccqthR Pd8qG0tbSHEGKEnH/HDLlSGsQU8srwkiUTl/hYswWiATleaXAMYj0ndes S5bjQoXKNrMR8DC5kXC70KXl19N/xFKWWByJYPMncRaFfE6aAmDgCHRcz wLXxLV04wFI0Ww+HtVTN+1v+9YSQqdPnkzjndK/276nkFejiQB1HZCHr6 g==; X-CSE-ConnectionGUID: hZaSJLUiTaWsJKEn+i3aqw== X-CSE-MsgGUID: 9MmdMTotT7eLHuSvXBEH9Q== X-IronPort-AV: E=McAfee;i="6800,10657,11529"; a="83587595" X-IronPort-AV: E=Sophos;i="6.17,309,1747724400"; d="scan'208";a="83587595" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 05:34:23 -0700 X-CSE-ConnectionGUID: 0Ym8VL6/Q8mIrmePHOE0sg== X-CSE-MsgGUID: yMUY+Y8/S2Wkw0ZFT2b9Rw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,309,1747724400"; d="scan'208";a="192360830" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.115]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 05:34:19 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: Bjorn Helgaas , linux-pci@vger.kernel.org, D Scott Phillips , Rio Liu , Tudor Ambarus , Markus Elfring , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Christian=20K=C3=B6nig?= , stable@vger.kernel.org Subject: [PATCH v3 1/3] PCI: Relaxed tail alignment should never increase min_align Date: Fri, 22 Aug 2025 15:33:57 +0300 Message-Id: <20250822123359.16305-2-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250822123359.16305-1-ilpo.jarvinen@linux.intel.com> References: <20250822123359.16305-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 Liu Closes: https://lore.kernel.org/all/o2bL8MtD_40-lf8GlslTw-AZpUPzm8nmfCnJKvS= 8RQ3NOzOW1uq1dVCEfRpUjJ2i7G2WjfQhk2IWZ7oGp-7G-jXN4qOdtnyOcjRR0PZWK5I=3D@r26= .me/ Tested-by: Rio Liu 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 7853ac6999e2..527f0479e983 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(relaxed_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 Fri Oct 3 23:02:05 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 E7BDF2FAC05; Fri, 22 Aug 2025 12:34:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755866085; cv=none; b=kDLvAAuOLyVc9HtcfBCgpEBdOo1K5i6povsEhBSisfbjjndsrdYngMH7lcQ/NS8GH/my9Ixx4pzEbX7ORtR7kLpyCYfAkAso2RpRWUVKjZjSO6tmxKYwegSJXvDNWXOZdVBgup8XBYW0EqOhY83n5Gt50BpzJyq/nfAfwqn+Rak= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755866085; c=relaxed/simple; bh=cL0GCb3tG/kam3FoIPck5xj4eap4KV0y2insekhYb5Q=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=aHxAgDSCYaCcd33ga6PoxVzdfzMEidweUcjZM5uWCS70ri2wUCRFSMBOwrLo+M+EUcPXfnde2Vp89kB/DkM5HKlulNTyQXhhutrsaur9SnROeEU3aADokseWQBEjhWbWpU6X4/DqIDsmkgBaX0tFdMNiq2qRgGArTFStPDmbtTw= 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=V4kr01dl; arc=none smtp.client-ip=192.198.163.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="V4kr01dl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1755866084; x=1787402084; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=cL0GCb3tG/kam3FoIPck5xj4eap4KV0y2insekhYb5Q=; b=V4kr01dlFI7nmhXbl9CljjFrmBOr3cjbbVFMxVYAUYPPTfyLWwx2R8ap 5NbT+P8ogJGNcCAt2Fyr6NCyIUS37CXoTNwxBXtykRqebZ7maaI9xpd1d 8oCZERYkabvcYSA+TYvem6LN00eYhhNA0KnrEDyyZSJBmvSiqThNK4S1A V+QYb3gWhblIfUD79Q5Kr85qQkG0byXh+gFnhhC/h8hGvcs8O2aUiiXD3 Ect0snkGoVVFA1F1ESqJJfr+wON5/QHea3m/TWmLbqLS7gEj9IKfnyz5C vvSVLowX82mkaaTROwmG5qbViLlMw8wRg609Yhkat6CzXOMwum6PteMhT A==; X-CSE-ConnectionGUID: hSXIj0ewRvSkt9nIgQKL2Q== X-CSE-MsgGUID: eurPymRXQwyH9FFQZVJc4g== X-IronPort-AV: E=McAfee;i="6800,10657,11529"; a="45742838" X-IronPort-AV: E=Sophos;i="6.17,309,1747724400"; d="scan'208";a="45742838" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 05:34:34 -0700 X-CSE-ConnectionGUID: BdhYEKszSaOvtvJ/or1ovg== X-CSE-MsgGUID: JebbR26uRN+jgj1ITw7dOQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,309,1747724400"; d="scan'208";a="168599384" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.115]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 05:34:30 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: Bjorn Helgaas , linux-pci@vger.kernel.org, D Scott Phillips , Rio Liu , Tudor Ambarus , Markus Elfring , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Christian=20K=C3=B6nig?= , stable@vger.kernel.org Subject: [PATCH v3 2/3] PCI: Fix pdev_resources_assignable() disparity Date: Fri, 22 Aug 2025 15:33:58 +0300 Message-Id: <20250822123359.16305-3-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250822123359.16305-1-ilpo.jarvinen@linux.intel.com> References: <20250822123359.16305-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 Closes: https://lore.kernel.org/all/5f103643-5e1c-43c6-b8fe-9617d3b5447c@li= naro.org/ Signed-off-by: Ilpo J=C3=A4rvinen Cc: --- 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 527f0479e983..df5aec46c29d 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 From nobody Fri Oct 3 23:02:05 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 1F5AA2FB972; Fri, 22 Aug 2025 12:34:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755866087; cv=none; b=aW8KXQxWZvAHUHTSh2xoXQdNWAlgrD5dvtmTd2NGM0IXsPgohzZUgqINTIbJkw61RQuTaCDjywBOokySQf6GatBNQh3fkLpNjJ2kpztyOKl/FW9b2+lC3i1H/4uZU/Q/tw4xVtUumvUXJRIe85yvaPlkFuVjGurkY/XuURC1C+k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755866087; c=relaxed/simple; bh=np5jOecE4nT+dASmiZntjLqhj8X27reIWBQkTw8zbAk=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=hzKba1zJeLPSHYEUMlnRxB/T/SM9fQ17GC3WwOXhUDyFw8y12rTEBXIX2Z3J1U13OoN7fuYsP0NT4R+RfZdPgsIRhT8qvqPkSPWk9XRmu/msMiPoWD33FLeDYSIp8j9/xmvyXAMWng3zaf7pcsDFkoy07R7BNYhbBgcDeLd9M18= 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=PiT7c3YH; arc=none smtp.client-ip=192.198.163.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="PiT7c3YH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1755866086; x=1787402086; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=np5jOecE4nT+dASmiZntjLqhj8X27reIWBQkTw8zbAk=; b=PiT7c3YHlTKQ56xSbpvxqxcTgp5CGjYjPrcGQxccpS6XTlvc6n/7qbhX khgFzNeqoifM5XqzvU9u3zmo6f3pPUthTIhqw0RZefIbqD0kKSMhyis0I PehcSizhIeXDiIKvMZPdwZeatAFpS8vrCMbFT0QHOeXeYOysG0b7AOWQG 3y70KUjYkZk54xIX8H5SIpHZUZDtfcfbSMkmkX3aJD1/hMCGGuEqEIv5Q cfJArcQ9EMPoQUg2omNLuTNYnvh+kPp9WdscIJiojreEs3LzioOgJ/Res 6nlxKndhQSah9e/H8xvabtW7CxmHcHLPxOxKHcw0oVfMnMX3StImZDNBc g==; X-CSE-ConnectionGUID: 9vVk9gMpRdWjHEqo4+FD2Q== X-CSE-MsgGUID: 5DLEe32nSlmw2jSKSFZfYQ== X-IronPort-AV: E=McAfee;i="6800,10657,11529"; a="45742866" X-IronPort-AV: E=Sophos;i="6.17,309,1747724400"; d="scan'208";a="45742866" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 05:34:44 -0700 X-CSE-ConnectionGUID: iLW5NYiFSxe+wgYVIA9zjQ== X-CSE-MsgGUID: 5aZFHMQKTDK/Vw7+5jxfeg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,309,1747724400"; d="scan'208";a="168599441" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.115]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 05:34:40 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= To: Bjorn Helgaas , linux-pci@vger.kernel.org, D Scott Phillips , Rio Liu , Tudor Ambarus , Markus Elfring , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , linux-kernel@vger.kernel.org Cc: =?UTF-8?q?Christian=20K=C3=B6nig?= , stable@vger.kernel.org Subject: [PATCH v3 3/3] PCI: Fix failure detection during resource resize Date: Fri, 22 Aug 2025 15:33:59 +0300 Message-Id: <20250822123359.16305-4-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250822123359.16305-1-ilpo.jarvinen@linux.intel.com> References: <20250822123359.16305-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 Since the commit 96336ec70264 ("PCI: Perform reset_resource() and build fail list in sync") the failed list is always built and returned to let the caller decide what to do with the failures. The caller may want to retry resource fitting and assignment and before that can happen, the resources should be restored to their original state (a reset effectively clears the struct resource), which requires returning them on the failed list so that the original state remains stored in the associated struct pci_dev_resource. Resource resizing is different from the ordinary resource fitting and assignment in that it only considers part of the resources. This means failures for other resource types are not relevant at all and should be ignored. As resize doesn't unassign such unrelated resources, those resource ending up into the failed list implies assignment of that resource must have failed before resize too. The check in pci_reassign_bridge_resources() to decide if the whole assignment is successful, however, is based on list emptiness which will cause false negatives when the failed list has resources with an unrelated type. If the failed list is not empty, call pci_required_resource_failed() and extend it to be able to filter on specific resource types too (if provided). Calling pci_required_resource_failed() at this point is slightly problematic because the resource itself is reset when the failed list is constructed in __assign_resources_sorted(). As a result, pci_resource_is_optional() does not have access to the original resource flags. This could be worked around by restoring and re-reseting the resource around the call to pci_resource_is_optional(), however, it shouldn't cause issue as resource resizing is meant for 64-bit prefetchable resources according to Christian K=C3=B6nig (see the Link which unfortunately doesn't point directly to Christian's reply because lore didn't store that email at all). Fixes: 96336ec70264 ("PCI: Perform reset_resource() and build fail list in = sync") Link: https://lore.kernel.org/all/c5d1b5d8-8669-5572-75a7-0b480f581ac1@linu= x.intel.com/ Reported-by: D Scott Phillips Closes: https://lore.kernel.org/all/86plf0lgit.fsf@scott-ph-mail.amperecomp= uting.com/ Tested-by: D Scott Phillips Signed-off-by: Ilpo J=C3=A4rvinen Reviewed-by: D Scott Phillips Cc: Christian K=C3=B6nig Cc: --- drivers/pci/setup-bus.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index df5aec46c29d..def29506700e 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -28,6 +28,10 @@ #include #include "pci.h" =20 +#define PCI_RES_TYPE_MASK \ + (IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH |\ + IORESOURCE_MEM_64) + unsigned int pci_flags; EXPORT_SYMBOL_GPL(pci_flags); =20 @@ -384,13 +388,19 @@ static bool pci_need_to_release(unsigned long mask, s= truct resource *res) } =20 /* Return: @true if assignment of a required resource failed. */ -static bool pci_required_resource_failed(struct list_head *fail_head) +static bool pci_required_resource_failed(struct list_head *fail_head, + unsigned long type) { struct pci_dev_resource *fail_res; =20 + type &=3D PCI_RES_TYPE_MASK; + list_for_each_entry(fail_res, fail_head, list) { int idx =3D pci_resource_num(fail_res->dev, fail_res->res); =20 + if (type && (fail_res->flags & PCI_RES_TYPE_MASK) !=3D type) + continue; + if (!pci_resource_is_optional(fail_res->dev, idx)) return true; } @@ -504,7 +514,7 @@ static void __assign_resources_sorted(struct list_head = *head, } =20 /* Without realloc_head and only optional fails, nothing more to do. */ - if (!pci_required_resource_failed(&local_fail_head) && + if (!pci_required_resource_failed(&local_fail_head, 0) && list_empty(realloc_head)) { list_for_each_entry(save_res, &save_head, list) { struct resource *res =3D save_res->res; @@ -1708,10 +1718,6 @@ static void __pci_bridge_assign_resources(const stru= ct pci_dev *bridge, } } =20 -#define PCI_RES_TYPE_MASK \ - (IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH |\ - IORESOURCE_MEM_64) - static void pci_bridge_release_resources(struct pci_bus *bus, unsigned long type) { @@ -2450,8 +2456,12 @@ int pci_reassign_bridge_resources(struct pci_dev *br= idge, unsigned long type) free_list(&added); =20 if (!list_empty(&failed)) { - ret =3D -ENOSPC; - goto cleanup; + if (pci_required_resource_failed(&failed, type)) { + ret =3D -ENOSPC; + goto cleanup; + } + /* Only resources with unrelated types failed (again) */ + free_list(&failed); } =20 list_for_each_entry(dev_res, &saved, list) { --=20 2.39.5