On Thu, Nov 12, 2015 at 12:00 AM, Ingo Molnar <mingo@xxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>