From: Oleg Nesterov <oleg@tv-sign.ru>
To: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Max Krasnyanskiy <maxk@qualcomm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: latest -git: hibernate: possible circular locking dependency detected
Date: Thu, 21 Aug 2008 22:03:43 +0400 [thread overview]
Message-ID: <20080821180343.GA14139@tv-sign.ru> (raw)
In-Reply-To: <b647ffbd0808211038h686f9df3ud335efbc46242952@mail.gmail.com>
On 08/21, Dmitry Adamushko wrote:
>
> however, I think there are 2 problems with handle_poweroff()
> [ kernel/power/poweroff.c ]
>
> (1) it doesn't ensure that the 'cpu' it gets via
> first_cpu(cpu_online_map) can't disappear (race with cpu_down()) on
> the way to schedule_work_on()
>
> [ I pressume, neither generic sysrq nor console layer takes care of
> it. They shoudn't of course ]
>
> (2) run_workqueue() [ which in the end calls do_poweroff() ] takes the
> "cwq->lock" (which is lock-2 in our terminology)
>
> well, actually it release it before calling "work->fun()" but is the
> 'lockdep' annotation right here? Peter?
>
> (I admit, I never looked at lockdep and do make assumptions on its syntax here).
>
> The lock-1 will be taken as a result of
>
> then, do_poweroff() -> kernel_power_off() -> disable_nonboot_cpus()
>
> which calls cpu_maps_update_begin() and takes "cpu_add_remove_lock"
>
> and this looks dangerous. Due to the same reason as was before with
> the use of get_online_cpus() by workqueue handlers before
> CPU_POST_DEAD introduction
> (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3da1c84c00c7e5fa8348336bd8c342f9128b0f14)
>
> I guess, it may deadlock as the lock-1 has been already taken before
> calling cleanup_workqueue_thread() -> flush_cpu_workqueue() and
> completion of the former chain depends in turn on being able to
> acquire the very same lock.
I apologize in advance if I missed something else in your message,
but I think you are very right. Please look at
http://marc.info/?t=121580236300019
Oleg.
next prev parent reply other threads:[~2008-08-21 17:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-21 15:04 Vegard Nossum
2008-08-21 17:38 ` Dmitry Adamushko
2008-08-21 17:59 ` Vegard Nossum
2008-08-22 9:18 ` Pavel Machek
2008-08-21 18:03 ` Oleg Nesterov [this message]
2008-08-21 18:22 ` Rafael J. Wysocki
2008-08-21 18:31 ` Vegard Nossum
2008-08-21 18:39 ` Vegard Nossum
2008-08-21 19:07 ` Rafael J. Wysocki
2008-08-21 19:14 ` Vegard Nossum
2008-08-21 19:31 ` Rafael J. Wysocki
2008-08-21 19:41 ` Vegard Nossum
2008-08-21 19:54 ` Rafael J. Wysocki
2008-08-22 8:55 ` Pavel Machek
2008-08-22 19:09 ` Vegard Nossum
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=20080821180343.GA14139@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=a.p.zijlstra@chello.nl \
--cc=dmitry.adamushko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=rjw@sisk.pl \
--cc=vegard.nossum@gmail.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
all inboxes | Powered by JetHome®