linux-kernel - Re: [PATCH] x86/mm: fix regression with huge pages on PAE

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:	Thu, 12 Nov 2015 11:29:32 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	"Kirill A. Shutemov" <kirill@...temov.name>,
	Borislav Petkov <bp@...en8.de>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Peter Anvin <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-mm <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Jürgen Groß <jgross@...e.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	elliott@....com, Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Toshi Kani <toshi.kani@....com>
Subject: Re: [PATCH] x86/mm: fix regression with huge pages on PAE

On Thu, Nov 12, 2015 at 12:00 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> So we already have PHYSICAL_PAGE_MASK, why not introduce PHYSICAL_PMD_MASK et al,
> instead of uglifying the code?

I think that's the right thing here.

> But, what problems do you expect with having a wider mask than its primary usage?
> If it's used for 32-bit values it will be truncated down safely. (But I have not
> tested it, so I might be missing some complication.)

No, it will not necessarily be truncated down. If we were to make the
regular PAGE_MASK etc that are normally used for virtual addresses be
"ull", it might easily make some calcyulations be done in 64 bits
instead. Sure, they'll probably be truncated down *eventually* when
you actually store them to some 32-bit thing, but I'd worry about it.

An example of a situation where over-long types cause problems is
simply in variadic functions (typically printk, but they do happen in
other places). Writing

    printk("page offset = %ul\n", address & PAGE_MASK);

makes sense. In the VM, addresses really are "unsigned long". But just
imagine how wrong the above goes if PAGE_MASK was made "ull".

So no, widening masks to the maximal possible type is not the answer.
They need to be the natural size.

Another possibility would be to simply make masks be _signed_ longs.
That can has its own set of problems, but it does mean that when the
mask has high bits set and it gets expanded to a wider type, the
normal C rules just do the RightThing(tm).

We've occasionally done that very explicitly. Just see how
PHYSICAL_PAGE_MASK is defined in terms of a signed PAGE_MASK.

I have this dim memory of us playing around with just making PAGE_SIZE
(and thus PAGE_MASK) always be signed, but that it caused other
problems. Signed types have downsides too.

                   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/