Re: 2.6.31rc5 RAID10 lockdep report - sysfs_nofity_dirent lockingissue

[Greg KH]

On Tue, Sep 15, 2009 at 03:12:07PM -0700, Dan Williams wrote:
> On Wed, Aug 5, 2009 at 10:43 PM, Neil Brown <neilb@xxxxxxx> wrote:
> > On Tuesday August 4, gregkh@xxxxxxx wrote:
> >> >
> >> > Greg: does that look right?  If so I'll add a changelog entry and
> >> > submit it properly (after at least a compile test...)
> >>
> >> Yes, it looks correct, if it passes your tests :)
> >
> > Thanks.
> > I've tested it and documented it now and so am happy to submit it.
> > Thanks,
> > NeilBrown
> >
> >
> > From: NeilBrown <neilb@xxxxxxx>
> > Date: Thu, 6 Aug 2009 15:42:08 +1000
> > Subject: [PATCH] Allow sysfs_notify_dirent to be called from interrupt context.
> >
> > sysfs_notify_dirent is a simple atomic operation that can be used to
> > alert user-space that new data can be read from a sysfs attribute.
> >
> > Unfortunately is cannot currently be called from non-process context
> > because of it's use of spin_lock which is sometimes taken with
> > interrupt enabled.
> >
> > So change all lockers of sysfs_open_dirent_lock to disable interrupts,
> > thus making sysfs_notify_dirent safe to be called from non-process
> > context (as drivers/md does in md_safemode_timeout).
> >
> > sysfs_get_open_dirent is (documented as being) only called from
> > process context, so it uses spin_lock_irq.  Other places
> > use spin_lock_irqsave.
> >
> > The usage for sysfs_notify_dirent in md_safemode_timeout was
> > introduced in 2.6.28, so this patch is suitable for that and more
> > recent kernels.
> >
> > Cc: stable@xxxxxxxxxx
> > Signed-off-by: NeilBrown <neilb@xxxxxxx>
> > ---
> 
> Greg?
> 
> Looks like this never made it upstream, and now Hans is hitting this
> in his tests.

Ok, I don't have this in my queue, so someone needs to resubmit it and
tell me what kernel trees it should be applicable for.

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/