From: Nadia Derbey <Nadia.Derbey@bull.net>
To: Hugh Dickins <hugh@veritas.com>
Cc: Franck Bui-Huu <fbuihuu@gmail.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: unable to mmap /dev/kmem
Date: Fri, 19 Jan 2007 10:10:47 +0100 [thread overview]
Message-ID: <45B08B17.3060807@bull.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0701181743340.25435@blonde.wat.veritas.com>
Hugh Dickins wrote:
> On Thu, 18 Jan 2007, Nadia Derbey wrote:
>
>>Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
>>I get an EIO error on a 2.6.20-rc4.
>>This is something that used to work on older kernels.
>>
>>Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whether
>>pfn is correctly computed there: shouldn't we have something like
>>
>>pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) +
>> __pa(vma->vm_pgoff << PAGE_SHIFT);
>>
>>instead of
>>
>>pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) + vma->vm_pgoff;
>>
>>Or may be should I substract PAGE_OFFSET from the value I get from System.map
>>before mmapping /dev/kmem?
>
>
> Sigh, you're right, 2.6.19 messed that up completely.
> No, you never had to subtract PAGE_OFFSET from that address
> in the past, and you shouldn't have to do so now.
>
> Please revert the offending patch below, and then maybe Franck
> can come up with a patch which preserves the original behaviour
> on architectures which used to work (e.g. i386), while fixing
> it for those architectures (which are they?) that did not.
>
> I guess it's reassuring to know that not many are actually
> using mmap of /dev/kmem, so you're the first to notice: thanks.
>
I find this feature very interesting from a testing perspective. Now,
since I don't like the idea of being the only one that uses a feature
(not maintained - may be even to be removed?) may be you could advice me
on a more broadly used way to get the value of a non exported kernel
variable from inside a test running in user mode? should I use /dev/mem
instead? But in that case, I should do the virtual to physical
conversion myself, right?
Regards,
Nadia
next prev parent reply other threads:[~2007-01-19 9:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-18 16:47 unable to mmap /dev/kmem Nadia Derbey
2007-01-18 18:04 ` Hugh Dickins
2007-01-19 6:26 ` Nadia Derbey
2007-01-19 9:10 ` Nadia Derbey [this message]
2007-01-19 16:33 ` Hugh Dickins
2007-01-19 16:57 ` Arjan van de Ven
2007-01-19 17:12 ` Hugh Dickins
2007-01-19 17:27 ` Arjan van de Ven
2007-01-19 17:52 ` Hugh Dickins
2007-01-19 21:57 ` Andi Kleen
2007-01-19 11:31 ` Franck Bui-Huu
2007-01-19 17:02 ` Hugh Dickins
2007-01-20 17:19 ` Franck Bui-Huu
2007-01-21 9:56 ` Hugh Dickins
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=45B08B17.3060807@bull.net \
--to=nadia.derbey@bull.net \
--cc=fbuihuu@gmail.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.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