On Sun, Jul 19 2015, Guenter Roeck <li...@roeck-us.net> wrote: > On Sun, Jul 19, 2015 at 02:20:14PM +0200, Sowmini Varadhan wrote: >> >> Using a 64 bit constant generates "warning: integer constant is too >> large for 'long' type" on 32 bit platforms. Instead use ~0l to get >> the desired effect. >> >> Detected by Andrew Morton who has confirmed that this patch >> fixes the warning on i386/gcc-4.4.3, i386/gcc-4.4.0 and arm/gcc-4.4.4. >> >> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> >> --- >> lib/iommu-common.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/lib/iommu-common.c b/lib/iommu-common.c >> index df30632..fd1297d 100644 >> --- a/lib/iommu-common.c >> +++ b/lib/iommu-common.c >> @@ -119,7 +119,7 @@ unsigned long iommu_tbl_range_alloc(struct device *dev, >> unsigned long align_mask = 0; >> >> if (align_order > 0) >> - align_mask = 0xffffffffffffffffl >> (64 - align_order); >> + align_mask = ~0l >> (64 - align_order); >> > Wonder if this just hides the real problem. Unless align_order > is very large, the resulting mask on 32 bit systems may be 0. > Is this really the idea ?
Probably not, but that's not what would happen on x86: the shift only depends on the lower 5 or 6 bits - I don't know if other platforms also has that behaviour. So for align_order == 2 and x86_32 we'd effectively end up with a shift of 62 & 31 == 30 (though technically undefined behaviour), and the desired mask of 0x3. Wouldn't GENMASK(align_order-1, 0) work for all cases (assuming align_order has a sane value)? Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
