On Tue, Sep 15, 2009 at 12:16, Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx> wrote:
On Tue, 15 Sep 2009, Wu Fengguang wrote:
On Tue, Sep 15, 2009 at 11:09:39AM +0800, KAMEZAWA Hiroyuki wrote:
On Tue, 15 Sep 2009 10:18:51 +0800
Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote:
Hi Kame,
Here are 3 more kmem patches in my queue. Comments are welcome.
If you feel good about them, I can send all recent kmem cleanup
patches for you.
This is my quick hack. But I don't want to be an obstacle for you.
So, I'll wait for your updates.
Thanks. This is also a bug fix: vmalloc_to_page() will otherwise BUG()
on !is_vmalloc_or_module_addr() pages.
==
Now, /dev/kmem's read/write vmalloc area doesn't do
range-check. Because vread/vwrite traverse vmalloc area list
under system-wide spinlock, it's better to avoid unnecessary
to do unnecessary calls to vread/vwrite.
is_vmalloc_or_module_addr() could be put to either read_kmem()
or aligned_vread(), and I'm fine with both.
It looks like vread can be shared by kmem and kcore :)
And, vread/vwrite returns 0 if we accessed memory holes.
We can avoid copy-to-user in read side, we just ignore at write.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
---
drivers/char/mem.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
Sorry guys, I'm picking this mail pretty much at random
as something to reply to.
I'm interested to notice such work going on in drivers/char/mem.c,
and don't have time to join in - you interact a lot faster than I
manage, and I've other priorities to attend to; but thought I should
at least send over the patch I've been including in my private debug
kernels for the last couple of years (rebased to 2.6.31), which lets
me peek and poke into /dev/kmem as I occasionally wish.
Warning: it may be rubbish, it may just be a hack which appeared to
work for me the last time I tried, on a particular address range of a
particular set of configurations of a particular set of architectures
(x86_32, x86_64, powerpc64). I've never thought it through enough to
consider submitting, but it _might_ contain something useful for you
to factor into your own efforts.
Sorry for chucking it over the wall to you in this way, but I guess
that's better than just sitting quietly on it for a few more years.
Certainly-Not-Signed-off-by: Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx>
---
drivers/char/mem.c | 265 +++++++++++++++----------------------------
fs/read_write.c | 9 +
2 files changed, 105 insertions(+), 169 deletions(-)
but if completed would also remove vread() and vwrite() from
include/linux/vmalloc.h
mm/nommu.c
mm/vmalloc.c
--- 2.6.31/drivers/char/mem.c 2009-09-09 23:13:59.000000000 +0100
+++ 2.6.31d/drivers/char/mem.c 2009-09-10 09:38:30.000000000 +0100
-#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
- /* we don't have page 0 mapped on sparc and m68k.. */
Is this `feature' removed?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
