linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-mm@kvack.org, vdavydov@virtuozzo.com, rientjes@google.com
Subject: Re: [PATCH] mm,oom: use per signal_struct flag rather than clear TIF_MEMDIE
Date: Mon, 27 Jun 2016 18:06:16 +0200	[thread overview]
Message-ID: <20160627160616.GN31799@dhcp22.suse.cz> (raw)
In-Reply-To: <20160627155119.GA17686@redhat.com>

On Mon 27-06-16 17:51:20, Oleg Nesterov wrote:
> On 06/27, Michal Hocko wrote:
> >
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -237,6 +237,8 @@ void free_task(struct task_struct *tsk)
> >  	ftrace_graph_exit_task(tsk);
> >  	put_seccomp_filter(tsk);
> >  	arch_release_task_struct(tsk);
> > +	if (tsk->active_mm)
> > +		mmdrop(tsk->active_mm);
> >  	free_task_struct(tsk);
> >  }
> >  EXPORT_SYMBOL(free_task);
> > @@ -1022,6 +1024,8 @@ static int copy_mm(unsigned long clone_flags, struct task_struct *tsk)
> >  good_mm:
> >  	tsk->mm = mm;
> >  	tsk->active_mm = mm;
> > +	/* to be release in the final task_put */
> > +	atomic_inc(&mm->mm_count);
> >  	return 0;
> 
> No, I don't think this can work.
> 
> Note that tsk->active_mm in free_task() points to the random mm "borrowed"
> from the previous/random task in context_switch() if task->mm == NULL. This
> is true for kthreads and for the task which has already called exit_mm().

OK, I misread the code. I though we wouldn't passed that route
again. Anyway, back to the drawing board.

> 
> > -	p = find_lock_task_mm(tsk);
> > -	if (!p)
> > -		goto unlock_oom;
> > -	mm = p->mm;
> > +	task_lock(tsk);
> > +	mm = tsk->active_mm;
> 
> The same. We can't know where this ->active_mm points to.
> 
> Just suppose that this tsk schedules after exit_mm(). When it gets CPU
> again tsk->active_mm will point to ->mm of another task which in turns
> called schedule() to make this tsk active.
> 
> Yes I agree, it would be nice to remove find_lock_task_mm(). And in
> fact it would be nice to kill task_struct->mm (but this needs a lot
> of cleanups). We probably want signal_struct->mm, but this is a bit
> complicated (locking).

Is there any hard requirement to reset task_struct::mm in the first
place?

I mean I could have added oom_mm pointer into the task_struct and that
would guarantee that we always have a valid pointer when it is needed
but having yet another mm pointer there.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-06-27 16:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 11:02 Tetsuo Handa
2016-06-24 12:39 ` Michal Hocko
2016-06-24 15:54   ` Tetsuo Handa
2016-06-24 22:42     ` Oleg Nesterov
2016-06-24 21:56 ` Oleg Nesterov
2016-06-25  5:44   ` Tetsuo Handa
2016-06-27  9:23     ` Michal Hocko
2016-06-27 10:36       ` Michal Hocko
2016-06-27 15:51         ` Oleg Nesterov
2016-06-27 16:06           ` Michal Hocko [this message]
2016-06-27 17:55             ` Oleg Nesterov
2016-06-28 10:19               ` Michal Hocko
2016-06-29  0:13                 ` Oleg Nesterov
2016-06-29  8:33                   ` Michal Hocko
2016-06-29 14:19                     ` Michal Hocko
2016-07-01 10:15                       ` Tetsuo Handa
2016-06-29 20:01                     ` Oleg Nesterov
2016-06-30  7:59                       ` Michal Hocko
2016-06-30 10:51                         ` Tetsuo Handa
2016-06-30 11:21                           ` Michal Hocko
2016-07-03 13:32                           ` Oleg Nesterov
2016-07-03 13:21                         ` Oleg Nesterov
2016-07-07 11:51                           ` Michal Hocko
2016-07-07 16:42                             ` Oleg Nesterov
2016-06-29 20:14                 ` Oleg Nesterov
2016-06-30  8:07                   ` Michal Hocko
2016-07-03 13:24                     ` Oleg Nesterov
2016-06-27 21:09       ` Oleg Nesterov
2016-06-28 10:26         ` Michal Hocko
2016-06-29 19:34           ` Oleg Nesterov
2016-06-27 20:40     ` Oleg Nesterov
2016-06-28 10:29       ` Michal Hocko
2016-06-29 20:24         ` Oleg Nesterov
2016-06-30  8:16           ` Michal Hocko

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=20160627160616.GN31799@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=vdavydov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox