On Mon, Jun 3, 2024 at 12:24 AM Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote: > > On Sun, 2 Jun 2024, Andy Shevchenko wrote: > > > On Fri, May 31, 2024 at 02:31:45PM -0700, Chia-I Wu wrote: > > > On Fri, May 31, 2024 at 1:57 AM Andy Shevchenko < > > > andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote: > > > > ... > > > > > > P.S> I'm not so sure about this change. It needs a thoroughly testing, esp. > > > > in PCI case. Cc'ing to Ilpo. > > > > > What's special about PCI? > > > > PCI, due to its nature, may rebuild resources either by shrinking or expanding > > of the entire subtree after the PCI bridge in question. And this may happen at > > run-time due to hotplug support. But I'm not a deep expert in this area, Ilpo > > knows much more than me. > > There is code which clearly tries to do expanding resource but that > usually fails to work as intended because of a parent resource whose size > is fixed because it's already assigned. > > Some other code might block shrinking too under certain conditions. > > This area would need to be reworked in PCI core but it's massive and > scary looking change. Given the nature of this change (skip checking against children when the parent does not match), unless a child resource can exceed its parent resource, I don't think this change affects correctness. The walk does not hold the resource lock outside of find_next_iomem_res(). Updating the tree while the walk is in progress has always been a bit ill-defined. The patch does not change that (but it might change the timing a bit). I can export __walk_iomem_res_desc() and write some unit tests against it. Would that be enough to justify this change? > > -- > i.
