* [PATCH] base/node.c: initialize the accessor list before registering
@ 2023-10-30 4:42 Gregory Price
2023-10-31 6:03 ` Greg KH
0 siblings, 1 reply; 3+ messages in thread
From: Gregory Price @ 2023-10-30 4:42 UTC (permalink / raw)
To: linux-kernel; +Cc: gregkh, rafael, Gregory Price
The current code registers the node as available in the node array
before initializing the accessor list. This makes it so that
anything which might access the accessor list as a result of
allocations will cause an undefined memory access.
In one example, an extension to access hmat data during interleave
caused this undefined access as a result of a bulk allocation
that occurs during node initialization but before the accessor
list is initialized.
Initialize the accessor list before making the node generally
available to the global system.
Signed-off-by: Gregory Price <gregory.price@memverge.com>
---
drivers/base/node.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 493d533f8375..4d588f4658c8 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -868,11 +868,15 @@ int __register_one_node(int nid)
{
int error;
int cpu;
+ struct node *node;
- node_devices[nid] = kzalloc(sizeof(struct node), GFP_KERNEL);
- if (!node_devices[nid])
+ node = kzalloc(sizeof(struct node), GFP_KERNEL);
+ if (!node)
return -ENOMEM;
+ INIT_LIST_HEAD(&node->access_list);
+ node_devices[nid] = node;
+
error = register_node(node_devices[nid], nid);
/* link cpu under this node */
@@ -881,7 +885,6 @@ int __register_one_node(int nid)
register_cpu_under_node(cpu, nid);
}
- INIT_LIST_HEAD(&node_devices[nid]->access_list);
node_init_caches(nid);
return error;
--
2.39.1
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] base/node.c: initialize the accessor list before registering
2023-10-30 4:42 [PATCH] base/node.c: initialize the accessor list before registering Gregory Price
@ 2023-10-31 6:03 ` Greg KH
2023-10-31 4:58 ` Gregory Price
0 siblings, 1 reply; 3+ messages in thread
From: Greg KH @ 2023-10-31 6:03 UTC (permalink / raw)
To: Gregory Price; +Cc: linux-kernel, rafael, Gregory Price
On Mon, Oct 30, 2023 at 12:42:39AM -0400, Gregory Price wrote:
> The current code registers the node as available in the node array
> before initializing the accessor list. This makes it so that
> anything which might access the accessor list as a result of
> allocations will cause an undefined memory access.
>
> In one example, an extension to access hmat data during interleave
> caused this undefined access as a result of a bulk allocation
> that occurs during node initialization but before the accessor
> list is initialized.
Is this an in-kernel driver that causes this problem?
>
> Initialize the accessor list before making the node generally
> available to the global system.
>
> Signed-off-by: Gregory Price <gregory.price@memverge.com>
What commit id does this fix?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] base/node.c: initialize the accessor list before registering
2023-10-31 6:03 ` Greg KH
@ 2023-10-31 4:58 ` Gregory Price
0 siblings, 0 replies; 3+ messages in thread
From: Gregory Price @ 2023-10-31 4:58 UTC (permalink / raw)
To: Greg KH; +Cc: Gregory Price, linux-kernel, rafael
On Tue, Oct 31, 2023 at 07:03:17AM +0100, Greg KH wrote:
> On Mon, Oct 30, 2023 at 12:42:39AM -0400, Gregory Price wrote:
> > The current code registers the node as available in the node array
> > before initializing the accessor list. This makes it so that
> > anything which might access the accessor list as a result of
> > allocations will cause an undefined memory access.
> >
> > In one example, an extension to access hmat data during interleave
> > caused this undefined access as a result of a bulk allocation
> > that occurs during node initialization but before the accessor
> > list is initialized.
>
> Is this an in-kernel driver that causes this problem?
>
I discovered this why testing an RFC:
https://lore.kernel.org/linux-mm/ZUCCoCRS3cohf9OE@memverge.com/T/#t
However I noticed that there are two exposed interfaces which may
allow a caller to hit the unitialized accessor list. I haven't
explicitly demonstrated this, though.
1) register_memory_node_under_compute_node
2) node_set_perf_attrs
Since `register_node` calls into device_register and inevitably hits
allocators, it seems like fully initializing the node struct before
going off into the aether was appropriate.
> >
> > Initialize the accessor list before making the node generally
> > available to the global system.
> >
> > Signed-off-by: Gregory Price <gregory.price@memverge.com>
>
> What commit id does this fix?
>
Sorry:
Fixes: 08d9dbe72b1f ("node: Link memory nodes to their compute nodes")
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-10-31 17:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-30 4:42 [PATCH] base/node.c: initialize the accessor list before registering Gregory Price
2023-10-31 6:03 ` Greg KH
2023-10-31 4:58 ` Gregory Price
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox