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
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'
>
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
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:
> >>>
> >>>
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",
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
> >
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
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
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 ==
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;
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:
11 matches
Mail list logo