From: Jakub Kicinski <kuba@kernel.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Douglas Miller" <dougmill@linux.ibm.com>
Cc: netdev@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
kernel@pengutronix.de,
"Guilherme G. Piccoli" <kernel@gpiccoli.net>
Subject: Re: Strangeness in ehea network driver's shutdown
Date: Mon, 3 Oct 2022 09:36:06 -0700 [thread overview]
Message-ID: <20221003093606.75a78f22@kernel.org> (raw)
In-Reply-To: <20221001143131.6ondbff4r7ygokf2@pengutronix.de>
On Sat, 1 Oct 2022 16:31:31 +0200 Uwe Kleine-König wrote:
> Hello,
>
> while doing some cleanup I stumbled over a problem in the ehea network
> driver.
>
> In the driver's probe function (ehea_probe_adapter() via
> ehea_register_memory_hooks()) a reboot notifier is registered. When this
> notifier is triggered (ehea_reboot_notifier()) it unregisters the
> driver. I'm unsure what is the order of the actions triggered by that.
> Maybe the driver is unregistered twice if there are two bound devices?
> Or the reboot notifier is called under a lock and unregistering the
> driver (and so the devices) tries to unregister the notifier that is
> currently locked and so results in a deadlock? Maybe Greg or Rafael can
> tell about the details here?
>
> Whatever the effect is, it's strange. It makes me wonder why it's
> necessary to free all the resources of the driver on reboot?! I don't
> know anything about the specifics of the affected machines, but I guess
> doing just the necessary stuff on reboot would be easier to understand,
> quicker to execute and doesn't have such strange side effects.
>
> With my lack of knowledge about the machine, the best I can do is report
> my findings. So don't expect a patch or testing from my side.
Last meaningful commit to this driver FWIW:
commit 29ab5a3b94c87382da06db88e96119911d557293
Author: Guilherme G. Piccoli <kernel@gpiccoli.net>
Date: Thu Nov 3 08:16:20 2016 -0200
Also that's the last time we heard from Douglas AFAICT..
next prev parent reply other threads:[~2022-10-03 16:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-01 14:31 Strangeness in ehea network driver's shutdown Uwe Kleine-König
2022-10-03 16:36 ` Jakub Kicinski [this message]
2022-12-06 16:49 ` Guilherme G. Piccoli
2022-12-06 17:02 ` Thadeu Lima de Souza Cascardo
2022-12-07 8:23 ` Uwe Kleine-König
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=20221003093606.75a78f22@kernel.org \
--to=kuba@kernel.org \
--cc=dougmill@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@gpiccoli.net \
--cc=kernel@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.