public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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