Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
MIME-Version: 1.0
References: <20220909192848.963982-1-longman@redhat.com>
In-Reply-To: <20220909192848.963982-1-longman@redhat.com>
From:   John Stultz <jstultz@google.com>
Date:   Wed, 20 Sep 2023 17:05:56 -0700
Message-ID: <CANDhNCpsDbz9ZT+h4Zcq-7QMJ-uqs3rW+MXCVcbi2A2hnTjBpQ@mail.gmail.com>
Subject: Re: [PATCH v2] locking/semaphore: Use wake_q to wake up processes
 outside lock critical section
To:     Waiman Long <longman@redhat.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Will Deacon <will.deacon@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Sep 9, 2022 at 12:28=E2=80=AFPM Waiman Long <longman@redhat.com> wr=
ote:
>
> It was found that a circular lock dependency can happen with the
> following locking sequence:
>
>    +--> (console_sem).lock --> &p->pi_lock --> &rq->__lock --+
>    |                                                         |
>    +---------------------------------------------------------+
>
> The &p->pi_lock --> &rq->__lock sequence is very common in all the
> task_rq_lock() calls.

Thanks for sending this out! I've been hitting these lockdep warningns
a lot recently, particularly if I have any debug printks/WARN_ONs in
the scheduler that trip, so I'm eager to get a fix for this!

That said, running with your patch, I'm seeing bootup hang pretty
close to where init starts when I've had a fair amount of debug
printks go off. It's odd because the lockup detectors don't seem to
fire.
I'll try to debug further, but wanted to give you a heads up. Let me
know if you have any suggestions.

thanks
-john