lkml.org 
[lkml]   [2021]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 2/2] x86/sgx: Add an attribute for the amount of SGX memory in a NUMA node
On Sun, Oct 24, 2021 at 05:24:43PM +0300, Jarkko Sakkinen wrote:
> On Sat, 2021-10-23 at 08:33 +0200, Greg Kroah-Hartman wrote:
> > On Sat, Oct 23, 2021 at 04:02:48AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, 2021-10-18 at 16:35 +0200, Greg Kroah-Hartman wrote:
> > > > > +               ret = sysfs_create_group(&dev->kobj, &sgx_node_attr_group);
> > > >
> > > > A huge hint, if a driver has to call a sysfs_* call, something is wrong.
> > > >
> > > > Something is wrong here.
> > > >
> > > > Why are you messing around with a kobject?  This is a device, that you
> > > > control, you can just set the default attribute group for it and then
> > > > the driver core will add and remove the sysfs group at the proper time,
> > > > in the proper way.  Right now you are racing userspace and loosing.
> > > >
> > > > Use the default group list, that is what it is there for.
> > >
> > > I used sysfs_create_group() because node_devices is not owned by SGX
> > > code. It is managed in drivers/base/node.c, and also initialized before
> > > SGX.
> >
> > Then that is broken, please do not use that device as your code does not
> > "own" it.  Or fix the logic to be initialized earlier.
>
> To get a synchronous initialization, I'd need to add the attributes as
> part of this declaration:
>
> static struct attribute *node_dev_attrs[] = {
> &dev_attr_cpumap.attr,
> &dev_attr_cpulist.attr,
> &dev_attr_meminfo.attr,
> &dev_attr_numastat.attr,
> &dev_attr_distance.attr,
> &dev_attr_vmstat.attr,
> NULL
> };
> ATTRIBUTE_GROUPS(node_dev);
>
> That guarantees that the attribute exists at the time when the
> node is created, e.g. in that sense this will fix the race with
> uevent code.
>
> However, up until sgx_init() has been completed, the attribute
> will emit '0'.

Is that a problem? Who would be wanting to use sgx until that happens?
You have this issue today anyway, right?

> If I change sgx_init() from device_initcall() to
> core_initcall() (i.e. one before postcore_initcall(), can I
> expect these to work:
>
> * node_isset()
> * node_set()
> * num_possibles_nodes()
> * numa_node_id()
> * next_node_in()
>
> ?

You should be able to test this out yourself :)

thanks,

greg k-h

\
 
 \ /
  Last update: 2021-10-25 07:17    [W:0.151 / U:0.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site