linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	ncunningham@cyclades.com, Daniel Phillips <phillips@arcor.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management <linux-mm@kvack.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Andrea Arcangeli <andrea@suse.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [RFC][patch 0/2] mm: remove PageReserved
Date: Tue, 9 Aug 2005 12:15:19 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.61.0508091145570.11660@goblin.wat.veritas.com> (raw)
In-Reply-To: <42F88514.9080104@yahoo.com.au>

On Tue, 9 Aug 2005, Nick Piggin wrote:
> Hugh Dickins wrote:
> > I think Nick is treating the "use" of PageReserved in ioremap much too
> > reverentially.  Fine to leave its removal from there to a later stage,
> > but why shouldn't that also be removed?
> 
> Well, as far as I had been able to gather, ioremap is trying to
> ensure it does indeed only hit one of these holes, and not valid
> RAM.

Who can tell?  rmk's mail sugggests it should work on some valid RAM.

ioremap is making a similar check to the one remap_pfn_range used
to make; but I see no good reason for it at all.  ioremap should be
allowed to map whatever the caller asked, just as memset is allowed
to set whatever the caller asked.  It's up to the caller to get it
right, not for the function to demand the added reassurance of some
mysterious page flag being set.

(But in what I said earlier about VM_RESERVE making sure wrong pages
not freed, I was confused and confusing ioremap with remap_pfn_range.)

> I thought the fact that it *won't* bail out when encountering
> kernel text or remap_pfn_range'ed pages was only due to PG_reserved
> being the proverbial jack of all trades, master of none.
> 
> I could be wrong here though.
> 
> But in either case: I agree that it is probably not a great loss
> to remove the check, although considering it will be needed for
> swsusp anyway...

swsusp (and I think crashdump has a similar need) is a very different
case: it's approaching memory from the zone/mem_map end, with no(?) idea
of how the different pages are used: needs to save all the info while
avoiding those areas which would give trouble.  I can well imagine it
needs either a page flag or a table lookup to decide that.

But ioremap and remap_pfn_range are coming from drivers which (we hope)
know what they're mapping these particular areas for.  If it's provable
that the meaning which swsusp needs is equally usable for a little sanity
check in ioremap, okay, but I'm sceptical.

Hugh
--
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:[~2005-08-09 11:15 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-07  3:28 Nick Piggin
2005-08-07  3:29 ` [patch 1/2] mm: remap ZERO_PAGE mappings Nick Piggin
2005-08-07  3:30   ` [patch 2/2] mm: core remove PageReserved Nick Piggin
2005-08-08 21:09 ` [RFC][patch 0/2] mm: " Daniel Phillips
2005-08-08 21:24   ` Daniel Phillips
2005-08-08 21:54     ` Andrew Morton
2005-08-09 23:23       ` [RFC][PATCH] Rename PageChecked as PageMiscFS Daniel Phillips
2005-08-10  7:48         ` Hugh Dickins
2005-08-10  8:06           ` Daniel Phillips
2005-08-10 22:12       ` Daniel Phillips
2005-08-10 22:23         ` Daniel Phillips
2005-08-10 22:34           ` Trond Myklebust
2005-08-10 22:57             ` Daniel Phillips
2005-08-10 23:23               ` Trond Myklebust
2005-08-11  9:42               ` David Howells
2005-08-10 23:42           ` Adrian Bunk
2005-08-11  9:46           ` David Howells
2005-08-12  2:34             ` Daniel Phillips
2005-08-12 12:32             ` David Howells
2005-08-11  9:31         ` David Howells
2005-08-11  9:26       ` David Howells
2005-08-12  3:29         ` Daniel Phillips
2005-08-12 12:41         ` David Howells
2005-08-12 13:28           ` Hugh Dickins
2005-08-16 13:59           ` Pavel Machek
2005-08-18 14:33           ` David Howells
2005-08-18 22:27             ` Pavel Machek
2005-08-19 10:04             ` David Howells
2005-08-19 16:31               ` Daniel Phillips
2005-08-20 10:45               ` David Howells
2005-08-20 20:21                 ` Daniel Phillips
2005-08-10 13:13     ` [RFC][patch 0/2] mm: remove PageReserved David Howells
2005-08-10 13:34       ` Daniel Phillips
2005-08-10 14:27       ` David Howells
2005-08-10 23:19         ` Daniel Phillips
2005-08-11 10:49         ` David Howells
2005-08-12 19:34           ` Daniel Phillips
2005-08-15 13:15           ` David Howells
2005-08-16  1:53             ` Daniel Phillips
2005-08-16 10:28             ` David Howells
2005-08-09  0:15   ` Nick Piggin
2005-08-09  8:51     ` Benjamin Herrenschmidt
2005-08-09  9:49       ` Nick Piggin
2005-08-09 19:19         ` Daniel Phillips
2005-08-09 19:22         ` Daniel Phillips
2005-08-10 21:50           ` Pavel Machek
2005-08-10 21:56             ` Martin J. Bligh
2005-08-11 10:36               ` Rafael J. Wysocki
2005-08-12 19:56                 ` Daniel Phillips
2005-08-12 22:20                   ` Rafael J. Wysocki
2005-08-12 23:04                     ` Daniel Phillips
2005-08-13  7:06                       ` Rafael J. Wysocki
2005-08-11 10:26             ` Rafael J. Wysocki
2005-08-09 11:25       ` Hugh Dickins
2005-08-09 14:31         ` Benjamin Herrenschmidt
2005-08-09 14:50           ` Hugh Dickins
2005-08-09 14:49             ` Benjamin Herrenschmidt
2005-08-09 15:36               ` Hugh Dickins
2005-08-09 21:27                 ` Daniel Phillips
2005-08-09 19:14     ` Daniel Phillips
2005-08-09 20:17       ` Hugh Dickins
2005-08-09 20:52         ` Daniel Phillips
2005-08-09  4:39   ` Nigel Cunningham
2005-08-09  4:59     ` Nick Piggin
2005-08-09  5:11       ` Nigel Cunningham
2005-08-09  5:20         ` Nick Piggin
2005-08-09  5:30           ` Nigel Cunningham
2005-08-09  7:08       ` Russell King
2005-08-09  8:38         ` Arjan van de Ven
2005-08-09  9:31           ` Nick Piggin
2005-08-09  9:49             ` Arjan van de Ven
2005-08-09  9:57               ` Nick Piggin
2005-08-09 10:24             ` Rafael J. Wysocki
2005-08-09  8:53         ` Benjamin Herrenschmidt
2005-08-09  9:15         ` Hugh Dickins
2005-08-09 10:27           ` Nick Piggin
2005-08-09 11:15             ` Hugh Dickins [this message]
2005-08-09 13:15               ` Nick Piggin
2005-08-09 13:26                 ` Arjan van de Ven
2005-08-09 14:28               ` Benjamin Herrenschmidt
2005-08-09 14:47                 ` Hugh Dickins
2005-08-09 19:49           ` Roman Zippel
2005-08-09  9:29         ` Nick Piggin
2005-08-09 19:40           ` Russell King
2005-08-09 14:38         ` Martin J. Bligh
2005-08-09 19:41           ` Russell King
2005-08-09 20:51             ` Linus Torvalds
2005-08-09 21:16             ` Martin J. Bligh
2005-08-09 21:51               ` Martin J. Bligh
2005-08-10  9:27             ` Benjamin Herrenschmidt
2005-08-11  9:09               ` Nick Piggin

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=Pine.LNX.4.61.0508091145570.11660@goblin.wat.veritas.com \
    --to=hugh@veritas.com \
    --cc=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ncunningham@cyclades.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=phillips@arcor.de \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox