From: Linus Torvalds <torvalds@linux-foundation.org> To: Ingo Molnar <mingo@kernel.org> Cc: "Kirill A. Shutemov" <kirill@shutemov.name>, "Borislav Petkov" <bp@alien8.de>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, "Peter Anvin" <hpa@zytor.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@redhat.com>, "Andrew Morton" <akpm@linux-foundation.org>, linux-mm <linux-mm@kvack.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "the arch/x86 maintainers" <x86@kernel.org>, "Jürgen Groß" <jgross@suse.com>, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, elliott@hpe.com, "Boris Ostrovsky" <boris.ostrovsky@oracle.com>, "Toshi Kani" <toshi.kani@hpe.com> Subject: Re: [PATCH] x86/mm: fix regression with huge pages on PAE Date: Thu, 12 Nov 2015 11:29:32 -0800 [thread overview] Message-ID: <CA+55aFx84N=o=RWJTy2Bjs-GNjKQuCZYyVWDTgOtRq3-qSO-yg@mail.gmail.com> (raw) In-Reply-To: <20151112080059.GA6835@gmail.com> On Thu, Nov 12, 2015 at 12:00 AM, Ingo Molnar <mingo@kernel.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
WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org> To: Ingo Molnar <mingo@kernel.org> Cc: "Kirill A. Shutemov" <kirill@shutemov.name>, "Borislav Petkov" <bp@alien8.de>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, "Peter Anvin" <hpa@zytor.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@redhat.com>, "Andrew Morton" <akpm@linux-foundation.org>, linux-mm <linux-mm@kvack.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "the arch/x86 maintainers" <x86@kernel.org>, "Jürgen Groß" <jgross@suse.com>, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, elliott@hpe.com, "Boris Ostrovsky" <boris.ostrovsky@oracle.com>, "Toshi Kani" <toshi.kani@hpe.com> Subject: Re: [PATCH] x86/mm: fix regression with huge pages on PAE Date: Thu, 12 Nov 2015 11:29:32 -0800 [thread overview] Message-ID: <CA+55aFx84N=o=RWJTy2Bjs-GNjKQuCZYyVWDTgOtRq3-qSO-yg@mail.gmail.com> (raw) In-Reply-To: <20151112080059.GA6835@gmail.com> On Thu, Nov 12, 2015 at 12:00 AM, Ingo Molnar <mingo@kernel.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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-11-12 19:29 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-09 23:18 [PATCH] x86/mm: fix regression with huge pages on PAE Kirill A. Shutemov 2015-11-09 23:18 ` Kirill A. Shutemov 2015-11-09 23:43 ` Toshi Kani 2015-11-09 23:43 ` Toshi Kani 2015-11-09 23:57 ` Kirill A. Shutemov 2015-11-09 23:57 ` Kirill A. Shutemov 2015-11-10 0:12 ` Toshi Kani 2015-11-10 0:12 ` Toshi Kani 2015-11-10 12:34 ` Borislav Petkov 2015-11-10 12:34 ` Borislav Petkov 2015-11-10 13:53 ` Kirill A. Shutemov 2015-11-10 13:53 ` Kirill A. Shutemov 2015-11-10 14:46 ` Borislav Petkov 2015-11-10 14:46 ` Borislav Petkov 2015-11-10 15:07 ` Kirill A. Shutemov 2015-11-10 15:07 ` Kirill A. Shutemov 2015-11-10 17:04 ` Borislav Petkov 2015-11-10 17:04 ` Borislav Petkov 2015-11-11 9:51 ` Borislav Petkov 2015-11-11 9:51 ` Borislav Petkov 2015-11-12 7:48 ` Ingo Molnar 2015-11-12 7:48 ` Ingo Molnar 2015-11-12 7:57 ` Kirill A. Shutemov 2015-11-12 7:57 ` Kirill A. Shutemov 2015-11-12 8:00 ` Ingo Molnar 2015-11-12 8:00 ` Ingo Molnar 2015-11-12 8:46 ` Kirill A. Shutemov 2015-11-12 8:46 ` Kirill A. Shutemov 2015-11-12 8:54 ` Ingo Molnar 2015-11-12 8:54 ` Ingo Molnar 2015-11-12 9:00 ` Kirill A. Shutemov 2015-11-12 9:00 ` Kirill A. Shutemov 2015-11-12 13:29 ` Ingo Molnar 2015-11-12 13:29 ` Ingo Molnar 2015-11-24 14:59 ` Boris Ostrovsky 2015-11-24 14:59 ` Boris Ostrovsky 2015-11-24 20:14 ` Kirill A. Shutemov 2015-11-24 20:14 ` Kirill A. Shutemov 2015-11-25 10:27 ` Borislav Petkov 2015-11-25 10:27 ` Borislav Petkov 2015-11-27 10:14 ` Ingo Molnar 2015-11-27 10:14 ` Ingo Molnar 2015-11-12 8:55 ` Ingo Molnar 2015-11-12 8:55 ` Ingo Molnar 2015-11-12 19:29 ` Linus Torvalds [this message] 2015-11-12 19:29 ` Linus Torvalds 2015-11-13 9:01 ` Dan Williams 2015-11-13 9:01 ` Dan Williams 2015-11-30 10:10 [PATCH] tip-queue 2015-11-30 Borislav Petkov 2015-11-30 10:10 ` [PATCH] x86/mm: Fix regression with huge pages on PAE Borislav Petkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CA+55aFx84N=o=RWJTy2Bjs-GNjKQuCZYyVWDTgOtRq3-qSO-yg@mail.gmail.com' \ --to=torvalds@linux-foundation.org \ --cc=akpm@linux-foundation.org \ --cc=boris.ostrovsky@oracle.com \ --cc=bp@alien8.de \ --cc=elliott@hpe.com \ --cc=hpa@zytor.com \ --cc=jgross@suse.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=kirill@shutemov.name \ --cc=konrad.wilk@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=tglx@linutronix.de \ --cc=toshi.kani@hpe.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.