On Mon, Aug 10, 2020 at 05:19:42PM +0300, Dima Stepanov wrote: > From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > > commit 51c48b310183ab6ba5419edfc6a8de889cc04521 upstream. > > pci_bridge_check_ranges() determines whether a bridge supports the optional > I/O and prefetchable memory windows and sets the flag bits in the bridge > resources. This *could* be done once during enumeration except that the > resource allocation code completely clears the flag bits, e.g., in the > pci_assign_unassigned_bridge_resources() path. > > The problem with pci_bridge_check_ranges() in the resource allocation path > is that we may allocate resources after devices have been claimed by > drivers, and pci_bridge_check_ranges() *changes* the window registers to > determine whether they're writable. This may break concurrent accesses to > devices behind the bridge. > > Add a new pci_read_bridge_windows() to determine whether a bridge supports > the optional windows, call it once during enumeration, remember the > results, and change pci_bridge_check_ranges() so it doesn't touch the > bridge windows but sets the flag bits based on those remembered results. > > Link: https://lore.kernel.org/linux-pci/1506151482-113560-1-git-send-email-wangzhou1@xxxxxxxxxxxxx > Link: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02082.html > Reported-by: Yandong Xu <xuyandong2@xxxxxxxxxx> > Tested-by: Yandong Xu <xuyandong2@xxxxxxxxxx> > Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > Cc: Michael S. Tsirkin <mst@xxxxxxxxxx> > Cc: Sagi Grimberg <sagi@xxxxxxxxxxx> > Cc: Ofer Hayut <ofer@xxxxxxxxxxxxxxxxx> > Cc: Roy Shterman <roys@xxxxxxxxxxxxxxxxx> > Cc: Keith Busch <keith.busch@xxxxxxxxx> > Cc: Zhou Wang <wangzhou1@xxxxxxxxxxxxx> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208371 > Signed-off-by: Dima Stepanov <dimastep@xxxxxxxxxxxxxx> > --- > drivers/pci/probe.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++++ > drivers/pci/setup-bus.c | 45 ++++-------------------------------------- > include/linux/pci.h | 3 +++ > 3 files changed, 59 insertions(+), 41 deletions(-) Why is this now needed in 4.19.y? What changed to require it and what prevents the users from just using 5.4.y instead? A bit of an explaination when backporting patches that are not obvious "fixes" to much older kernels is always appreciated :) thanks, greg k-h