Messages in this thread | | | Date | Thu, 7 Feb 2008 10:04:52 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH][Regression] x86, 32-bit: trim memory not covered by wb mtrrs - FIX |
| |
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> minor difference > + trim_start = highest_pfn << PAGE_SHIFT; > + trim_size = end_pfn << PAGE_SHIFT; > > could cause some problem with 32 bit kernel when mem > 4g. becase > highest_pfn and end_pfn is unsigned long aka 32 bit ...could overflow. > > so need to assign thtem to trim_start/trim_end at first > or > + trim_start = (u64)highest_pfn << PAGE_SHIFT; > + trim_size = (u64)end_pfn << PAGE_SHIFT;
indeed ...
i think the 64-bit behavior of gcc is inherently dangerous, we had numerous subtle bugs in that area.
i think perhaps Sparse should be extended to warn about this. I think any case where on _32-bit_ we have an 'unsigned long' that is shifted to the left by any significant amount is clearly in danger of overflowing. _Especially_ when the lvalue is 64-bit!
or in other words, on any such construct:
64-bit lvalue = ... 32-bit value
we should enforce _explicit_ (u64) conversions.
Ingo
| |