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

From: Neil Brown
Date: Wed Feb 17 2010 - 19:39:27 EST


On Wed, 17 Feb 2010 14:38:48 -0800
Greg KH <greg@xxxxxxxxx> wrote:

> 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.
I hadn't sent you a fix myself (As requested) as I got the impression from
the following discussion that a different approach would be taken.

I'm happy either way though.

Thanks,
NeilBrown
--
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/