From: Daniel Phillips <phillips@arcor.de>
To: Andrew Morton <akpm@zip.com.au>
Cc: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>,
lkml <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: MM patches against 2.5.31
Date: Mon, 26 Aug 2002 21:34:19 +0200 [thread overview]
Message-ID: <E17jPcx-0002Yp-00@starship> (raw)
In-Reply-To: <3D6A8082.3775C5AB@zip.com.au>
On Monday 26 August 2002 21:24, Andrew Morton wrote:
> Daniel Phillips wrote:
> > On Monday 26 August 2002 17:29, Christian Ehrhardt wrote:
> > > On Mon, Aug 26, 2002 at 04:22:50PM +0200, Daniel Phillips wrote:
> > > > On Monday 26 August 2002 11:10, Christian Ehrhardt wrote:
> > > > > + * A special Problem is the lru lists. Presence on one of these lists
> > > > > + * does not increase the page count.
> > > >
> > > > Please remind me... why should it not?
> > >
> > > Pages that are only on the lru but not reference by anyone are of no
> > > use and we want to free them immediatly. If we leave them on the lru
> > > list with a page count of 1, someone else will have to walk the lru
> > > list and remove pages that are only on the lru.
> >
> > I don't understand this argument. Suppose lru list membership is worth a
> > page count of one. Then anyone who finds a page by way of the lru list can
> > safely put_page_testzero and remove the page from the lru list. Anyone who
> > finds a page by way of a page table can likewise put_page_testzero and clear
> > the pte, or remove the mapping and pass the page to Andrew's pagevec
> > machinery, which will eventually do the put_page_testzero. Anyone who
> > removes a page from a radix tree will also do a put_page_testzero. Exactly
> > one of those paths will result in the page count reaching zero, which tells
> > us nobody else holds a reference and it's time for __free_pages_ok. The page
> > is thus freed immediately as soon as there are no more references to it, and
> > does not hang around on the lru list.
> >
> > Nobody has to lock against the page count. Each put_page_testzero caller
> > only locks the data structure from which it's removing the reference.
> >
> > This seems so simple, what is the flaw?
>
> The flaw is in doing the put_page_testzero() outside of any locking
> which would prevent other CPUs from finding and "rescuing" the zero-recount
> page.
>
> CPUA:
> if (put_page_testzero()) {
> /* Here's the window */
> spin_lock(lru_lock);
> list_del(page->lru);
According to my assumption that lru list membership is (should be) worth one
page count, if testzero triggers here the page is not on the lru.
> CPUB:
>
> spin_lock(lru_lock);
> page = list_entry(lru);
> page_cache_get(page); /* If this goes from 0->1, we die */
It can't. You know that because you found the page on the lru, its count
must be at least one (again, according to assumption above).
> ...
> page_cache_release(page); /* double free */
I'd like to jump in and chase more solutions with you, but the above doesn't
prove your point, so I'm not ready to reject this one yet.
--
Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Phillips <phillips@arcor.de>
To: Andrew Morton <akpm@zip.com.au>
Cc: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>,
lkml <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: MM patches against 2.5.31
Date: Mon, 26 Aug 2002 21:34:19 +0200 [thread overview]
Message-ID: <E17jPcx-0002Yp-00@starship> (raw)
In-Reply-To: <3D6A8082.3775C5AB@zip.com.au>
On Monday 26 August 2002 21:24, Andrew Morton wrote:
> Daniel Phillips wrote:
> > On Monday 26 August 2002 17:29, Christian Ehrhardt wrote:
> > > On Mon, Aug 26, 2002 at 04:22:50PM +0200, Daniel Phillips wrote:
> > > > On Monday 26 August 2002 11:10, Christian Ehrhardt wrote:
> > > > > + * A special Problem is the lru lists. Presence on one of these lists
> > > > > + * does not increase the page count.
> > > >
> > > > Please remind me... why should it not?
> > >
> > > Pages that are only on the lru but not reference by anyone are of no
> > > use and we want to free them immediatly. If we leave them on the lru
> > > list with a page count of 1, someone else will have to walk the lru
> > > list and remove pages that are only on the lru.
> >
> > I don't understand this argument. Suppose lru list membership is worth a
> > page count of one. Then anyone who finds a page by way of the lru list can
> > safely put_page_testzero and remove the page from the lru list. Anyone who
> > finds a page by way of a page table can likewise put_page_testzero and clear
> > the pte, or remove the mapping and pass the page to Andrew's pagevec
> > machinery, which will eventually do the put_page_testzero. Anyone who
> > removes a page from a radix tree will also do a put_page_testzero. Exactly
> > one of those paths will result in the page count reaching zero, which tells
> > us nobody else holds a reference and it's time for __free_pages_ok. The page
> > is thus freed immediately as soon as there are no more references to it, and
> > does not hang around on the lru list.
> >
> > Nobody has to lock against the page count. Each put_page_testzero caller
> > only locks the data structure from which it's removing the reference.
> >
> > This seems so simple, what is the flaw?
>
> The flaw is in doing the put_page_testzero() outside of any locking
> which would prevent other CPUs from finding and "rescuing" the zero-recount
> page.
>
> CPUA:
> if (put_page_testzero()) {
> /* Here's the window */
> spin_lock(lru_lock);
> list_del(page->lru);
According to my assumption that lru list membership is (should be) worth one
page count, if testzero triggers here the page is not on the lru.
> CPUB:
>
> spin_lock(lru_lock);
> page = list_entry(lru);
> page_cache_get(page); /* If this goes from 0->1, we die */
It can't. You know that because you found the page on the lru, its count
must be at least one (again, according to assumption above).
> ...
> page_cache_release(page); /* double free */
I'd like to jump in and chase more solutions with you, but the above doesn't
prove your point, so I'm not ready to reject this one yet.
--
Daniel
--
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/
next prev parent reply other threads:[~2002-08-26 19:50 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-22 2:29 MM patches against 2.5.31 Andrew Morton
2002-08-22 2:29 ` Andrew Morton
2002-08-22 11:28 ` Christian Ehrhardt
2002-08-22 11:28 ` Christian Ehrhardt
2002-08-26 1:52 ` Andrew Morton
2002-08-26 1:52 ` Andrew Morton
2002-08-26 9:10 ` Christian Ehrhardt
2002-08-26 9:10 ` Christian Ehrhardt
2002-08-26 14:22 ` Daniel Phillips
2002-08-26 14:22 ` Daniel Phillips
2002-08-26 15:29 ` Christian Ehrhardt
2002-08-26 15:29 ` Christian Ehrhardt
2002-08-26 17:56 ` Daniel Phillips
2002-08-26 17:56 ` Daniel Phillips
2002-08-26 19:24 ` Andrew Morton
2002-08-26 19:24 ` Andrew Morton
2002-08-26 19:34 ` Daniel Phillips [this message]
2002-08-26 19:34 ` Daniel Phillips
2002-08-26 19:48 ` Christian Ehrhardt
2002-08-26 19:48 ` Christian Ehrhardt
2002-08-27 9:22 ` Christian Ehrhardt
2002-08-27 9:22 ` Christian Ehrhardt
2002-08-27 19:19 ` Andrew Morton
2002-08-27 19:19 ` Andrew Morton
2002-08-26 20:00 ` Christian Ehrhardt
2002-08-26 20:00 ` Christian Ehrhardt
2002-08-26 20:09 ` Daniel Phillips
2002-08-26 20:09 ` Daniel Phillips
2002-08-26 20:58 ` Christian Ehrhardt
2002-08-26 20:58 ` Christian Ehrhardt
2002-08-27 16:48 ` Daniel Phillips
2002-08-27 16:48 ` Daniel Phillips
2002-08-28 13:14 ` Christian Ehrhardt
2002-08-28 13:14 ` Christian Ehrhardt
2002-08-28 17:18 ` Daniel Phillips
2002-08-28 17:18 ` Daniel Phillips
2002-08-28 17:42 ` Andrew Morton
2002-08-28 17:42 ` Andrew Morton
2002-08-28 20:41 ` Daniel Phillips
2002-08-28 20:41 ` Daniel Phillips
2002-08-28 21:03 ` Andrew Morton
2002-08-28 21:03 ` Andrew Morton
2002-08-28 22:04 ` Daniel Phillips
2002-08-28 22:04 ` Daniel Phillips
2002-08-28 22:39 ` Andrew Morton
2002-08-28 22:39 ` Andrew Morton
2002-08-28 22:57 ` Daniel Phillips
2002-08-28 22:57 ` Daniel Phillips
2002-08-26 21:31 ` Andrew Morton
2002-08-26 21:31 ` Andrew Morton
2002-08-27 3:42 ` Benjamin LaHaise
2002-08-27 3:42 ` Benjamin LaHaise
2002-08-27 4:37 ` Andrew Morton
2002-08-27 4:37 ` Andrew Morton
2002-08-26 17:58 ` Linus Torvalds
2002-08-26 19:28 ` Rik van Riel
2002-08-30 23:03 ` [RFC] [PATCH] Include LRU in page count Daniel Phillips
2002-08-31 16:14 ` Christian Ehrhardt
2002-08-31 17:54 ` Andrew Morton
2002-08-31 19:47 ` Daniel Phillips
2002-08-31 20:26 ` Andrew Morton
2002-08-31 21:05 ` Daniel Phillips
2002-08-31 22:30 ` William Lee Irwin III
2002-09-01 3:36 ` Daniel Phillips
2002-09-01 21:32 ` Daniel Phillips
2002-09-01 22:09 ` Andrew Morton
2002-09-01 22:08 ` Daniel Phillips
2002-09-01 22:20 ` Daniel Phillips
2002-09-01 23:08 ` Andrew Morton
2002-09-01 23:19 ` Daniel Phillips
2002-09-01 23:28 ` William Lee Irwin III
2002-09-01 23:33 ` Daniel Phillips
2002-09-02 0:17 ` Andrew Morton
2002-09-02 0:30 ` Daniel Phillips
2002-09-02 1:50 ` Andrew Morton
2002-09-02 1:08 ` Rik van Riel
2002-09-02 17:23 ` Christian Ehrhardt
2002-09-02 18:01 ` Daniel Phillips
2002-09-05 4:42 ` [RFC] Alternative raceless page free Daniel Phillips
2002-09-05 12:34 ` Christian Ehrhardt
2002-09-05 15:21 ` Daniel Phillips
2002-09-05 16:04 ` Christian Ehrhardt
2002-09-05 16:10 ` Daniel Phillips
2002-09-05 16:31 ` Daniel Phillips
2002-09-05 18:06 ` [RFC] Alternative raceless page free, updated Daniel Phillips
2002-08-22 15:59 ` MM patches against 2.5.31 Steven Cole
2002-08-22 15:59 ` Steven Cole
2002-08-22 16:06 ` Martin J. Bligh
2002-08-22 16:06 ` Martin J. Bligh
2002-08-22 19:45 ` Steven Cole
2002-08-22 19:45 ` Steven Cole
2002-08-26 2:15 ` Andrew Morton
2002-08-26 2:15 ` Andrew Morton
2002-08-26 2:08 ` Martin J. Bligh
2002-08-26 2:08 ` Martin J. Bligh
2002-08-26 2:32 ` Andrew Morton
2002-08-26 2:32 ` Andrew Morton
2002-08-26 3:06 ` Steven Cole
2002-08-26 3:06 ` Steven Cole
-- strict thread matches above, loose matches on Subject: below --
2002-08-26 22:09 Ed Tomlinson
2002-08-26 22:09 ` Ed Tomlinson
2002-08-26 23:58 ` Andrew Morton
2002-08-26 23:58 ` Andrew Morton
2002-08-27 0:13 ` Rik van Riel
2002-08-27 0:13 ` Rik van Riel
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=E17jPcx-0002Yp-00@starship \
--to=phillips@arcor.de \
--cc=akpm@zip.com.au \
--cc=ehrhardt@mathematik.uni-ulm.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.