diff options
author | Chuansheng Liu <chuansheng.liu@intel.com> | 2012-11-09 21:27:22 +0400 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2012-11-15 03:04:23 +0400 |
commit | bd9eb7fbe69111ea0ff1f999ef4a5f26d223d1d5 (patch) | |
tree | f8dbda4472687bebbb757a0835c6d1441a984abc /drivers/net/hyperv | |
parent | ce2fcbd99cef580623116bb33531dbc3e6f690b0 (diff) | |
download | linux-bd9eb7fbe69111ea0ff1f999ef4a5f26d223d1d5.tar.xz |
firmware loader: Fix the concurrent request_firmware() race for kref_get/put
There is one race that both request_firmware() with the same
firmware name.
The race scenerio is as below:
CPU1 CPU2
request_firmware() -->
_request_firmware_load() return err another request_firmware() is coming -->
_request_firmware_cleanup is called --> _request_firmware_prepare -->
release_firmware ---> fw_lookup_and_allocate_buf -->
spin_lock(&fwc->lock)
... __fw_lookup_buf() return true
fw_free_buf() will be called --> ...
kref_put -->
decrease the refcount to 0
kref_get(&tmp->ref) ==> it will trigger warning
due to refcount == 0
__fw_free_buf() -->
... spin_unlock(&fwc->lock)
spin_lock(&fwc->lock)
list_del(&buf->list)
spin_unlock(&fwc->lock)
kfree(buf)
After that, the freed buf will be used.
The key race is decreasing refcount to 0 and list_del is not protected together by
fwc->lock, and it is possible another thread try to get it between refcount==0
and list_del.
Fix it here to protect it together.
Acked-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/net/hyperv')
0 files changed, 0 insertions, 0 deletions