linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	arnd@arndb.de, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org,
	Wedson Almeida Filho <wedsonaf@google.com>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH] char: misc: make misc_open() and misc_register() killable
Date: Tue, 5 Jul 2022 16:16:35 +0200	[thread overview]
Message-ID: <YsRHwy6+5gask+KT@kroah.com> (raw)
In-Reply-To: <5665ccb2-b92b-9e1f-8bb5-a950986450ec@I-love.SAKURA.ne.jp>

On Tue, Jul 05, 2022 at 11:01:38PM +0900, Tetsuo Handa wrote:
> On 2022/07/05 14:21, Tetsuo Handa wrote:
> > Possible locations where snapshot_open() might sleep with system_transition_mutex held are
> > pm_notifier_call_chain_robust()/wait_for_device_probe()/create_basic_memory_bitmaps().
> > But I think we can exclude pm_notifier_call_chain_robust() because lockdep does not report
> > that that process is holding "struct blocking_notifier_head"->rwsem. I suspect that
> > that process is sleeping at wait_for_device_probe(), for it waits for probe operations.
> > 
> > ----------------------------------------
> > void wait_for_device_probe(void)
> > {
> > 	/* wait for the deferred probe workqueue to finish */
> > 	flush_work(&deferred_probe_work);
> > 
> > 	/* wait for the known devices to complete their probing */
> > 	wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
> > 	async_synchronize_full();
> > }
> > ----------------------------------------
> 
> syzbot confirmed that snapshot_open() is unable to proceed due to
> atomic_read(&probe_count) == 2 for 145 seconds.
> 
> ----------------------------------------
> [   86.794300][ T4209] Held system_transition_mutex.
> [   86.821486][ T4209] Calling wait_for_device_probe()
> [   86.841374][ T4209] Calling flush_work(&deferred_probe_work)
> [   86.867398][ T4209] Calling wait_event(probe_waitqueue)
> [   87.966188][ T4209] Calling probe_count=2
> (...snipped...)
> [  233.554473][ T4209] Calling probe_count=2
> [  234.444800][   T28] INFO: task syz-executor.4:4146 blocked for more than 143 seconds.
> ----------------------------------------
> 
> Apart from whether we should fuzz snapshot code or not,
> there seems to be a bug that causes wait_for_device_probe() to hung.

What else is going on in the system at this point in time?  Are devices
still being added as part of boot init sequences?  Or has boot finished
properly and these are devices being removed?

Some device is being probed at the moment, maybe we have a deadlock
somewhere here...

thanks,

greg k-h

  reply	other threads:[~2022-07-05 14:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000000000000d9ff3a05bb37069e@google.com>
     [not found] ` <72e74af9-f1b6-e383-a2c3-6ee8a0aea5e0@I-love.SAKURA.ne.jp>
     [not found]   ` <YsKW6VvWqvcMRBSl@kroah.com>
     [not found]     ` <100f445e-9fa8-4f37-76aa-8359f0008c59@I-love.SAKURA.ne.jp>
     [not found]       ` <YsLIepAXeBKT0AF/@kroah.com>
2022-07-04 12:34         ` [PATCH] char: misc: make misc_open() and misc_register() killable Tetsuo Handa
2022-07-04 12:59           ` Wedson Almeida Filho
2022-07-04 13:48             ` Tetsuo Handa
2022-07-04 13:57               ` Wedson Almeida Filho
2022-07-04 14:07                 ` Tetsuo Handa
2022-07-04 14:46                   ` Wedson Almeida Filho
2022-07-04 14:31           ` Greg KH
2022-07-05  5:21             ` Tetsuo Handa
2022-07-05  5:37               ` Greg KH
     [not found]                 ` <a1fcc07e-51ef-eaad-f14b-33f1263e45ac@I-love.SAKURA.ne.jp>
2022-07-05  7:20                   ` Dmitry Vyukov
2022-07-05 10:10                     ` Greg Kroah-Hartman
2022-07-08  6:06                       ` Dmitry Vyukov
2022-07-05 14:01               ` Tetsuo Handa
2022-07-05 14:16                 ` Greg KH [this message]
2022-07-05 14:35                   ` Tetsuo Handa
2022-07-06  6:21                     ` Tetsuo Handa
2022-07-06  6:34                       ` Greg KH
2022-07-06 10:26                         ` Tetsuo Handa
2022-07-06 11:04                           ` Oliver Neukum
2022-07-07  5:06                             ` Tetsuo Handa
2022-07-07  8:04                               ` Greg KH
2022-07-08 13:37                               ` Greg KH
2022-07-10  2:27                                 ` Tetsuo Handa
2022-07-06 12:17                           ` Oliver Neukum

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 \
    --in-reply-to=YsRHwy6+5gask+KT@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=dvyukov@google.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rafael@kernel.org \
    --cc=wedsonaf@google.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).