On (07/19/15 08:27), Guenter Roeck wrote: > > - 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 ?
<subsequent example code deleted> > So either case ~0l appears to be wrong; it should be ~0ul. > I don't know if ~0ull makes a difference for some architectures. I agree about the unsigned part. However, regarding the arch specific twists.. I checked into this.. even though I have a test program on x86_64 that "does the right thing" for both of align_mask = ~0ul >> (64 - align_order); align_mask = ~0ul >> (BITS_PER_LONG - align_order); when I compiled with -m32 and without (I tried align_order == 1 and 31 for edge cases), I think there are some gcc/arch specific variations possible based on undefined behavior, so that the second variant is safer. I'll send out a patch with that version soon. --Sowmini -- 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/
