2014-10-23 0:13 GMT+04:00 Andrew Morton <a...@linux-foundation.org>: > On Wed, 22 Oct 2014 14:50:22 -0400 Sasha Levin <sasha.le...@oracle.com> wrote: > >> On 10/22/2014 02:44 PM, Andrew Morton wrote: >> > On Wed, 22 Oct 2014 09:42:46 +0400 Andrey Ryabinin >> > <a.ryabi...@samsung.com> wrote: >> > >> >> > On 10/21/2014 10:15 PM, Sasha Levin wrote: >> >>> > > hstate_sizelog() would shift left an int rather than long, triggering >> >>> > > undefined behaviour and passing an incorrect value when the requested >> >>> > > page size was more than 4GB, thus breaking >4GB pages. >> >> > >> >>> > > >> >>> > > Signed-off-by: Sasha Levin <sasha.le...@oracle.com> >> >>> > > --- >> >>> > > include/linux/hugetlb.h | 3 ++- >> >>> > > 1 file changed, 2 insertions(+), 1 deletion(-) >> >>> > > >> >>> > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h >> >>> > > index 65e12a2..57e0dfd 100644 >> >>> > > --- a/include/linux/hugetlb.h >> >>> > > +++ b/include/linux/hugetlb.h >> >>> > > @@ -312,7 +312,8 @@ static inline struct hstate *hstate_sizelog(int >> >>> > > page_size_log) >> >>> > > { >> >>> > > if (!page_size_log) >> >>> > > return &default_hstate; >> >>> > > - return size_to_hstate(1 << page_size_log); >> >>> > > + >> >>> > > + return size_to_hstate(1UL << page_size_log); >> >> > >> >> > That still could be undefined on 32-bits. Either use 1ULL or reduce >> >> > SHM_HUGE_MASK on 32bits. >> >> > >> > But >> > >> > struct hstate *size_to_hstate(unsigned long size) >> >> True, but "(1 << page_size_log)" produces an integer rather than long >> because "1" >> is an int and not long. > > My point is that there's no point in using 1ULL because > size_to_hstate() will truncate it anyway. >
There is a point to use 1ULL On 32-bit with size >= 32 (1UL << size) - undefined, so size_to_hstate() will truncate it to undefined as well. E.g. It definitely won't be zero on x86. While (1ULL << size) - is defined and size_to_hstate() will truncate it to zero. -- Best regards, Andrey Ryabinin -- 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/