[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y5srbaf7.fsf@rustcorp.com.au>
Date: Sun, 29 Jan 2012 11:19:00 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Oleg Nesterov <oleg@...hat.com>
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 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.
Cheers,
Rusty.
--
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