From: Wu Fengguang <fengguang.wu@intel.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "Huang, Ying" <ying.huang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Ingo Molnar <mingo@elte.hu>,
Nick Piggin <npiggin@suse.de>, Andi Kleen <andi@firstfloor.org>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Christoph Lameter <cl@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] vmalloc: simplify vread()/vwrite()
Date: Thu, 7 Jan 2010 13:24:03 +0800 [thread overview]
Message-ID: <20100107052403.GA25203@localhost> (raw)
In-Reply-To: <20100107122304.b5c1d777.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, Jan 07, 2010 at 11:23:04AM +0800, KAMEZAWA Hiroyuki wrote:
> On Thu, 07 Jan 2010 11:15:41 +0800
> Huang Ying <ying.huang@intel.com> wrote:
>
> > > >
> > > > > The page_is_ram() check is necessary because kmap_atomic() is not
> > > > > designed to work with non-RAM pages.
> > > > >
> > > > I think page_is_ram() is not a complete method...on x86, it just check
> > > > e820's memory range. checking VM_IOREMAP is better, I think.
> > >
> > > (double check) Not complete or not safe?
> > >
> > > EFI seems to not update e820 table by default. Ying, do you know why?
> >
> > In EFI system, E820 table is constructed from EFI memory map in boot
> > loader, so I think you can rely on E820 table.
> >
> Yes, we can rely on. But concerns here is that we cannot get any
> information of ioremap via e820 map.
>
> But yes,
> == ioremap()
> 140 for (pfn = phys_addr >> PAGE_SHIFT;
> 141 (pfn << PAGE_SHIFT) < (last_addr & PAGE_MASK);
> 142 pfn++) {
> 143
> 144 int is_ram = page_is_ram(pfn);
> 145
> 146 if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
> 147 return NULL;
> 148 WARN_ON_ONCE(is_ram);
> 149 }
> ==
> you'll get warned before access if "ram" area is remapped...
Right.
> But, about this patch, it seems that page_is_ram() is not free from architecture
> dependecy.
Yes this is a problem. We can provide a generic page_is_ram() as below.
And could further convert the existing x86 (and others) page_is_ram()
to be resource-based -- since at least for now the e820 table won't be
updated on memory hotplug.
Thanks,
Fengguang
---
include/linux/ioport.h | 2 ++
kernel/resource.c | 18 ++++++++++++++++++
2 files changed, 20 insertions(+)
--- linux-mm.orig/kernel/resource.c 2010-01-07 12:40:55.000000000 +0800
+++ linux-mm/kernel/resource.c 2010-01-07 13:13:46.000000000 +0800
@@ -297,6 +297,24 @@ int walk_system_ram_range(unsigned long
#endif
+static int __page_is_ram(unsigned long pfn, unsigned long nr_pages, void *arg)
+{
+ int *is_ram = arg;
+
+ *is_ram = 1;
+
+ return 1;
+}
+
+int __attribute__((weak)) page_is_ram(unsigned long pagenr)
+{
+ int is_ram = 0;
+
+ walk_system_ram_range(pagenr, 1, &is_ram, __page_is_ram);
+
+ return is_ram;
+}
+
/*
* Find empty slot in the resource tree given range and alignment.
*/
--- linux-mm.orig/include/linux/ioport.h 2010-01-07 13:11:43.000000000 +0800
+++ linux-mm/include/linux/ioport.h 2010-01-07 13:12:37.000000000 +0800
@@ -188,5 +188,7 @@ extern int
walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
void *arg, int (*func)(unsigned long, unsigned long, void *));
+extern int page_is_ram(unsigned long pagenr);
+
#endif /* __ASSEMBLY__ */
#endif /* _LINUX_IOPORT_H */
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "Huang, Ying" <ying.huang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Ingo Molnar <mingo@elte.hu>,
Nick Piggin <npiggin@suse.de>, Andi Kleen <andi@firstfloor.org>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Christoph Lameter <cl@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] vmalloc: simplify vread()/vwrite()
Date: Thu, 7 Jan 2010 13:24:03 +0800 [thread overview]
Message-ID: <20100107052403.GA25203@localhost> (raw)
In-Reply-To: <20100107122304.b5c1d777.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, Jan 07, 2010 at 11:23:04AM +0800, KAMEZAWA Hiroyuki wrote:
> On Thu, 07 Jan 2010 11:15:41 +0800
> Huang Ying <ying.huang@intel.com> wrote:
>
> > > >
> > > > > The page_is_ram() check is necessary because kmap_atomic() is not
> > > > > designed to work with non-RAM pages.
> > > > >
> > > > I think page_is_ram() is not a complete method...on x86, it just check
> > > > e820's memory range. checking VM_IOREMAP is better, I think.
> > >
> > > (double check) Not complete or not safe?
> > >
> > > EFI seems to not update e820 table by default. Ying, do you know why?
> >
> > In EFI system, E820 table is constructed from EFI memory map in boot
> > loader, so I think you can rely on E820 table.
> >
> Yes, we can rely on. But concerns here is that we cannot get any
> information of ioremap via e820 map.
>
> But yes,
> == ioremap()
> 140 for (pfn = phys_addr >> PAGE_SHIFT;
> 141 (pfn << PAGE_SHIFT) < (last_addr & PAGE_MASK);
> 142 pfn++) {
> 143
> 144 int is_ram = page_is_ram(pfn);
> 145
> 146 if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
> 147 return NULL;
> 148 WARN_ON_ONCE(is_ram);
> 149 }
> ==
> you'll get warned before access if "ram" area is remapped...
Right.
> But, about this patch, it seems that page_is_ram() is not free from architecture
> dependecy.
Yes this is a problem. We can provide a generic page_is_ram() as below.
And could further convert the existing x86 (and others) page_is_ram()
to be resource-based -- since at least for now the e820 table won't be
updated on memory hotplug.
Thanks,
Fengguang
---
include/linux/ioport.h | 2 ++
kernel/resource.c | 18 ++++++++++++++++++
2 files changed, 20 insertions(+)
--- linux-mm.orig/kernel/resource.c 2010-01-07 12:40:55.000000000 +0800
+++ linux-mm/kernel/resource.c 2010-01-07 13:13:46.000000000 +0800
@@ -297,6 +297,24 @@ int walk_system_ram_range(unsigned long
#endif
+static int __page_is_ram(unsigned long pfn, unsigned long nr_pages, void *arg)
+{
+ int *is_ram = arg;
+
+ *is_ram = 1;
+
+ return 1;
+}
+
+int __attribute__((weak)) page_is_ram(unsigned long pagenr)
+{
+ int is_ram = 0;
+
+ walk_system_ram_range(pagenr, 1, &is_ram, __page_is_ram);
+
+ return is_ram;
+}
+
/*
* Find empty slot in the resource tree given range and alignment.
*/
--- linux-mm.orig/include/linux/ioport.h 2010-01-07 13:11:43.000000000 +0800
+++ linux-mm/include/linux/ioport.h 2010-01-07 13:12:37.000000000 +0800
@@ -188,5 +188,7 @@ extern int
walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
void *arg, int (*func)(unsigned long, unsigned long, void *));
+extern int page_is_ram(unsigned long pagenr);
+
#endif /* __ASSEMBLY__ */
#endif /* _LINUX_IOPORT_H */
--
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>
next prev parent reply other threads:[~2010-01-07 5:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-07 1:24 [RFC][PATCH] vmalloc: simplify vread()/vwrite() Wu Fengguang
2010-01-07 1:24 ` Wu Fengguang
2010-01-07 1:38 ` KAMEZAWA Hiroyuki
2010-01-07 1:38 ` KAMEZAWA Hiroyuki
2010-01-07 2:50 ` Wu Fengguang
2010-01-07 2:50 ` Wu Fengguang
2010-01-07 2:57 ` KAMEZAWA Hiroyuki
2010-01-07 2:57 ` KAMEZAWA Hiroyuki
2010-01-07 3:21 ` Wu Fengguang
2010-01-07 3:21 ` Wu Fengguang
2010-01-07 3:15 ` Huang Ying
2010-01-07 3:15 ` Huang Ying
2010-01-07 3:23 ` KAMEZAWA Hiroyuki
2010-01-07 3:23 ` KAMEZAWA Hiroyuki
2010-01-07 5:24 ` Wu Fengguang [this message]
2010-01-07 5:24 ` Wu Fengguang
2010-01-07 5:39 ` KAMEZAWA Hiroyuki
2010-01-07 5:39 ` KAMEZAWA Hiroyuki
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=20100107052403.GA25203@localhost \
--to=fengguang.wu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=tj@kernel.org \
--cc=ying.huang@intel.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.