On Mon 14-01-19 16:13:08, Dmitry Vyukov wrote:
> On Mon, Jan 14, 2019 at 4:11 PM Dmitry Vyukov wrote:
> >
> > On Wed, Jan 9, 2019 at 2:30 PM Jan Kara wrote:
> > >
> > > On Tue 08-01-19 12:49:08, Dmitry Vyukov wrote:
> > > > On Tue, Jan 8, 2019 at 12:24 PM Jan Kara wrote:
> > > > >
> > > > > On
On Mon, Jan 14, 2019 at 4:11 PM Dmitry Vyukov wrote:
>
> On Wed, Jan 9, 2019 at 2:30 PM Jan Kara wrote:
> >
> > On Tue 08-01-19 12:49:08, Dmitry Vyukov wrote:
> > > On Tue, Jan 8, 2019 at 12:24 PM Jan Kara wrote:
> > > >
> > > > On Tue 08-01-19 19:04:06, Tetsuo Handa wrote:
> > > > > On
On Wed, Jan 9, 2019 at 2:30 PM Jan Kara wrote:
>
> On Tue 08-01-19 12:49:08, Dmitry Vyukov wrote:
> > On Tue, Jan 8, 2019 at 12:24 PM Jan Kara wrote:
> > >
> > > On Tue 08-01-19 19:04:06, Tetsuo Handa wrote:
> > > > On 2019/01/03 2:26, Jan Kara wrote:
> > > > > On Thu 03-01-19 01:07:25, Tetsuo
On Tue 08-01-19 12:49:08, Dmitry Vyukov wrote:
> On Tue, Jan 8, 2019 at 12:24 PM Jan Kara wrote:
> >
> > On Tue 08-01-19 19:04:06, Tetsuo Handa wrote:
> > > On 2019/01/03 2:26, Jan Kara wrote:
> > > > On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
> > > >> On 2019/01/02 23:40, Jan Kara wrote:
> >
On Tue, Jan 8, 2019 at 12:24 PM Jan Kara wrote:
>
> On Tue 08-01-19 19:04:06, Tetsuo Handa wrote:
> > On 2019/01/03 2:26, Jan Kara wrote:
> > > On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
> > >> On 2019/01/02 23:40, Jan Kara wrote:
> > >>> I had a look into this and the only good explanation
On Tue 08-01-19 19:04:06, Tetsuo Handa wrote:
> On 2019/01/03 2:26, Jan Kara wrote:
> > On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
> >> On 2019/01/02 23:40, Jan Kara wrote:
> >>> I had a look into this and the only good explanation for this I have is
> >>> that sb->s_blocksize is different from
On 2019/01/03 2:26, Jan Kara wrote:
> On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
>> On 2019/01/02 23:40, Jan Kara wrote:
>>> I had a look into this and the only good explanation for this I have is
>>> that sb->s_blocksize is different from (1 <<
>>> sb->s_bdev->bd_inode->i_blkbits).
>>> If
On 2019/01/03 2:26, Jan Kara wrote:
> On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
>> On 2019/01/02 23:40, Jan Kara wrote:
>>> I had a look into this and the only good explanation for this I have is
>>> that sb->s_blocksize is different from (1 <<
>>> sb->s_bdev->bd_inode->i_blkbits).
>>> If
On Thu 03-01-19 01:07:25, Tetsuo Handa wrote:
> On 2019/01/02 23:40, Jan Kara wrote:
> > I had a look into this and the only good explanation for this I have is
> > that sb->s_blocksize is different from (1 <<
> > sb->s_bdev->bd_inode->i_blkbits).
> > If that would happen, we'd get exactly the
On 2019/01/02 23:40, Jan Kara wrote:
> I had a look into this and the only good explanation for this I have is
> that sb->s_blocksize is different from (1 << sb->s_bdev->bd_inode->i_blkbits).
> If that would happen, we'd get exactly the behavior syzkaller observes
> because grow_buffers() would
On Wed, Jan 2, 2019 at 3:40 PM Jan Kara wrote:
>
> On Fri 28-12-18 22:34:13, Tetsuo Handa wrote:
> > On 2018/08/06 19:09, Jan Kara wrote:
> > > On Tue 31-07-18 00:07:22, Tetsuo Handa wrote:
> > >> On 2018/07/21 5:06, Andrew Morton wrote:
> > >>> On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
>
On Fri 28-12-18 22:34:13, Tetsuo Handa wrote:
> On 2018/08/06 19:09, Jan Kara wrote:
> > On Tue 31-07-18 00:07:22, Tetsuo Handa wrote:
> >> On 2018/07/21 5:06, Andrew Morton wrote:
> >>> On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
> >>> wrote:
> >>>
> >
> > This report is stalling
On 2018/08/06 19:09, Jan Kara wrote:
> On Tue 31-07-18 00:07:22, Tetsuo Handa wrote:
>> On 2018/07/21 5:06, Andrew Morton wrote:
>>> On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
>>> wrote:
>>>
>
> This report is stalling after mount() completed and process used
>
On 2018/08/06 20:56, Tetsuo Handa wrote:
> On 2018/08/06 19:09, Jan Kara wrote:
>> Looks like some kind of a race where device block size gets changed while
>> getblk() runs (and creates buffers for underlying page). I don't have time
>> to nail it down at this moment can have a look into it later
On 2018/08/06 20:56, Tetsuo Handa wrote:
> On 2018/08/06 19:09, Jan Kara wrote:
>> Looks like some kind of a race where device block size gets changed while
>> getblk() runs (and creates buffers for underlying page). I don't have time
>> to nail it down at this moment can have a look into it later
On 2018/08/06 19:09, Jan Kara wrote:
>> syzbot reproduced this problem (
>> https://syzkaller.appspot.com/text?tag=CrashLog=11f2fc4440 ) .
>> It says that grow_dev_page() is returning 1 but __find_get_block() is
>> failing forever. Any idea?
So far syzbot reproduced 7 times, and all reports
On 2018/08/06 19:09, Jan Kara wrote:
>> syzbot reproduced this problem (
>> https://syzkaller.appspot.com/text?tag=CrashLog=11f2fc4440 ) .
>> It says that grow_dev_page() is returning 1 but __find_get_block() is
>> failing forever. Any idea?
So far syzbot reproduced 7 times, and all reports
On Tue 31-07-18 00:07:22, Tetsuo Handa wrote:
> On 2018/07/21 5:06, Andrew Morton wrote:
> > On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
> > wrote:
> >
> >>>
> >>> This report is stalling after mount() completed and process used
> >>> remap_file_pages().
> >>> I think that we might need to
On Tue 31-07-18 00:07:22, Tetsuo Handa wrote:
> On 2018/07/21 5:06, Andrew Morton wrote:
> > On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
> > wrote:
> >
> >>>
> >>> This report is stalling after mount() completed and process used
> >>> remap_file_pages().
> >>> I think that we might need to
On 2018/07/21 5:06, Andrew Morton wrote:
> On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
> wrote:
>
>>>
>>> This report is stalling after mount() completed and process used
>>> remap_file_pages().
>>> I think that we might need to use debug printk(). But I don't know what to
>>> examine.
On 2018/07/21 5:06, Andrew Morton wrote:
> On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
> wrote:
>
>>>
>>> This report is stalling after mount() completed and process used
>>> remap_file_pages().
>>> I think that we might need to use debug printk(). But I don't know what to
>>> examine.
On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
wrote:
> >
> > This report is stalling after mount() completed and process used
> > remap_file_pages().
> > I think that we might need to use debug printk(). But I don't know what to
> > examine.
> >
>
> Andrew, can you pick up this debug
On Fri, 20 Jul 2018 19:36:23 +0900 Tetsuo Handa
wrote:
> >
> > This report is stalling after mount() completed and process used
> > remap_file_pages().
> > I think that we might need to use debug printk(). But I don't know what to
> > examine.
> >
>
> Andrew, can you pick up this debug
FO: task hung in fat_fallocate
INFO: task hung in generic_file_write_iter
INFO: task hung in d_alloc_parallel
INFO: task hung in __fdget_pos (2)
INFO: task hung in path_openat
INFO: task hung in do_truncate
INFO: task hung in filename_create
> And there is horrible comment
FO: task hung in fat_fallocate
INFO: task hung in generic_file_write_iter
INFO: task hung in d_alloc_parallel
INFO: task hung in __fdget_pos (2)
INFO: task hung in path_openat
INFO: task hung in do_truncate
INFO: task hung in filename_create
> And there is horrible comment
On Wed, Jul 18, 2018 at 12:28 PM, Tetsuo Handa
wrote:
> On 2018/07/18 17:58, syzbot wrote:
>> mmap: syz-executor7 (10902) uses deprecated remap_file_pages() syscall. See
>> Documentation/vm/remap_file_pages.rst.
>
> There are many reports which are stalling inside __getblk_gfp().
> And there is
On Wed, Jul 18, 2018 at 12:28 PM, Tetsuo Handa
wrote:
> On 2018/07/18 17:58, syzbot wrote:
>> mmap: syz-executor7 (10902) uses deprecated remap_file_pages() syscall. See
>> Documentation/vm/remap_file_pages.rst.
>
> There are many reports which are stalling inside __getblk_gfp().
> And there is
On 2018/07/18 17:58, syzbot wrote:
> mmap: syz-executor7 (10902) uses deprecated remap_file_pages() syscall. See
> Documentation/vm/remap_file_pages.rst.
There are many reports which are stalling inside __getblk_gfp().
And there is horrible comment for __getblk_gfp():
/*
* __getblk_gfp()
On 2018/07/18 17:58, syzbot wrote:
> mmap: syz-executor7 (10902) uses deprecated remap_file_pages() syscall. See
> Documentation/vm/remap_file_pages.rst.
There are many reports which are stalling inside __getblk_gfp().
And there is horrible comment for __getblk_gfp():
/*
* __getblk_gfp()
Hello,
syzbot found the following crash on:
HEAD commit:30b06abfb92b Merge tag 'pinctrl-v4.18-3' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1240ed6240
kernel config: https://syzkaller.appspot.com/x/.config?x=6d0ccc9273f0e539
Hello,
syzbot found the following crash on:
HEAD commit:30b06abfb92b Merge tag 'pinctrl-v4.18-3' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1240ed6240
kernel config: https://syzkaller.appspot.com/x/.config?x=6d0ccc9273f0e539
31 matches
Mail list logo
