mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Franck Bui-Huu" <fbuihuu@gmail.com>
To: "Hugh Dickins" <hugh@veritas.com>
Cc: "Nadia Derbey" <Nadia.Derbey@bull.net>, "Andi Kleen" <ak@suse.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: unable to mmap /dev/kmem
Date: Sat, 20 Jan 2007 18:19:47 +0100	[thread overview]
Message-ID: <61ec3ea90701200919kd6593bdl8dcd47824ed03f49@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0701191634070.6398@blonde.wat.veritas.com>

On 1/19/07, Hugh Dickins <hugh@veritas.com> wrote:
>
> Apology surely accepted, it's a confusing area (inevitably: in a driver
> for mem, the distinction between addresses and offsets become blurred).
>
> But please note, the worst of it was, that your patch comment gave no
> hint that you were knowingly changing its behaviour on the "main"
> architectures: it reads as if you were simply fixing it up on a
> few less popular architectures where an anomaly had been missed.
>

Because I was thinking that the expected behaviour was the one
implemented before 2.6.12. So I really thought to fix a bug, again
sorry for not having checked the history...

That said, it's really confusing to pass a virtual address as an
offset because:

    (a) mmap() has always worked with offset not addresses;

    (b) the kernel will treat this virtual address as an offset
        until kmem driver convert it back to a virtual
        address. And it seems that during this convertion the
        lowest bits of the virtual address will be lost...

Maybe read/write behaviours should be changed to use the offset as an
offset and not as a virtual address.

> > > 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.
> >
> > yes it doesn't seems to be used. In my case, I was just playing with
> > it when I submitted the patch but have no real usages.
>
> Have I got it right, that actually the problem you thought you were
> fixing does not even exist?

yes, see above.

>  __pa was already doing the right thing on
> all architectures, wasn't it?  So we can simply ask Linus to revert your
> patch?

yes we can if the desired behaviour is the one introduced by 2.6.12.

> I don't think your PFN_DOWN or virt_to_phys were improvements:
> though mem.c happens to live in drivers/char/, imagine it under mm/.
>

I don't get your point here. Do you mean that virt_to_phys() is only
meant for drivers ? If so, I would have said that virt_to_phys() is
prefered once boot memory init is finished...

		Franck

  reply	other threads:[~2007-01-20 17:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-18 16:47 Nadia Derbey
2007-01-18 18:04 ` Hugh Dickins
2007-01-19  6:26   ` Nadia Derbey
2007-01-19  9:10   ` Nadia Derbey
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 [this message]
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=61ec3ea90701200919kd6593bdl8dcd47824ed03f49@mail.gmail.com \
    --to=fbuihuu@gmail.com \
    --cc=Nadia.Derbey@bull.net \
    --cc=ak@suse.de \
    --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

Powered by JetHome