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 T
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 2019/01/
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 Ha
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 for
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 that
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 that
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 beh
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 pop
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 aft
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
> remap_file_pages(
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&x=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 report
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 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 prin
On 2018/07/18 19:28, Tetsuo Handa wrote:
> There are many reports which are stalling inside __getblk_gfp().
Currently 18 reports out of 65 "INFO: task hung in " reports.
INFO: task hung in aead_recvmsg
INFO: task hung in inode_sleep_on_writeback
INFO: task hung in __writeback_inodes_sb_nr
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 h
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() wi
21 matches
Mail list logo