summaryrefslogtreecommitdiff
path: root/drivers/net/hyperv
diff options
context:
space:
mode:
authorChuansheng Liu <chuansheng.liu@intel.com>2012-11-09 21:27:22 +0400
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-11-15 03:04:23 +0400
commitbd9eb7fbe69111ea0ff1f999ef4a5f26d223d1d5 (patch)
treef8dbda4472687bebbb757a0835c6d1441a984abc /drivers/net/hyperv
parentce2fcbd99cef580623116bb33531dbc3e6f690b0 (diff)
downloadlinux-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