From: Lukas Wunner <lukas@wunner.de>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Tony Nguyen" <anthony.l.nguyen@intel.com>,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, netdev@vger.kernel.org,
sasha.neftin@intel.com, "Roman Lozko" <lozko.roma@gmail.com>,
"Kurt Kanzenbach" <kurt@linutronix.de>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Simon Horman" <horms@kernel.org>,
"Naama Meir" <naamax.meir@linux.intel.com>
Subject: Re: [PATCH net] igc: Fix LED-related deadlock on driver unbind
Date: Tue, 23 Apr 2024 10:08:55 +0200 [thread overview]
Message-ID: <ZidslwZAYyu4RnJk@wunner.de> (raw)
In-Reply-To: <a356d2a0-e573-4e31-bae3-2a361476f937@intel.com>
On Mon, Apr 22, 2024 at 04:46:28PM -0700, Jacob Keller wrote:
> To me, using devm from the PCI device should be equivalent to managing
> it manually within the igc_remove() function.
It is not equivalent because the ordering is different:
igc_remove() is called before device-managed resources are released:
__device_release_driver()
device_remove() # invokes igc_remove()
device_unbind_cleanup()
devres_release_all() # releases device-managed resources
If you unregister LEDs explicitly in igc_remove() before unregistering
the netdev and disabling PCI device access, everything's fine.
If you instead use devm_led_classdev_register(), the LEDs would still
be registered and available in sysfs after igc_remove() has torn down
everything, which is bad.
You'd have to use devm_*() for all initialization steps in igc_probe()
to make this work. With devm_*() it's generally all or nothing.
(There are exceptions: Using devm_*() just for memory allocations is
fine as those can safely be freed even if everything else is torn down.)
Thanks,
Lukas
next prev parent reply other threads:[~2024-04-23 8:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 20:45 [PATCH net] igc: Fix LED-related deadlock on driver unbind Tony Nguyen
2024-04-22 23:32 ` Jacob Keller
2024-04-22 23:37 ` Marek Marczykowski-Górecki
2024-04-22 23:46 ` Jacob Keller
2024-04-23 8:08 ` Lukas Wunner [this message]
2024-04-23 7:53 ` Lukas Wunner
2024-04-25 3:40 ` patchwork-bot+netdevbpf
-- strict thread matches above, loose matches on Subject: below --
2024-04-15 13:48 Lukas Wunner
2024-04-16 13:51 ` Simon Horman
2024-04-16 14:06 ` Kurt Kanzenbach
2024-04-16 20:55 ` Lukas Wunner
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=ZidslwZAYyu4RnJk@wunner.de \
--to=lukas@wunner.de \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=lozko.roma@gmail.com \
--cc=marmarek@invisiblethingslab.com \
--cc=naamax.meir@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sasha.neftin@intel.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 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.