In support of detecting whether a resource might have been been claimed,
report the parent to the walk_iomem_res_desc() callback. For example,
the ACPI HMAT parser publishes "hmem" platform devices per target range.
However, if the HMAT is disabled / missing a fallback driver can attach
devices to the raw memory ranges as a fallback if it sees unclaimed /
orphan "Soft Reserved" resources in the resource tree.
Otherwise, find_next_iomem_res() returns a resource with garbage data
from the stack allocation in __walk_iomem_res_desc() for the res->parent
field.
Cc: Jason Gunthorpe <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Wei Yang <[email protected]>
Cc: Tom Lendacky <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
---
kernel/resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/resource.c b/kernel/resource.c
index 76036a41143b..6e22e312fd55 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -386,6 +386,7 @@ static int find_next_iomem_res(resource_size_t start, resource_size_t end,
res->end = min(end, p->end);
res->flags = p->flags;
res->desc = p->desc;
+ res->parent = p->parent;
}
read_unlock(&resource_lock);
On 3/2/20 4:20 PM, Dan Williams wrote:
> In support of detecting whether a resource might have been been claimed,
> report the parent to the walk_iomem_res_desc() callback. For example,
> the ACPI HMAT parser publishes "hmem" platform devices per target range.
> However, if the HMAT is disabled / missing a fallback driver can attach
> devices to the raw memory ranges as a fallback if it sees unclaimed /
> orphan "Soft Reserved" resources in the resource tree.
>
> Otherwise, find_next_iomem_res() returns a resource with garbage data
> from the stack allocation in __walk_iomem_res_desc() for the res->parent
> field.
Just wondering if we shouldn't just copy the complete resource struct and
just override the start and end values? That way, if some code in the
future wants to look at sibling or child values, another change isn't needed.
Just a thought.
Thanks,
Tom
>
> Cc: Jason Gunthorpe <[email protected]>
> Cc: Dave Hansen <[email protected]>
> Cc: Wei Yang <[email protected]>
> Cc: Tom Lendacky <[email protected]>
> Signed-off-by: Dan Williams <[email protected]>
> ---
> kernel/resource.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 76036a41143b..6e22e312fd55 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -386,6 +386,7 @@ static int find_next_iomem_res(resource_size_t start, resource_size_t end,
> res->end = min(end, p->end);
> res->flags = p->flags;
> res->desc = p->desc;
> + res->parent = p->parent;
> }
>
> read_unlock(&resource_lock);
>
On Thu, Mar 5, 2020 at 6:42 AM Tom Lendacky <[email protected]> wrote:
>
> On 3/2/20 4:20 PM, Dan Williams wrote:
> > In support of detecting whether a resource might have been been claimed,
> > report the parent to the walk_iomem_res_desc() callback. For example,
> > the ACPI HMAT parser publishes "hmem" platform devices per target range.
> > However, if the HMAT is disabled / missing a fallback driver can attach
> > devices to the raw memory ranges as a fallback if it sees unclaimed /
> > orphan "Soft Reserved" resources in the resource tree.
> >
> > Otherwise, find_next_iomem_res() returns a resource with garbage data
> > from the stack allocation in __walk_iomem_res_desc() for the res->parent
> > field.
>
> Just wondering if we shouldn't just copy the complete resource struct and
> just override the start and end values? That way, if some code in the
> future wants to look at sibling or child values, another change isn't needed.
>
> Just a thought.
Thanks for taking a look. I think it's ok to come update this again if
that need arises.