Re: INFO: task hung in __sb_start_write

On 2018/06/15 18:19, Dmitry Vyukov wrote:

On Thu, Jun 14, 2018 at 12:33 PM, Tetsuo Handa
[off-list ref] wrote:

quoted

On 2018/06/11 16:39, Dmitry Vyukov wrote:

quoted

On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra [off-list ref] wrote:

quoted

On Sun, Jun 10, 2018 at 11:47:56PM +0900, Tetsuo Handa wrote:

quoted

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() ?