All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <anton.vorontsov@linaro.org>
To: Oleg Nesterov <oleg@redhat.com>, Greg KH <gregkh@suse.de>
Cc: "Arve Hjønnevåg" <arve@android.com>,
	"KOSAKI Motohiro" <kosaki.motohiro@gmail.com>,
	"San Mehat" <san@google.com>, "Colin Cross" <ccross@android.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org, kernel-team@android.com,
	linaro-kernel@lists.linaro.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] staging: android/lowmemorykiller: Don't grab tasklist_lock
Date: Thu, 2 Feb 2012 21:16:59 +0400	[thread overview]
Message-ID: <20120202171659.GA29378@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20120202125441.GA32229@redhat.com>

On Thu, Feb 02, 2012 at 01:54:41PM +0100, Oleg Nesterov wrote:
> On 02/01, Anton Vorontsov wrote:
> >
> > @@ -132,7 +133,7 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc)
> >  	}
> >  	selected_oom_adj = min_adj;
> >
> > -	read_lock(&tasklist_lock);
> > +	rcu_read_lock();
> 
> This has the same problem, force_sig() becomes unsafe.

Ouch, I think I finally got it. So, lock_task_sighand() is trying to
gracefully grab the lock, checking if the sighand is not NULL (which means,
per __exit_signal(), that the task is halfway into the grave).

Well, it seems that such a behaviour of force_sig() is not quite obvious,
and there are other offenders out there. E.g. in sysrq code I don't see
anything that prevent the same race.

static void send_sig_all(int sig)
{      
        struct task_struct *p;

        for_each_process(p) {
                if (p->mm && !is_global_init(p))
                        /* Not swapper, init nor kernel thread */
                        force_sig(sig, p);
        }
}

Would the following fix work for the sysrq?

- - - -
From: Anton Vorontsov <anton.vorontsov@linaro.org>
Subject: [PATCH] sysrq: Fix unsafe operations on tasks

sysrq should grab the tasklist lock, otherwise calling force_sig() is
not safe, as it might race with exiting task, which ->sighand might be
set to NULL already.

Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
---
 drivers/tty/sysrq.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 7867b7c..a1bcad7 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -322,11 +322,13 @@ static void send_sig_all(int sig)
 {
 	struct task_struct *p;
 
+	read_lock(&tasklist_lock);
 	for_each_process(p) {
 		if (p->mm && !is_global_init(p))
 			/* Not swapper, init nor kernel thread */
 			force_sig(sig, p);
 	}
+	read_unlock(&tasklist_lock);
 }
 
 static void sysrq_handle_term(int key)
- - - -

But for LMK I will use send_signal(), as LMK is special.

Plus, while I'm at it, might want to review a bit closer other offenders,
and fix them as well.

> Why do you need force_? Do you really want to kill /sbin/init (or sub-namespace
> init) ?

Nope.

> We could change force_sig_info() to use lock_task_sighand(), but I'd like to
> avoid this. Imho, this interface should be cleanuped, and it should be used
> for synchronous signals only.

OK. Then we should fix the users?

> With or without this patch, sig == NULL is not possible but !mm is not right,
> there could be other other threads with mm != NULL.

I'm not sure I completely follow. In the current LMK code, we check for !mm
because otherwise the potential victim is useless for us (i.e. killing it
will not free much memory anyway).

Thanks!

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

  reply	other threads:[~2012-02-02 17:17 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01  4:33 [PATCH] staging: android/lowmemorykiller: Don't grab tasklist_lock Anton Vorontsov
2012-02-02 12:54 ` Oleg Nesterov
2012-02-02 17:16   ` Anton Vorontsov [this message]
2012-02-03  0:03     ` [PATCH v3] " Anton Vorontsov
2012-02-03 16:36       ` Oleg Nesterov
2012-02-03 16:30     ` [PATCH] " Oleg Nesterov
2012-02-06 16:29       ` [PATCH 1/6] oom: Make find_lock_task_mm() sparse-aware Anton Vorontsov
2012-02-06 16:35         ` Greg KH
2012-02-06 18:59           ` Anton Vorontsov
2012-02-06 19:18             ` Greg KH
2012-02-06 21:27               ` KOSAKI Motohiro
2012-02-07  4:48                 ` [PATCH v2 " Anton Vorontsov
2012-02-07  5:17                   ` KOSAKI Motohiro
2012-02-08 15:27                   ` Oleg Nesterov
2012-02-09 16:45                     ` [PATCH] sched: Turn lock_task_sighand() into a static inline Anton Vorontsov
2012-02-11 23:10                       ` [tip:sched/core] " tip-bot for Anton Vorontsov
2012-02-15 13:52                         ` Peter Zijlstra
2012-02-06 16:29       ` [PATCH 2/6] oom: Get rid of sparse warnings Anton Vorontsov
2012-02-06 21:33         ` KOSAKI Motohiro
2012-02-07  4:20           ` [PATCH v2 " Anton Vorontsov
2012-02-07  5:38             ` KOSAKI Motohiro
2012-02-07  6:23               ` Anton Vorontsov
2012-02-08 18:13                 ` KOSAKI Motohiro
2012-02-06 16:29       ` [PATCH 3/6] staging: android/lowmemorykiller: Don't grab tasklist_lock Anton Vorontsov
2012-02-06 16:36         ` Greg KH
2012-02-06 16:42           ` Anton Vorontsov
2012-02-09  0:56             ` Greg KH
2012-02-08 15:32         ` Oleg Nesterov
2012-02-06 16:29       ` [PATCH 4/6] staging: android/lowmemorykiller: Better mm handling Anton Vorontsov
2012-02-06 21:36         ` KOSAKI Motohiro
2012-02-08 15:34         ` Oleg Nesterov
2012-02-06 16:29       ` [PATCH 5/6] staging: android/lowmemorykiller: No need for task->signal check Anton Vorontsov
2012-02-06 21:38         ` KOSAKI Motohiro
2012-02-08 15:35         ` Oleg Nesterov
2012-02-06 16:30       ` [PATCH 6/6] staging: android/lowmemorykiller: Do not kill kernel threads Anton Vorontsov
2012-02-06 21:38         ` KOSAKI Motohiro
2012-02-08 15:36         ` 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=20120202171659.GA29378@oksana.dev.rtsoft.ru \
    --to=anton.vorontsov@linaro.org \
    --cc=arve@android.com \
    --cc=ccross@android.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@suse.de \
    --cc=kernel-team@android.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=san@google.com \
    /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.