linux-stable.git/drivers/base/firmware_class.c, branch v3.7.4

firmware: make sure the fw file size is not 0

2013-01-21T19:44:32+00:00

commit 4adf07fba3bd64472921a01aae0e116f9f948b77 upstream.

If the requested firmware file size is 0 bytes in the filesytem, we
will try to vmalloc(0), which causes a warning:

  vmalloc: allocation failure: 0 bytes
  kworker/1:1: page allocation failure: order:0, mode:0xd2
    __vmalloc_node_range+0x164/0x208
    __vmalloc_node+0x4c/0x58
    vmalloc+0x38/0x44
    _request_firmware_load+0x220/0x6b0
    request_firmware+0x64/0xc8
    wl18xx_setup+0xb4/0x570 [wl18xx]
    wlcore_nvs_cb+0x64/0x9f8 [wlcore]
    request_firmware_work_func+0x94/0x100
    process_one_work+0x1d0/0x750
    worker_thread+0x184/0x4ac
    kthread+0xb4/0xc0

To fix this, check whether the file size is less than or equal to zero
in fw_read_file_contents().

Signed-off-by: Luciano Coelho 
Acked-by: Ming Lei 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

firmware loader: Fix the concurrent request_firmware() race for kref_get/put

2013-01-11T17:18:16+00:00

commit bd9eb7fbe69111ea0ff1f999ef4a5f26d223d1d5 upstream.

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 
Signed-off-by: liu chuansheng 
Signed-off-by: Greg Kroah-Hartman

firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout

2013-01-11T17:18:16+00:00

commit ce2fcbd99cef580623116bb33531dbc3e6f690b0 upstream.

There is a race as below when calling request_firmware():
CPU1                                   CPU2
write 0 > loading
mutex_lock(&fw_lock)
...
set_bit FW_STATUS_DONE                 class_timeout is coming
                                       set_bit FW_STATUS_ABORT
complete_all &completion
...
mutex_unlock(&fw_lock)

In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
and request_firmware() will return failure due to condition in
_request_firmware_load():
	if (!buf->size || test_bit(FW_STATUS_ABORT, &buf->status))
		retval = -ENOENT;

But from the above scenerio, it should be a successful requesting.
So we need judge if the bit FW_STATUS_DONE is already set before
calling fw_load_abort() in timeout function.

As Ming's proposal, we need change the timer into sched_work to
benefit from using &fw_lock mutex also.

Signed-off-by: liu chuansheng 
Acked-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

firmware loader: sync firmware cache by async_synchronize_full_domain

2012-10-22T15:37:18+00:00

async.c has provided synchronization mechanism on async_schedule_*,
so use async_synchronize_full_domain to sync caching firmware instead
of reinventing the wheel.

Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

firmware loader: let direct loading back on 'firmware_buf'

2012-10-22T15:37:17+00:00

Firstly 'firmware_buf' is introduced to make all loading requests
to share one firmware kernel buffer, so firmware_buf should
be used in direct loading for saving memory and speedup firmware
loading.

Secondly, the commit below

	abb139e75c2cdbb955e840d6331cb5863e409d0e(firmware:teach
	the kernel to load firmware files directly from the filesystem)

introduces direct loading for fixing udev regression, but it
bypasses the firmware cache meachnism, so this patch enables
caching firmware for direct loading case since it is still needed
to solve drivers' dependency during system resume.

Cc: Linus Torvalds 
Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

firmware loader: fix one reqeust_firmware race

2012-10-22T15:37:17+00:00

Several loading requests may be pending on one same
firmware buf, and this patch moves fw_map_pages_buf()
before complete_all(&fw_buf->completion) and let all
requests see the mapped 'buf->data' once the loading
is completed.

Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

firmware loader: cancel uncache work before caching firmware

2012-10-22T15:37:16+00:00

Under 'Opportunistic sleep' situation, system sleep might be
triggered very frequently, so the uncahce work may not be completed
before caching firmware during next suspend.

This patch cancels the uncache work before caching firmware to
fix the problem above.

Also this patch optimizes the cacheing firmware mechanism a bit by
only storing one firmware cache entry for one firmware image.

So if the firmware is still cached during suspend, it doesn't need
to be loaded from user space any more.

Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

firmware: use 'kernel_read()' to read firmware into kernel buffer

2012-10-04T16:19:02+00:00

Fengguang correctly points out that the firmware reading should not use
vfs_read(), since the buffer is in kernel space.

The vfs_read() just happened to work for kernel threads, but sparse
warns about the incorrect address spaces, and it's definitely incorrect
and could fail for other users of the firmware loading.

Reported-by: Fengguang Wu 
Signed-off-by: Linus Torvalds

firmware: teach the kernel to load firmware files directly from the filesystem

2012-10-03T22:58:32+00:00

This is a first step in allowing people to by-pass udev for loading
device firmware.  Current versions of udev will deadlock (causing us to
block for the 30 second timeout) under some circumstances if the
firmware is loaded as part of the module initialization path, and this
is causing problems for media drivers in particular.

The current patch hardcodes the firmware path that udev uses by default,
and will fall back to the legacy udev mode if the firmware cannot be
found there.  We'd like to add support for both configuring the paths
and the fallback behaviour, but in the meantime this hopefully fixes the
immediate problem, while also giving us a way forward.

[ v2: Some VFS layer interface cleanups suggested by Al Viro ]
[ v3: use the default udev paths suggested by Kay Sievers ]

Suggested-by: Ivan Kalvachev 
Acked-by: Greg KH 
Acked-by: Al Viro 
Cc: Mauro Carvalho Chehab 
Cc: Kay Sievers 
Cc: Ming Lei 
Signed-off-by: Linus Torvalds

firmware loader: fix compile warning when CONFIG_PM=n

2012-09-10T23:40:30+00:00

This patch replaces the previous macro of CONFIG_PM with
CONFIG_PM_SLEEP becasue firmware cache is only used in
system sleep situations.

Also this patch fixes the below compile warning when
CONFIG_PM=n:

	drivers/base/firmware_class.c:1147: warning: 'device_cache_fw_images'
	defined but not used
	drivers/base/firmware_class.c:1212: warning:
	'device_uncache_fw_images_delay' defined but not used

Reported-by: Andrew Morton 
Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman