All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: Hugh Dickins <hugh@veritas.com>, Nick Piggin <npiggin@suse.de>,
	linux-kernel@vger.kernel.org, pj@sgi.com
Subject: Re: Pagecache: find_or_create_page does not call a proper page allocator function
Date: Tue, 24 Apr 2007 12:49:22 -0700	[thread overview]
Message-ID: <20070424124922.d406aac1.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0704241234341.12753@schroedinger.engr.sgi.com>

On Tue, 24 Apr 2007 12:34:53 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> > Not as metadata, no.  But someone (let's hope only root, though I may
> > be wrong on that) can map any part of the block device into userspace.
> 
> Concurrent access to a block device by a filesystem and the user? That 
> cannot go over well. If one just reads then I would expect that a copy
> of the metadata becomes available to the user. Also you cannot migrate 
> pages that have multiple references (which is the case here if the 
> filesystem uses the page cache for the metadata) unless the user has 
> special priviledges and uses special command options.
> 
> A page that has references that cannot be accounted for by page migration 
> is never migrated. I would assume that the filesystem at minimum takes a 
> refcount on the page used for metadata.
> 
> If the filesystem would not take a refcount then it would already be in 
> trouble because the page may then be evicted at any time.

No, think of the following scenario:

- file I/O causes a read of an ext2 file's bitmap.  The bitmap is
  brought into /dev/hda1's pagecache using !__GFP_HIGHMEM

- references are released against that page and it's now just clean
  reclaimable pagecache

- someone (say, an online filesystem checker or something) mmaps
  /dev/hda1 and reads that page.

- migration comes alnog and migrates that page into highmem

- file I/O causes a read of that bitmap again.  We find it in
  /dev/hda's pagecache.

  Here's set_bh_page().

	void set_bh_page(struct buffer_head *bh,
			struct page *page, unsigned long offset)
	{
		bh->b_page = page;
		BUG_ON(offset >= PAGE_SIZE);
		if (PageHighMem(page))
			/*
			 * This catches illegal uses and preserves the offset:
			 */
			bh->b_data = (char *)(0 + offset);
		else
			bh->b_data = page_address(page) + offset;
	}

- ext2 now tries to access the bits in the bitmap via page->bh->b_data

- game over

  reply	other threads:[~2007-04-24 19:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 21:11 Pagecache: find_or_create_page does not call a proper page allocator function Christoph Lameter
2007-04-23 21:29 ` Andrew Morton
2007-04-23 21:37   ` Christoph Lameter
2007-04-23 22:33   ` Christoph Lameter
2007-04-23 22:42     ` Christoph Lameter
2007-04-23 22:42     ` Andrew Morton
2007-04-24 13:09       ` Hugh Dickins
2007-04-24 17:11         ` Andrew Morton
2007-04-24 19:06           ` Hugh Dickins
2007-04-24 19:55             ` Christoph Lameter
2007-04-24 20:16               ` Hugh Dickins
2007-04-24 20:30                 ` Christoph Lameter
2007-04-24 20:42                   ` Andrew Morton
2007-04-24 20:44                     ` Christoph Lameter
2007-04-24 20:53                       ` Andrew Morton
2007-04-24 20:58                         ` Christoph Lameter
2007-04-24 21:24                           ` Andrew Morton
2007-04-24 21:28                             ` Christoph Lameter
2007-04-24 17:38         ` Christoph Lameter
2007-04-24 17:45           ` Hugh Dickins
2007-04-24 17:48             ` Christoph Lameter
2007-04-24 17:51             ` Andrew Morton
2007-04-24 17:56               ` Christoph Lameter
2007-04-24 17:45         ` Christoph Lameter
2007-04-24 18:53           ` Hugh Dickins
2007-04-24 19:34             ` Christoph Lameter
2007-04-24 19:49               ` Andrew Morton [this message]
2007-04-24 19:59                 ` Christoph Lameter
2007-04-24 20:10                   ` Andrew Morton
2007-04-24 20:12                     ` Christoph Lameter
2007-04-24 20:20                       ` Andrew Morton

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=20070424124922.d406aac1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=pj@sgi.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.