Re: kernel BUG at mm/hugetlb.c:LINE!

[Mike Kravetz]

On 5/18/20 4:12 AM, Miklos Szeredi wrote:
> On Sat, May 16, 2020 at 12:15 AM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote:
>> Any suggestions on how to move forward?  It seems like there may be the
>> need for a real_file() routine?  I see a d_real dentry_op was added to
>> deal with this issue for dentries.  Might we need something similiar for
>> files (f_real)?
>>
>> Looking for suggestions as I do not normally work with this code.
> 
> And I'm not so familiar with hugepages code.  I'd suggest moving
> length alignment into f_op->get_unmapped_area() and cleaning up other
> special casing of hugetlb mappings, but it's probably far from
> trivial...
> 
> So yeah, that leaves a real_file() helper or something similar.
> Unlike the example I gave first it actually needs to be recursive:
> 
> static inline struct file *real_file(struct file *file)
> {
>     whole (unlikely(file->f_op == ovl_file_operations))
>         file = file->private_data;
>     return file;
> }

If we add real_file(), then I think it only needs to be called in two
places: is_file_hugepages() and core mmap code.  However, I could not
think of a good place to put real_file().  Below is a patch which creates
a new file <linux/overlayfs.h> for the routine.  It does solve this BUG
and should fix any other issues with callers of is_file_hugepages().
Let me know what you think.

I add a 'Suggested-by:' for real_file, but am happy to change that to
a 'Signed-off-by:' if you prefer.