[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1708251813550.1883@nanos>
Date: Fri, 25 Aug 2017 18:21:05 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Byungchul Park <max.byungchul.park@...il.com>
cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Byungchul Park <byungchul.park@....com>,
Peter Zijlstra <peterz@...radead.org>,
lkml <linux-kernel@...r.kernel.org>, kernel-team@....com
Subject: Re: WARNING: possible circular locking dependency detected
On Sat, 26 Aug 2017, Byungchul Park wrote:
> On Fri, Aug 25, 2017 at 11:47 PM, Sebastian Andrzej Siewior
> <bigeasy@...utronix.de> wrote:
> > We hold the sparse_irq_lock lock while waiting for the completion in the
> > CPU-down case and in the CPU-up case we acquire the sparse_irq_lock lock
> > while the other CPU is waiting for the completion.
> > This is not an issue if my interpretation of lockdep here is correct.
>
> Hello Sebastian,
>
> I think you parsed the message correctly.
>
> The message is saying that, for example:
>
> context A (maybe being up?)
> --
> lock(sparse_irq_lock) // wait for sparse_irq_lock in B to be released
> complete(st->done) // impossible to hit here
>
> context B (maybe wanting to synchronize with the cpu being up?)
> --
> lock(sparse_irq_lock) // acquired successfully
> wait_for_completion(st->done) // wait for completion of st->done in A
> unlock(sparse_irq_lock) // impossible to hit here
>
> I cannot check the kernel code at the moment.. I wonder if this scenario is
> impossible. Could you answer it?
Yes, it's impossible because cpu hotplug is globally serialized. So the cpu
down scenario cannot happen in parallel with the cpu up scenario.
Thanks,
tglx
Powered by blists - more mailing lists