Re: Sysfs attributes racing with unregistration

[Tejun Heo]

Hello, Alan.

On Wed, Jan 04, 2012 at 11:52:20AM -0500, Alan Stern wrote:
> Can you explain the current situation regarding access to sysfs
> attributes and possible races with kobject removal?  I have two
> questions in particular:

Heh, I haven't looked at sysfs code seriously for years now and my
memory sucks to begin with, so please take whatever I say with a
gigantic grain of salt.  Eric has been looking at sysfs a lot lately
so he probably can answer these best.  Adding him, Greg and Kay - hi!
guys.

> 	What happens if one thread calls an attribute's show or
> 	store method concurrently with another thread unregistering
> 	the underlying kobject?

sysfs nodes have two reference counts - one for object lifespan and
the other for active usage.  The latter is called active and acquired
and released using sysfs_get/put_active().  Any callback invocation
should be performed while holding an active reference.  On removal,
sysfs_deactivate() marks the active reference count for deactivation
so that no new active reference is given out and waits for the
in-flight ones to drain.  IOW, removal makes sure new invocations of
callbacks fail and waits for in-progress ones to finish before
proceeding with removal.

> 	What happens if a thread continues to hold an open fd 
> 	reference to a sysfs attribute file after the kobject is
> 	unregistered, and then tries to read or write that fd?

Active reference is held only for the duration of each callback
invocation.  Userland can't prolong the existence of active reference.
The duration of callback execution is the only deciding factor.

Someone (I think Eric, right?) was trying to generalize the semantics
to vfs layer so that severance/revocation capability is generally
available.  IIRC, it didn't get through tho.

Thanks.

-- 
tejun
--
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/