[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <18314.48266.220382.180206@notabene.brown>
Date: Mon, 14 Jan 2008 12:36:10 +1100
From: Neil Brown <neilb@...e.de>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Kevin Winchester <kjwinchester@...il.com>,
"J. Bruce Fields" <bfields@...ldses.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
NetDev <netdev@...r.kernel.org>, gregkh@...e.de
Subject: Re: Top 10 kernel oopses for the week ending January 5th, 2008
On Thursday January 10, viro@...IV.linux.org.uk wrote:
> On Thu, Jan 10, 2008 at 03:13:48PM +1100, Neil Brown wrote:
> > > What guarantees that it doesn't happen before we get to callback? AFAICS,
> > > nothing whatsoever...
> >
> > Yes, that's bad isn't it :-)
> >
> > I think I should be using sysfs_schedule_callback here. That makes the
> > required 'get' and 'put' calls.... but it can fail with -ENOMEM. I
> > wonder what I do if -ENOMEM??? Maybe I'll just continue to roll my
> > one :-(
>
> How about this instead (completely untested)
>
> * split failure exits
> * switch to kick_rdev_from_array()
> * fold unbind_rdev_from_array() into it (no other callers anymore)
> * take export_rdev() into failure case in bind_rdev_to_array()
> * in kick_rdev_from_array() do what export_rdev() does sans
> kobject_put() and do that before schedule_work(). Take kobject_put() into
> delayed_delete().
While there are probably some good ideas in there, I think fixing this
particular bug is much simpler. Just take a reference to the object
before scheduling the worker, and drop it when the worker has done
its work.
I have a closer look at the idea of no required export_rdev after a
failed bind_rdev_to_array. On the surface it does seem to make the
code nicer.
Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists