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

2020-05-27 Thread Mike Kravetz
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

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

2020-05-22 Thread Miklos Szeredi
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' >

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

2020-05-20 Thread Mike Kravetz
On 5/20/20 4:20 AM, Miklos Szeredi wrote: > On Tue, May 19, 2020 at 2:35 AM Mike Kravetz wrote: >> >> On 5/18/20 4:41 PM, Colin Walters wrote: >>> >>> On Tue, May 12, 2020, at 11:04 AM, Miklos Szeredi wrote: >>> > However, in this syzbot test case the 'file' is in an overlayfs filesystem

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

2020-05-20 Thread Miklos Szeredi
On Tue, May 19, 2020 at 2:35 AM Mike Kravetz wrote: > > On 5/18/20 4:41 PM, Colin Walters wrote: > > > > On Tue, May 12, 2020, at 11:04 AM, Miklos Szeredi wrote: > > > >>> However, in this syzbot test case the 'file' is in an overlayfs filesystem > >>> created as follows: > >>> > >>>

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

2020-05-18 Thread Mike Kravetz
On 5/18/20 4:41 PM, Colin Walters wrote: > > On Tue, May 12, 2020, at 11:04 AM, Miklos Szeredi wrote: > >>> However, in this syzbot test case the 'file' is in an overlayfs filesystem >>> created as follows: >>> >>> mkdir("./file0", 000) = 0 >>> mount(NULL, "./file0",

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

2020-05-18 Thread Colin Walters
On Tue, May 12, 2020, at 11:04 AM, Miklos Szeredi wrote: > > However, in this syzbot test case the 'file' is in an overlayfs filesystem > > created as follows: > > > > mkdir("./file0", 000) = 0 > > mount(NULL, "./file0", "hugetlbfs", MS_MANDLOCK|MS_POSIXACL, NULL) = 0 > >

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

2020-05-18 Thread Mike Kravetz
On 5/18/20 4:12 AM, Miklos Szeredi wrote: > On Sat, May 16, 2020 at 12:15 AM Mike Kravetz 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

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

2020-05-18 Thread Miklos Szeredi
On Sat, May 16, 2020 at 12:15 AM Mike Kravetz wrote: > I started going down the path of creating a get_unmapped_area f_op for > overlayfs. That is pretty straight forward and works well. But that > did not take care of the is_file_hugepages() routine. Recall that > is_file_hugepages simply

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

2020-05-15 Thread Mike Kravetz
On 5/12/20 11:11 AM, Mike Kravetz wrote: > On 5/12/20 8:04 AM, Miklos Szeredi wrote: >> On Tue, Apr 7, 2020 at 12:06 AM Mike Kravetz wrote: >>> On 4/5/20 8:06 PM, syzbot wrote: >>> >>> The routine is_file_hugepages() is just comparing the file ops to huegtlbfs: >>> >>> if (file->f_op ==

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

2020-05-12 Thread Mike Kravetz
On 5/12/20 8:04 AM, Miklos Szeredi wrote: > On Tue, Apr 7, 2020 at 12:06 AM Mike Kravetz wrote: >> On 4/5/20 8:06 PM, syzbot wrote: >> >> The routine is_file_hugepages() is just comparing the file ops to huegtlbfs: >> >> if (file->f_op == _file_operations) >> return true;

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

2020-05-12 Thread Miklos Szeredi
On Tue, Apr 7, 2020 at 12:06 AM Mike Kravetz wrote: > > On 4/5/20 8:06 PM, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:1a323ea5 x86: get rid of 'errret' argument to __get_user_x.. > > git tree: upstream > > console output: