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:	Sat, 05 Nov 2011 17:39:41 -0400
From:	Mark Salter <msalter@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PULL] Add support for Texas Instruments C6X architecture

On Fri, 2011-11-04 at 18:23 -0700, Linus Torvalds wrote:
> On Tue, Nov 1, 2011 at 1:27 PM, Mark Salter <msalter@...hat.com> wrote:
> >
> > Please pull this port of Linux to the Texas Instruments C6X architecture.
> > The patches have all been acked and available for some time in linux-net.
> 
> Ugh. So I finally was about to merge this, but wanted to check the
> non-C6x files before I did.
> 
> And that seems broken. If I read that code correctly, your
> ARCH_PFN_OFFSET thing is just insane, and thinking that "pfn_valid()"
> has anything to do with PAGE_OFFSET is crazy.
> 
> PAGE_OFFSET is about *virtual* addresses. It has absolutely nothing to
> do with pfn's that are the physical page number. virt_to_pfn() already
> corrects for PAGE_OFFSET (that part of your patch looks fine), your
> change to *also* do it in pfn_valid() looks entirely bogus to me.
> 
> I'm not pulling new architectures that look like they will break old
> ones, and do odd things to generic files.

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.

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)?

If PAGE_OFFSET should be zero for NOMMU, then the existing generic
page.h is wrong to use CONFIG_KERNEL_RAM_BASE_ADDRESS. Also,
free_area_init() in mm/page_alloc.c uses __pa(PAGE_OFFSET) which
seems wrong and is definitely broken in the NOMMU case if PAGE_OFFSET
must be zero on an arch where the RAM base is non-zero.

So what do I need to do to get this straightened out?

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