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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 08 Nov 2011 13:08:56 -0500
From:	Mark Salter <msalter@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	"JACQUIOT-XID, Aurelien" <a-jacquiot@...com>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PULL] Add support for Texas Instruments C6X architecture

On Sat, 2011-11-05 at 15:38 -0700, Linus Torvalds wrote:
> 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?
> 

Having a little time to think about this some more, I'm going to take
another crack at it. Defining __pa/__va with PAGE_OFFSET as they are
currently creates a physical space which doesn't match the hardware
when PAGE_OFFSET is non-zero.

For arches using device tree support, that means that the physical
addresses in the device tree are either linux-specific or early boot
code would have to go through the tree to fixup the "hardware physical"
addresses so that they are "linux physical" addresses for the kernel.

For arches not using device tree, the physical addresses used in headers
or printed out in log messages won't match the hardware documentation.
Not a huge problem, but a PITA for maintenance/debug.

--Mark


--
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/