From: Wei Liu <wei.liu@kernel.org>
To: Gaurav Kohli <gauravkohli@linux.microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>,
kys@microsoft.com, decui@microsoft.com, haiyangz@microsoft.com,
tglx@linutronix.de, mingo@redhat.com,
dave.hansen@linux.intel.com, x86@kernel.org,
linux-hyperv@vger.kernel.org, bp@alien8.de,
mikelley@microsoft.com
Subject: Re: [PATCH] x86/hyperv: Remove unregister syscore call from hyperv cleanup
Date: Fri, 25 Nov 2022 16:00:52 +0000 [thread overview]
Message-ID: <Y4DmtKikFh5PqjtL@liuwe-devbox-debian-v2> (raw)
In-Reply-To: <a7689a77-ff0d-97c2-3938-9e6422ec069b@linux.microsoft.com>
On Fri, Nov 25, 2022 at 09:09:52PM +0530, Gaurav Kohli wrote:
>
> On 11/25/2022 8:58 PM, Wei Liu wrote:
> > On Wed, Nov 23, 2022 at 09:23:11PM -0800, Gaurav Kohli wrote:
> > > Hyperv cleanup codes comes under panic path where preemption and irq
> > Please use "Hyper-V" throughout.
> Thanks for the comment, sure will do on v2.
> >
> > > is already disabled. So calling of unregister_syscore_ops which has mutex
> > > from hyperv cleanup might schedule out the thread and never comes back.
> > >
> > While on paper this looks problematic -- have you seen this issue
> > triggered in real life?
> >
> > This looks to be only triggered when there is another thread already
> > holding the mutex, which seems rather rare in the life cycle of the
> > machine?
>
>
> Earlier we also suspected the same that someone was holding the lock, but
> actually there
>
> was no owner of lock and it got scheduled out due to might sleep code in
> mutex_lock.
>
> Looks like where voluntary preemption config is on, there it is getting
> scheduled out in might sleep.
If there is only one CPU online and the mutex is free, then
rescheduling will not have any adverse effect, right? Does it not get
scheduled on the only available CPU and make further progress?
>
> But there is no need of unregister_syscore_ops as this is in crash path
> only, So removing the same.
I'm not against removing it, but the reasoning left in the commit
message and comment should reflect what happens.
Thanks,
Wei.
next prev parent reply other threads:[~2022-11-25 16:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-24 5:23 [PATCH] x86/hyperv: Remove unregister syscore call from hyperv cleanup Gaurav Kohli
2022-11-25 15:28 ` Wei Liu
2022-11-25 15:39 ` Gaurav Kohli
2022-11-25 16:00 ` Wei Liu [this message]
2022-11-25 16:05 ` Gaurav Kohli
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=Y4DmtKikFh5PqjtL@liuwe-devbox-debian-v2 \
--to=wei.liu@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=gauravkohli@linux.microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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