linux-kernel - Re: [PATCH 05/23] PCI: Remove old_size limit from bridge window sizing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260127224256.GA384149@bhelgaas>
Date: Tue, 27 Jan 2026 16:42:56 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Simon Richter <Simon.Richter@...yros.de>
Subject: Re: [PATCH 05/23] PCI: Remove old_size limit from bridge window
 sizing

On Tue, Jan 27, 2026 at 01:39:39PM +0200, Ilpo Järvinen wrote:
> On Mon, 26 Jan 2026, Bjorn Helgaas wrote:
> > On Mon, Jan 26, 2026 at 11:16:01AM -0600, Bjorn Helgaas wrote:
> > > On Fri, Dec 19, 2025 at 07:40:18PM +0200, Ilpo Järvinen wrote:
> > > > calculate_memsize() applies lower bound to the resource size before
> > > > aligning the resource size making it impossible to shrink bridge window
> > > > resources. I've not found any justification for this lower bound and
> > > > nothing indicated it was to work around some HW issue.
> ...

> > > > Reported-by: Simon Richter <Simon.Richter@...yros.de>
> > > 
> > > I guess this report was
> > > https://lore.kernel.org/r/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/,
> > > right?
> > 
> > And this looks like a regression in v6.18 that will persist in v6.19.
> > 
> > Is that the right thing?  I wonder if we should move these first five
> > patches to pci/for-linus so they land in v6.19?
> 
> Fine with me if you want to do that. Stable people would pick things that 
> landing in the merge window into Linus' tree anyway so the difference 
> isn't going to be that huge.
> 
> Patch 3 is the scariest of the changes and is not strictly even a fix 
> (without it there are two parallel alignment approaches though which 
> wastes some stack space). It will have some impact on resource allocation 
> when the new approach is enabled for everything were as previously the new 
> sizing/alignment approached were only used in the relative safe haven of 
> relaxed tail alignment cases; though in my tests, surprisingly few changes 
> did occur.
> 
> The patch 4 too is on the edge, if you want to push that through for-linus 
> (but it's not dangerous and is useful for complex topos).
> 
> I don't know how you are going to handle the pci/resource branch then 
> though as I expect the rest of the series to not apply cleanly without 
> those 5 patches.

OK, I'll leave it as-is, with all of this on pci/resource for v6.20.

I was concerned that lots of people would trip over the issue Simon
reported, but I don't see many reports on the web.

Bjorn