linux-kernel - Re: [PATCH] mm: sync rss-counters at the end of exit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Apr 2012 15:03:45 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...il.com>
cc:	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org,
	Markus Trippelsdorf <markus@...ppelsdorf.de>
Subject: Re: [PATCH] mm: sync rss-counters at the end of exit_mm()

On Mon, 9 Apr 2012, KOSAKI Motohiro wrote:
> On Mon, Apr 9, 2012 at 4:03 PM, Konstantin Khlebnikov
> <khlebnikov@...nvz.org> wrote:
> > On task's exit do_exit() calls sync_mm_rss() but this is not enough,
> > there can be page-faults after this point, for example exit_mm() ->
> > mm_release() -> put_user() (for processing tsk->clear_child_tid).
> > Thus there may be some rss-counters delta in current->rss_stat.
> 
> Seems reasonable.

Yes, I think Konstantin has probably caught it;
but I'd like to hear confirmation from Markus.

> but I have another question. Do we have any reason to
> keep sync_mm_rss() in do_exit()? I havn't seen any reason that thread exiting
> makes rss consistency.

IIRC it's all about the hiwater_rss/maxrss stuff: we want to sync the
maximum rss into mm->hiwater_rss before it's transferred to signal->maxrss,
and later made visible to the user though getrusage(RUSAGE_CHILDREN,) -
does your reading confirm that?

Konstantin now finds the child_tid and futex stuff can trigger faults
raising rss beyond that point, but usually it won't go higher than when
it was captured for maxrss there.

The sync_mm_rss() added by this patch (after "tsk->mm = NULL" so
*_mm_counter_fast() cannot store any more into the tsk even if there
were more faults) is solely to satisfy Konstantin's check_mm(), and
it is irritating to have that duplicated on the exit path.

I'd be happy to see the new one put under CONFIG_DEBUG_VM along with
check_mm(), once it's had a few -rcs of exposure without.

Hugh

> 
> 
> >
> > Signed-off-by: Konstantin Khlebnikov <khlebnikov@...nvz.org>
> > Reported-by: Markus Trippelsdorf <markus@...ppelsdorf.de>
> > Cc: Hugh Dickins <hughd@...gle.com>
> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
> > ---
> >  kernel/exit.c |    1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/kernel/exit.c b/kernel/exit.c
> > index d8bd3b42..8e09dbe 100644
> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> > @@ -683,6 +683,7 @@ static void exit_mm(struct task_struct * tsk)
> >        enter_lazy_tlb(mm, current);
> >        task_unlock(tsk);
> >        mm_update_next_owner(mm);
> > +       sync_mm_rss(mm);
> >        mmput(mm);
> >  }
> >