Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754241AbbKLT3f (ORCPT ); Thu, 12 Nov 2015 14:29:35 -0500 Received: from mail-io0-f175.google.com ([209.85.223.175]:35583 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754070AbbKLT3d (ORCPT ); Thu, 12 Nov 2015 14:29:33 -0500 MIME-Version: 1.0 In-Reply-To: <20151112080059.GA6835@gmail.com> References: <1447111090-8526-1-git-send-email-kirill.shutemov@linux.intel.com> <20151110123429.GE19187@pd.tnic> <20151110135303.GA11246@node.shutemov.name> <20151110144648.GG19187@pd.tnic> <20151110150713.GA11956@node.shutemov.name> <20151110170447.GH19187@pd.tnic> <20151111095101.GA22512@pd.tnic> <20151112074854.GA5376@gmail.com> <20151112075758.GA20702@node.shutemov.name> <20151112080059.GA6835@gmail.com> Date: Thu, 12 Nov 2015 11:29:32 -0800 X-Google-Sender-Auth: qpkl8BvOQd6VndbOHXewfXF5440 Message-ID: Subject: Re: [PATCH] x86/mm: fix regression with huge pages on PAE From: Linus Torvalds To: Ingo Molnar Cc: "Kirill A. Shutemov" , Borislav Petkov , "Kirill A. Shutemov" , Peter Anvin , Thomas Gleixner , Ingo Molnar , Andrew Morton , linux-mm , Linux Kernel Mailing List , "the arch/x86 maintainers" , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Konrad Rzeszutek Wilk , elliott@hpe.com, Boris Ostrovsky , Toshi Kani Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2072 Lines: 47 On Thu, Nov 12, 2015 at 12:00 AM, Ingo Molnar 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/