public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: apw@canonical.com, arjan@linux.intel.com, fhrbata@redhat.com,
	john.johansen@canonical.com, penguin-kernel@I-love.SAKURA.ne.jp,
	rientjes@google.com, rusty@rustcorp.com.au, tj@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/6] kmod: make __request_module() killable
Date: Thu, 16 Feb 2012 16:04:29 +0100	[thread overview]
Message-ID: <20120216150429.GB11953@redhat.com> (raw)
In-Reply-To: <20120215123049.6e938eed.akpm@linux-foundation.org>

On 02/15, Andrew Morton wrote:
>
> On Tue, 14 Feb 2012 17:49:14 +0100
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > As Tetsuo Handa pointed out, request_module() can stress the
> > system while the oom-killed caller sleeps in TASK_UNINTERRUPTIBLE.
>
> Whine.
>
> Solving this problem is the entire point of the entire patchset and you
> told us almost nothing about it.  Please, provide a complete
> description of the problem which is being solved, so we can understand
> the value of the patchset?

I did ;) from the message I sent to security list:

	Tetsuo has the test-cases, but the problem (well, one of the problems) is
	simple.

	The task T uses "almost all" memory, then it does something which triggers
	request_module(). Say, it can simply call sys_socket(). This in turn needs
	more memory and leads to OOM. oom-killer correctly chooses T and kills it,
	but this can't help because it sleeps in TASK_UNINTERRUPTIBLE and after
	that oom-killer becomes "disabled" by the TIF_MEMDIE task T.

Credits to Tetsuo.

But in fact I think this change is "obviously good" anyway. Assuming
it is correct of course. request_module() is heavy, it can take the
unpredictable amount of time/resources to finish. It is not good we
can't interrupt the task which waits for completion.

Yes, this adds some complications and initially I wasn't agree with
Tetsuo, I thought this doesn't worth the trouble. But I hope that
this code is simple/clean enough.



Btw, there is another example of "unbounded" sleep in UNINTERRUPTIBLE,
vfork. I already have the patches, will send today.

Oleg.


  reply	other threads:[~2012-02-16 15:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-14 16:47 [PATCH 0/6] make request_module() killable Oleg Nesterov
2012-02-14 16:47 ` [PATCH 1/6] usermodehelper: introduce umh_complete(sub_info) Oleg Nesterov
2012-02-14 16:48 ` [PATCH 2/6] usermodehelper: implement UMH_KILLABLE Oleg Nesterov
2012-02-14 16:48 ` [PATCH 3/6] usermodehelper: kill umh_wait, renumber UMH_* constants Oleg Nesterov
2012-02-15  1:09   ` Rusty Russell
2012-02-15 18:12     ` Oleg Nesterov
2012-02-14 16:48 ` [PATCH 4/6] usermodehelper: ____call_usermodehelper() doesn't need do_exit() Oleg Nesterov
2012-02-14 16:48 ` [PATCH 5/6] kmod: introduce call_modprobe() helper Oleg Nesterov
2012-02-14 16:49 ` [PATCH 6/6] kmod: make __request_module() killable Oleg Nesterov
2012-02-15 20:30   ` Andrew Morton
2012-02-16 15:04     ` Oleg Nesterov [this message]
2012-02-16 17:26       ` [PATCH 0/4] make vfork() killable Oleg Nesterov
2012-02-16 17:26         ` [PATCH 1/4] introduce complete_vfork_done() Oleg Nesterov
2012-02-17  0:35           ` Andrew Morton
2012-02-17 14:37             ` Oleg Nesterov
2012-02-16 17:27         ` [PATCH 2/4] vfork: make it killable Oleg Nesterov
2012-02-17  0:39           ` Andrew Morton
2012-02-17 14:44             ` Oleg Nesterov
2012-02-16 17:27         ` [PATCH 3/4] coredump_wait: don't call complete_vfork_done() Oleg Nesterov
2012-02-16 17:27         ` [PATCH 4/4] kill PF_STARTING Oleg Nesterov
2012-02-17  0:26         ` [PATCH 0/4] make vfork() killable Andrew Morton
2012-02-17  2:45           ` Stephen Rothwell
2012-02-17 14:46             ` Oleg Nesterov
     [not found]         ` <20120216173233.GF30393@redhat.com>
     [not found]           ` <201202172211.CGH81726.OStOJFLFHQVMFO@I-love.SAKURA.ne.jp>
     [not found]             ` <20120217150726.GD22440@redhat.com>
2012-02-17 18:00               ` [PATCH 0/1] hung_task: fix the broken rcu_lock_break() logic Oleg Nesterov
2012-02-17 18:00                 ` [PATCH 1/1] " Oleg Nesterov

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=20120216150429.GB11953@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=arjan@linux.intel.com \
    --cc=fhrbata@redhat.com \
    --cc=john.johansen@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=rusty@rustcorp.com.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox