All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: + kmod-avoid-deadlock-by-recursive-kmod-call.patch added to -mm tree
Date: Sun, 29 Jan 2012 11:19:00 +1030	[thread overview]
Message-ID: <87y5srbaf7.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120127143234.GA13056@redhat.com>

On Fri, 27 Jan 2012 15:32:34 +0100, Oleg Nesterov <oleg@redhat.com> wrote:
> On 01/27, Rusty Russell wrote:
> > On Thu, 26 Jan 2012 18:56:12 +0100, Oleg Nesterov <oleg@redhat.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.

  reply	other threads:[~2012-01-29 11:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26 17:56 + kmod-avoid-deadlock-by-recursive-kmod-call.patch added to -mm tree Oleg Nesterov
2012-01-27  2:55 ` Rusty Russell
2012-01-27 14:32   ` Oleg Nesterov
2012-01-29  0:49     ` Rusty Russell [this message]
2012-01-29 16:31       ` Oleg Nesterov
2012-01-29 23:26         ` Rusty Russell
2012-01-30  0:25           ` Tejun Heo
2012-01-30 13:03             ` Oleg Nesterov
2012-01-30 17:28               ` Tejun Heo
2012-02-03 18:00                 ` Oleg Nesterov
2012-02-03 19:26                   ` Tejun Heo
2012-02-04 12:56                   ` + kmod-avoid-deadlock-by-recursive-kmod-call.patch added to-mm tree Tetsuo Handa
2012-02-06 17:19                     ` Oleg Nesterov
2012-01-30 12:38           ` + kmod-avoid-deadlock-by-recursive-kmod-call.patch added to -mm tree Oleg Nesterov
  -- strict thread matches above, loose matches on Subject: below --
2012-01-26  0:41 akpm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y5srbaf7.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.