Re: kernel BUG at mm/hugetlb.c:LINE!
From: Mike Kravetz
Date: Wed May 27 2020 - 20:01:43 EST
On 5/22/20 3:05 AM, Miklos Szeredi wrote:
> On Wed, May 20, 2020 at 10:27:15AM -0700, Mike Kravetz wrote:
>> I am fairly confident it is all about checking limits and alignment. The
>> filesystem knows if it can/should align to base or huge page size. DAX has
>> some interesting additional restrictions, and several 'traditional' filesystems
>> check if they are 'on DAX'.
> Okay, I haven't looked at DAX vs. overlay. I'm sure it's going to come up at
> some point, if it hasn't already.
>> In a previous e-mail, you suggested hugetlb_get_unmapped_area could do the
>> length adjustment in hugetlb_get_unmapped_area (generic and arch specific).
>> I agree, although there may be the need to add length overflow checks in
>> these routines (after round up) as this is done in core code now. However,
>> this can be done as a separate cleanup patch.
>> In any case, we need to get the core mmap code to call filesystem specific
>> get_unmapped_area if on a union/overlay. The patch I suggested does this
>> by simply calling real_file to determine if there is a filesystem specific
>> get_unmapped_area. The other approach would be to provide an overlayfs
>> get_unmapped_area that calls the underlying filesystem get_unmapped_area.
> That latter is what's done for all other stacked operations in overlayfs.
> Untested patch below.
We still need the 'real_file()' routine for is_file_hugepages. So combining
these, I propose the following patch. It addresses the known issue as well
as potential issues with is_file_hugepages returning incorrect information.
I don't really like a separate header file for real_file, but I can not
think of any good place to put it.
Let me know what you think,