From: Tetsuo Handa <firstname.lastname@example.org> To: Dmitry Vyukov <email@example.com> Cc: Peter Zijlstra <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Will Deacon <firstname.lastname@example.org>, syzbot <email@example.com>, linux-fsdevel <firstname.lastname@example.org>, LKML <email@example.com>, syzkaller-bugs <firstname.lastname@example.org>, Al Viro <email@example.com>, Linus Torvalds <firstname.lastname@example.org> Subject: Re: INFO: task hung in __sb_start_write Date: Sat, 16 Jun 2018 04:40:14 +0900 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CACT4Y+ZaUanRCWtq4nFhFVxfDCX=2e6JCW-qkX7vp++QvijWBw@mail.gmail.com> On 2018/06/15 18:19, Dmitry Vyukov wrote: > On Thu, Jun 14, 2018 at 12:33 PM, Tetsuo Handa > <firstname.lastname@example.org> wrote: >> On 2018/06/11 16:39, Dmitry Vyukov wrote: >>> On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra <email@example.com> wrote: >>>> On Sun, Jun 10, 2018 at 11:47:56PM +0900, Tetsuo Handa wrote: >>>> >>>>> This looks quite strange that nobody is holding percpu_rw_semaphore for >>>>> write but everybody is stuck trying to hold it for read. (Since there >>>>> is no "X locks held by ..." line without followup "#0:" line, there is >>>>> no possibility that somebody is in TASK_RUNNING state while holding >>>>> percpu_rw_semaphore for write.) >>>>> >>>>> I feel that either API has a bug or API usage is wrong. >>>>> Any idea for debugging this? >>>> >>>> Look at percpu_rwsem_release() and usage. The whole fs freezer thing is >>>> magic. >>> >>> Do you mean that we froze fs? We tried to never-ever issue >>> ioctl(FIFREEZE) during fuzzing. Are there other ways to do this? >>> >> >> Dmitry, can you try this patch? If you can get > > I've tried replying 5 logs with this patch, but I don't see that we > return to user-space with locks held, nor deadlock reports. Did you succeed to reproduce khungtaskd messages with this patch? If yes, was one of sb_writers#X/sb_pagefaults/sb_internal printed there? If no, we would want a git tree for testing under syzbot. > > What I've noticed is that all these logs contain lots of error > messages around block subsystem. Perhaps if we can identify the common > denominator across error messages in different logs, we can find the > one responsible for hangs. While there are lots of error messages around block subsystem, how can down_read() fail to continue unless up_write() somehow failed to wake up waiters sleeping at down_read(), assuming that khungtaskd says that none of sb_writers#X/sb_pagefaults/sb_internal was held? Hmm, there might be other locations calling percpu_rwsem_release() ?
next prev parent reply other threads:[~2018-06-15 19:41 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-03 10:17 syzbot 2018-06-10 14:47 ` Tetsuo Handa 2018-06-11 7:30 ` Peter Zijlstra 2018-06-11 7:39 ` Dmitry Vyukov 2018-06-14 10:33 ` Tetsuo Handa 2018-06-14 10:33 ` Tetsuo Handa 2018-06-15 9:19 ` Dmitry Vyukov 2018-06-15 19:40 ` Tetsuo Handa [this message] 2018-06-19 11:10 ` Tetsuo Handa 2018-06-19 11:47 ` Dmitry Vyukov 2018-06-19 13:00 ` Tetsuo Handa 2018-07-11 11:13 ` Tetsuo Handa 2018-07-13 10:38 ` Tetsuo Handa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: INFO: task hung in __sb_start_write' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.