gpiolib: Don't bypass SRCU when CONFIG_LOCKDEP is enabled - #7548
Merged
pelwell merged 1 commit intoAug 12, 2026
Conversation
Commit 6c96741 ("gpiolib: Avoid the hotplug performance reduction") stubs out gpiolib's SRCU read-side locking to recover the throughput lost to the hotplug interlock. That trade-off is deliberate, but it leaves the core's lockdep_assert_held(&gc->gpiodev->srcu) checks in place while the lock is never actually taken. Since those are WARN_ON(), every GPIO access splats with CONFIG_LOCKDEP=y and the log fills up with backtraces. Therefore, only enable REJECT_HOTPLUG_TAX when CONFIG_LOCKDEP is disabled. This way, the optimisation is kept for production builds, but developers can still debug the kernel with lockdep enabled. Fixes: 6c96741 ("gpiolib: Avoid the hotplug performance reduction") Signed-off-by: Maíra Canal <mcanal@igalia.com>
Contributor
|
Funny, I've stumbled over this very same issue last week with a colleague. In order to reduce the initial penalty upstream I'm currently testing something like this nbuchwitz@1ed0cf1 Testing shows that this at least halves the penalty, but probably has other caveats. Happy to keep you in the loop once / if I send the patches. |
pelwell
approved these changes
Aug 11, 2026
pelwell
left a comment
pelwell
left a comment
Contributor
There was a problem hiding this comment.
A pragmatic solution, and easy to understand.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commit 6c96741 ("gpiolib: Avoid the hotplug performance reduction") stubs out gpiolib's SRCU read-side locking to recover the throughput lost to the hotplug interlock. That trade-off is deliberate, but it leaves the core's lockdep_assert_held(&gc->gpiodev->srcu) checks in place while the lock is never actually taken. Since those are WARN_ON(), every GPIO access splats with CONFIG_LOCKDEP=y and the log fills up with backtraces.
Therefore, only enable REJECT_HOTPLUG_TAX when CONFIG_LOCKDEP is disabled. This way, the optimisation is kept for production builds, but developers can still debug the kernel with lockdep enabled.
I found this issue while testing the DRM scheduler series for VC4 with LOCKDEP enabled. This commit might be useful for other RPi developers in the kernel, but I can understand that it also brings the maintenance cost of increasing the delta to upstream. If you believe that it's not worth the cost, feel free to close this MR.