summaryrefslogtreecommitdiff
path: root/drivers/firmware
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2024-02-29 15:36:20 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-03-07 22:08:15 +0000
commit952c3fce297f12c7ff59380adb66b564e2bc9b64 (patch)
tree67c07a10551559d5b97d9333d1b64e57fa3e3062 /drivers/firmware
parent4dc3d612ee5c3be2a4d1a73ab31bcfaaa850aa19 (diff)
debugfs: fix wait/cancellation handling during remove
Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses debugfs cancellations. Turns out that despite all the review on the locking, we missed completely that the logic is wrong: if the refcount hits zero we can finish (and need not wait for the completion), but if it doesn't we have to trigger all the cancellations. As written, we can _never_ get into the loop triggering the cancellations. Fix this, and explain it better while at it. Cc: stable@vger.kernel.org Fixes: 8c88a474357e ("debugfs: add API to allow debugfs operations cancellation") Reported-by: Ben Greear <greearb@candelatech.com> Closes: https://lore.kernel.org/r/1c9fa9e5-09f1-0522-fdbc-dbcef4d255ca@candelatech.com Tested-by: Madhan Sai <madhan.singaraju@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20240229153635.6bfab7eb34d3.I6c7aeff8c9d6628a8bc1ddcf332205a49d801f17@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/firmware')
0 files changed, 0 insertions, 0 deletions