[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120129163141.GC20803@redhat.com>
Date: Sun, 29 Jan 2012 17:31:41 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: + kmod-avoid-deadlock-by-recursive-kmod-call.patch added to
-mm tree
On 01/29, Rusty Russell wrote:
>
> On Fri, 27 Jan 2012 15:32:34 +0100, Oleg Nesterov <oleg@...hat.com> wrote:
> > On 01/27, Rusty Russell wrote:
> > > On Thu, 26 Jan 2012 18:56:12 +0100, Oleg Nesterov <oleg@...hat.com> wrote:
> > > > Can't we simply kill khelper_wq and use system_unbound_wq instead?
> > >
> > > I'd prefer that, because then we'd hit the existing "too many modprobes"
> > > check.
> >
> > Hmm. Why? I mean, why do you think that s/khelper_wq/system_unbound_wq/
> > leads to recursive __request_module's ?
> >
> > Note that that this patch (which adds kmod_thread_locker) can not limit
> > the recursive modprobe loop.
> >
> >
> > OK, yes, with system_unbound_wq we can hit this warning if we have
> > max_modprobes UMH_WAIT_EXEC's resulting in __request_module at the
> > same time, but probably this is good?
>
> Yes, that's what I'm saying.
>
> We already have a check against too many modprobes, it might be best to
> use it.
Confused... in this case I do not understand why do you dislike the
idea to kill khelper_wq.
Help!
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists