All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: "Greg KH" <gregkh@suse.de>, "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: Fri, 3 Feb 2012 17:30:56 +0100	[thread overview]
Message-ID: <20120203163056.GA4190@redhat.com> (raw)
In-Reply-To: <20120202171659.GA29378@oksana.dev.rtsoft.ru>

On 02/02, Anton Vorontsov wrote:
>
> On Thu, Feb 02, 2012 at 01:54:41PM +0100, Oleg Nesterov wrote:
> >
> > 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).

Yes.

> 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.

And there are other reasons for tasklist. It is not clear why
for_each_process() itself is safe. OK, currently (afaics) the
caller disables irqs, but in theory this doesn't imply rcu_lock.

And it can race with fork() and miss the task, although mostly
in theory.

> --- 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);

Agreed, but force_sig() should not be used anyway. It sends the
signal to the thread, we need to kill the process. The main thread
can exit.

> > 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).

This is the common mistake. Consider this program:

	void *thread_func(...)
	{
		use_a_lot_of_memory();
	}

	int main(void)
	{
		pthread_create(..., thread_func, ...);
		pthread_exit();
	}

lowmem_shrink() will skip this task because p->mm == NULL.

Oleg.


  parent reply	other threads:[~2012-02-03 16:37 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
2012-02-03  0:03     ` [PATCH v3] " Anton Vorontsov
2012-02-03 16:36       ` Oleg Nesterov
2012-02-03 16:30     ` Oleg Nesterov [this message]
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=20120203163056.GA4190@redhat.com \
    --to=oleg@redhat.com \
    --cc=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=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.