All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 1/3] When migrate_pages returns 0, all pages must have been released
Date: Fri, 21 Jan 2011 18:36:18 +0100	[thread overview]
Message-ID: <20110121173618.GH9506@random.random> (raw)
In-Reply-To: <alpine.DEB.2.00.1101211005150.14313@router.home>

On Fri, Jan 21, 2011 at 10:11:03AM -0600, Christoph Lameter wrote:
> On Thu, 20 Jan 2011, Andrea Arcangeli wrote:
> 
> > Which following putback_lru_page()?  You mean
> > putback_lru_page(newpage)? That is for the newly allocated page
> > (allocated at the very top, so always needed), it's not relevant to
> > the page_count(page) = 1. The page_count 1 is hold by the caller, so
> > it's leaking memory right now (for everything but compaction).
> 
> Ahh yes we removed the putback_lru_pages call from migrate_pages()
> and broke the existing release logic. The caller has to call
> putback_release_pages() as per commit

putback_lru_paeges

> cf608ac19c95804dc2df43b1f4f9e068aa9034ab

That is the very commit that introduced the two bugs that I've fixed
by code review.

> 
> If that is still the case then we still have the double free.

The caller only calls putback_lru_pages if ret != 0 (the two cases you
refer to happen with ret = 0).

Even if caller unconditionally calls putback_lru_pages (kind of what
compaction did), it can't double free because migrate_pages already
unlinked the pages before calling putback_lru_page(page), so there's
no way to do a double free (however if the caller unconditionally
called putback_lru_pages there would be no memleak to fix, but it
doesn't).

> Could we please document the calling conventions exactly in the source?
> Right now it says that the caller should call putback_lru_pages().

The caller should call putback_lru_pages only if ret != 0. Minchan
this is your commit we're discussing can you check the commentary?

Thanks!
Andrea


WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <aarcange@redhat.com>
To: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 1/3] When migrate_pages returns 0, all pages must have been released
Date: Fri, 21 Jan 2011 18:36:18 +0100	[thread overview]
Message-ID: <20110121173618.GH9506@random.random> (raw)
In-Reply-To: <alpine.DEB.2.00.1101211005150.14313@router.home>

On Fri, Jan 21, 2011 at 10:11:03AM -0600, Christoph Lameter wrote:
> On Thu, 20 Jan 2011, Andrea Arcangeli wrote:
> 
> > Which following putback_lru_page()?  You mean
> > putback_lru_page(newpage)? That is for the newly allocated page
> > (allocated at the very top, so always needed), it's not relevant to
> > the page_count(page) = 1. The page_count 1 is hold by the caller, so
> > it's leaking memory right now (for everything but compaction).
> 
> Ahh yes we removed the putback_lru_pages call from migrate_pages()
> and broke the existing release logic. The caller has to call
> putback_release_pages() as per commit

putback_lru_paeges

> cf608ac19c95804dc2df43b1f4f9e068aa9034ab

That is the very commit that introduced the two bugs that I've fixed
by code review.

> 
> If that is still the case then we still have the double free.

The caller only calls putback_lru_pages if ret != 0 (the two cases you
refer to happen with ret = 0).

Even if caller unconditionally calls putback_lru_pages (kind of what
compaction did), it can't double free because migrate_pages already
unlinked the pages before calling putback_lru_page(page), so there's
no way to do a double free (however if the caller unconditionally
called putback_lru_pages there would be no memleak to fix, but it
doesn't).

> Could we please document the calling conventions exactly in the source?
> Right now it says that the caller should call putback_lru_pages().

The caller should call putback_lru_pages only if ret != 0. Minchan
this is your commit we're discussing can you check the commentary?

Thanks!
Andrea

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-01-21 18:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-20 16:17 [PATCH 1/3] When migrate_pages returns 0, all pages must have been released Minchan Kim
2011-01-20 16:17 ` Minchan Kim
2011-01-20 16:17 ` [PATCH 2/3] migration: Fix page corruption during hugepage migration Minchan Kim
2011-01-20 16:17   ` Minchan Kim
2011-01-20 16:17 ` [PATCH 3/3] compaction: Check migrate_pages's return value instead of list_empty Minchan Kim
2011-01-20 16:17   ` Minchan Kim
2011-01-26  8:18   ` Mel Gorman
2011-01-26  8:18     ` Mel Gorman
2011-01-20 17:30 ` [PATCH 1/3] When migrate_pages returns 0, all pages must have been released Christoph Lameter
2011-01-20 17:30   ` Christoph Lameter
2011-01-20 18:24   ` Andrea Arcangeli
2011-01-20 18:24     ` Andrea Arcangeli
2011-01-20 18:49     ` Christoph Lameter
2011-01-20 18:49       ` Christoph Lameter
2011-01-20 21:28       ` Andrea Arcangeli
2011-01-20 21:28         ` Andrea Arcangeli
2011-01-21 16:11         ` Christoph Lameter
2011-01-21 16:11           ` Christoph Lameter
2011-01-21 17:36           ` Andrea Arcangeli [this message]
2011-01-21 17:36             ` Andrea Arcangeli
2011-01-21 23:54             ` Minchan Kim
2011-01-21 23:54               ` Minchan Kim
2011-01-26  8:14 ` Mel Gorman
2011-01-26  8:14   ` Mel Gorman
2011-01-26 23:06 ` Andrew Morton
2011-01-26 23:06   ` Andrew Morton
2011-01-26 23:21   ` Minchan Kim
2011-01-26 23:21     ` Minchan Kim

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=20110121173618.GH9506@random.random \
    --to=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.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.