Re: [char-misc-next 2/3] mei: adding sysfs fw_status attribute

From: Greg KH
Date: Mon Jul 29 2013 - 18:38:12 EST


On Mon, Jul 29, 2013 at 10:27:06PM +0000, Winkler, Tomas wrote:
>
> >
> > > > >
> > > > >
> > > > > > >
> > > > > > > Just to make sure, is this what you're suggesting ?
> > > > > > >
> > > > > > > device->groups = mei_attr_groups
> > > > > > > mei_misc_device.parent = device; ret =
> > > > > > > misc_register(&mei_misc_device);
> > > > > >
> > > > > > Yes, that should work. If not, please let me know, the code
> > > > > > underwent some changes in 3.11-rc2.
> > > > >
> > > > > I don' t see the file being created.
> > > > > Not sure if the misc_register setup the parent sysfs as well.
> > > >
> > > > Oops, wait, the parent is already registered, that's not going to
> > > > work, you want to create the files for the device itself that you
> > > > are creating, so set the -
> > > > >groups field for that device.
> > > >
> > > > sorry about that.
> > >
> > > So is this okay to go as is?
> >
> > What is "this"?
>
> The intentions was to create the sysfs on a parent pci device, and
> these are already created .

You can't create attributes on a device you do not "own", that will be
racy and prone to cause big problems (your callback will not with the
"right" device usually, as your parent might not "be" a pci device in
the future...)

> The only reason I wanted do it here as this is true for any parent pci
> device we support currently that registers with mei.
>
> Either this code ode is still confusing because I'm doing something
> wrong here or your mind Is set on fixing this particular user space
> race issue.

Probably both...

Either way, you can't create sysfs files in a racy way, I'm going
through the whole kernel tree to clean them all up, I'm not going to add
new race conditions today that I need to fix up tomorrow, my patch count
is high enough as it is :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/