linux-kernel - Re: [PULL] Add support for Texas Instruments C6X architecture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 5 Nov 2011 15:38:15 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mark Salter <msalter@...hat.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PULL] Add support for Texas Instruments C6X architecture

On Sat, Nov 5, 2011 at 2:39 PM, Mark Salter <msalter@...hat.com> wrote:
>
> Okay, first of all, it doesn't break any old ones. There is one arch
> that currently uses asm-generic/page.h (blackfin) and that one uses a
> PAGE_OFFSET of 0x0 and has physical RAM starting at 0x0. My patch (wrong
> as it may otherwise be) won't break blackfin.

Ok. And I didn't notice that when you added the PFN_OFFSET, you did
actually remove the subtraction of PAGE_OFFSET from the
virtual->physical translation.

But I don't really understand why you did that. It makes very little sense.

> Are you saying that PAGE_OFFSET should always be zero in the NOMMU case?
> Or that ARCH_PFN_OFFSET shouldn't use PAGE_OFFSET (five existing arches
> use that same definition)?

So If the memory is mapped at some non-zero offset, what would make
*sense* to me is have the old

   #define __pa(x) ((unsigned long)(x) -- PAGE_OFFSET)

and that should already make sure that then the PFN is in the right
range, and doesn't need any fixups.

That's what the old version of the file did, and that seems to be a
sensible model. Why isn't it?

                      Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/