linux-ext4 - Re: INFO: task hung in blk_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <927ef9f9-4f4d-185e-b86f-10bd18fa92d4@i-love.sakura.ne.jp>
Date:   Thu, 7 Jun 2018 22:19:06 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Ming Lei <tom.leiming@...il.com>, Ming Lei <ming.lei@...hat.com>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Bart Van Assche <Bart.VanAssche@....com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        alan.christopher.jenkins@...il.com,
        syzbot+c4f9cebf9d651f6e54de@...kaller.appspotmail.com,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Christoph Hellwig <hch@....de>,
        Oleksandr Natalenko <oleksandr@...alenko.name>,
        martin@...htvoll.de, Hannes Reinecke <hare@...e.com>,
        syzkaller-bugs@...glegroups.com,
        Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Keith Busch <keith.busch@...el.com>,
        "open list:EXT4 FILE SYSTEM" <linux-ext4@...r.kernel.org>
Subject: Re: INFO: task hung in blk_queue_enter

On 2018/06/07 12:29, Ming Lei wrote:
>> The vfs_fsync() isn't necessary in loop_update_dio() since both
>> generic_file_write_iter() and generic_file_read_iter() can handle
>> buffered io vs dio well.
>>
>> I will send one patch to remove the vfs_sync() later.
> 
> Hi Tetsuo,
> 
> The issue might be fixed by removing this vfs_sync(), but I'd like to
> understand the idea behind since vfs_sync() shouldn't have caused
> any IO to this loop queue.
> 
> I also tried to do the test via the following c syzbot, but can't reproduce
> it yet after running it for several hours.
> 
> https://syzkaller.appspot.com/x/repro.c?id=4727023951937536
> 
> Could you share us how you reproduce it?

I just reported that syzbot started hitting vfs_sync() case.
I haven't succeeded reproducing vfs_sync() case in my environment.

But in general, I modify "any reproducer provided by syzbot that loops
forever" to call exit() if open() etc. failed, for continuing the loop
unlikely helps after hitting "Too many open files" error.

   res = syscall(__NR_memfd_create, 0x200002c0, 0);
   if (res != -1)
     r[1] = res;
+  else
+    exit(1);

Thus, I restart the reproducer in a loop from shell
rather than keep running for hours.

   while :; do echo -n .; ./a.out; done