On Fri, 18 Dec 2009 13:24:41 -0800 (PST)
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> And once you do that, then using "release_resrouce()" is the wrong
> thing, since it turns into just "__release_resource()" and you notice
> that that walks the chain looking for them - which makes it pointless
> to have _another_ outer loop that walks the chain to release them!
>
> So you'd need to
>
> - move this to kernel/resource.c
>
> - do it all under 'write_lock(&resource_lock);'
>
> - stop the silly double list loop, and just do it as a single loop
> that does
>
> p = old->parent->child;
> old->parent = NULL;
> while (p) {
> struct resource *tmp = p;
> p = p->sibling;
>
> .. do whatever you do to free tmp ..
> }
>
> and it's much simpler, more efficient, has the rigth locking, and
> is in the right place.
>
> That said, it's still unclear if you can ever do this! Why would the
> PCI layer be allowed to release ACPI resources int he tree, for
> example?
>
> So I can see fixing the _implementation_ issues I have like above,
> but I'd still be nervous about the whole concept of the patch..
Yeah, if we roll all the way back up through some system resources we
could definitely get into trouble. Stopping the recursion when we hit
a bridge or host bridge may be a good enough heuristic?
Really I guess this is just a half measure. There are a whole set a
fixed resources that are children of the root address space, and we
shouldn't try to free or move them around at all (e.g. ACPI _CRS type
resources). Beyond that though it should be safe to free all the
moveable resources in a tree and try again if a leaf device can't get
its preferred allocation (the whole purpose of this series afaict).
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
