Re: [PATCH] sysfs: differentiate between locking links andnon-links

[Greg KH]

On Thu, Feb 11, 2010 at 02:47:57PM -0800, Eric W. Biederman wrote:
> Greg KH <gregkh@xxxxxxx> writes:
> 
> > On Thu, Feb 11, 2010 at 01:42:10PM -0800, Eric W. Biederman wrote:
> >> Greg KH <gregkh@xxxxxxx> writes:
> >> 
> >> > On Wed, Feb 10, 2010 at 12:09:33PM +1100, Neil Brown wrote:
> >> >> 
> >> >> Hi,
> >> >>  I've just spent a while sorting out some lockdep complaints triggered
> >> >>  by the recent addition of the "s_active" lockdep annotation in sysfs
> >> >>   (commit 846f99749ab68bbc7f75c74fec305de675b1a1bf)
> >> >> 
> >> >>  Some of them are genuine and I have submitted a fix for those.
> >> >>  Some are, I think, debatable and I get to that is a minute.  I've
> >> >>  submitted a fix for them anyway.
> >> >>  But some are to my mind clearly bogus and I'm hoping that can be
> >> >>  fixed by the change below (or similar).
> >> >>  The 'bogus' ones are triggered by writing to a sysfs attribute file
> >> >>  for which the handler tries to delete a symlink from sysfs.
> >> >>  This appears to be a recursion on s_active as s_active is held while
> >> >>  the handler runs and is again needed to effect the delete.  However
> >> >>  as the thing being deleted is a symlink, it is very clearly a
> >> >>  different object to the thing triggering the delete, so there is no
> >> >>  real loop.
> >> >> 
> >> >>  The following patch splits the lockdep context in two - one for
> >> >>  symlink and one for everything else.  This removes the apparent loop.
> >> >>  (An example report can be seen in
> >> >>      http://bugzilla.kernel.org/show_bug.cgi?id=15142).
> >> >> 
> >> >>  The "debatable" dependency loops happen when writing to one attribute
> >> >>  causes a different attribute to be deleted.  In my (md) case this can
> >> >>  actually cause a deadlock as both the attributes take the same lock
> >> >>  while the handler is running.  This is because deleting the attribute
> >> >>  will block until the all accesses of that attribute have completed (I
> >> >>  think).
> >> >>  However it should be possible to delete a name from sysfs while there
> >> >>  are still accesses pending (it works for normal files!!).  So if
> >> >>  sysfs could be changed to simply unlink the file and leave deletion to
> >> >>  happen when the refcount become zero it would certainly make my life
> >> >>  a lot easier, and allow the removal of some ugly code from md.c.
> >> >>  I don't know sysfs well enough to suggest a patch though.
> >> >> 
> >> >> Thanks,
> >> >> NeilBrown
> >> >> 
> >> >> 
> >> >> 
> >> >> commit 2e502cfe444b68f6ef6b8b2abe83b6112564095b
> >> >> Author: NeilBrown <neilb@xxxxxxx>
> >> >> Date:   Wed Feb 10 09:43:45 2010 +1100
> >> >> 
> >> >>     sysfs: differentiate  between locking links and non-links for sysfs
> >> >>     
> >> >>     symlinks and non-symlink is sysfs are very different.
> >> >>     A symlink can never be locked (active) while an attribute
> >> >>     modification routine is running.  So removing symlink from an
> >> >>     attribute 'store' routine should be permitted without any lockdep
> >> >>     warnings.
> >> >>     
> >> >>     So split the lockdep context for 's_active' in two, one for symlinks
> >> >>     and other for everything else.
> >> >>     
> >> >>     Signed-off-by: NeilBrown <neilb@xxxxxxx>
> >> >
> >> > Nice patch, I'll queue it up for .34.
> >> 
> >> Note the patch does not compile with lockdep disabled.
> >
> > Ugh, why not?
> >
> > Neil, care to fix this up?
> 
>  
>  #ifdef CONFIG_DEBUG_LOCK_ALLOC
> -#define sysfs_dirent_init_lockdep(sd)				\
> +#define sysfs_dirent_init_lockdep(sd, type)			\
>  do {								\
>  	static struct lock_class_key __key;			\
>  								\
> -	lockdep_init_map(&sd->dep_map, "s_active", &__key, 0);	\
> +	lockdep_init_map(&sd->dep_map, "s_active_" type, &__key, 0);	\
>  } while(0)
>  #else
>  #define sysfs_dirent_init_lockdep(sd) do {} while(0)

Got it, I've fixed this by hand.

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/