1. 29 2月, 2016 1 次提交
    • L
      firmware: change kernel read fail to dev_dbg() · 8e516aa5
      Luis R. Rodriguez 提交于
      When we now use the new kernel_read_file_from_path() we
      are reporting a failure when we iterate over all the paths
      possible for firmware. Before using kernel_read_file_from_path()
      we only reported a failure once we confirmed a file existed
      with filp_open() but failed with fw_read_file_contents().
      
      With kernel_read_file_from_path() both are done for us and
      we obviously are now reporting too much information given that
      some optional paths will always fail and clutter the logs.
      
      fw_get_filesystem_firmware() already has a check for failure
      and uses an internal flag, FW_OPT_NO_WARN, but this does not
      let us capture other unxpected errors. This enables that
      as changed by Neil via commit:
      
      "firmware: Be a bit more verbose about direct firmware loading failure"
      Reported-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@kernel.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      8e516aa5
  2. 21 2月, 2016 1 次提交
    • M
      firmware: replace call to fw_read_file_contents() with kernel version · e40ba6d5
      Mimi Zohar 提交于
      Replace the fw_read_file_contents with kernel_file_read_from_path().
      
      Although none of the upstreamed LSMs define a kernel_fw_from_file hook,
      IMA is called by the security function to prevent unsigned firmware from
      being loaded and to measure/appraise signed firmware, based on policy.
      
      Instead of reading the firmware twice, once for measuring/appraising the
      firmware and again for reading the firmware contents into memory, the
      kernel_post_read_file() security hook calculates the file hash based on
      the in memory file buffer.  The firmware is read once.
      
      This patch removes the LSM kernel_fw_from_file() hook and security call.
      
      Changelog v4+:
      - revert dropped buf->size assignment - reported by Sergey Senozhatsky
      v3:
      - remove kernel_fw_from_file hook
      - use kernel_file_read_from_path() - requested by Luis
      v2:
      - reordered and squashed firmware patches
      - fix MAX firmware size (Kees Cook)
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NLuis R. Rodriguez <mcgrof@kernel.org>
      e40ba6d5
  3. 19 2月, 2016 3 次提交
  4. 09 2月, 2016 2 次提交
  5. 08 1月, 2016 1 次提交
    • B
      firmware: actually return NULL on failed request_firmware_nowait() · 715780ae
      Brian Norris 提交于
      The kerneldoc for request_firmware_nowait() says that it may call the
      provided cont() callback with @fw == NULL, if the firmware request
      fails. However, this is not the case when called with an empty string
      (""). This case is short-circuited by the 'name[0] == '\0'' check
      introduced in commit 471b095d ("firmware_class: make sure fw requests
      contain a name"), so _request_firmware() never gets to set the fw to
      NULL.
      
      Noticed while using the new 'trigger_async_request' testing hook:
      
          # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request
          [10553.726178] test_firmware: loading ''
          [10553.729859] test_firmware: loaded: 995209091
          # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request
          [10733.676184] test_firmware: loading ''
          [10733.679855] Unable to handle kernel NULL pointer dereference at virtual address 00000004
          [10733.687951] pgd = ec188000
          [10733.690655] [00000004] *pgd=00000000
          [10733.694240] Internal error: Oops: 5 [#1] SMP ARM
          [10733.698847] Modules linked in: btmrvl_sdio btmrvl bluetooth sbs_battery nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables asix usbnet mwifiex_sdio mwifiex cfg80211 jitterentropy_rng drbg joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun
          [10733.725670] CPU: 0 PID: 6600 Comm: bash Not tainted 4.4.0-rc4-00351-g63d0877 #178
          [10733.733137] Hardware name: Rockchip (Device Tree)
          [10733.737831] task: ed24f6c0 ti: ee322000 task.ti: ee322000
          [10733.743222] PC is at do_raw_spin_lock+0x18/0x1a0
          [10733.747831] LR is at _raw_spin_lock+0x18/0x1c
          [10733.752180] pc : [<c00653a0>]    lr : [<c054c204>]    psr: a00d0013
          [10733.752180] sp : ee323df8  ip : ee323e20  fp : ee323e1c
          [10733.763634] r10: 00000051  r9 : b6f18000  r8 : ee323f80
          [10733.768847] r7 : c089cebc  r6 : 00000001  r5 : 00000000  r4 : ec0e6000
          [10733.775360] r3 : dead4ead  r2 : c06bd140  r1 : eef913b4  r0 : 00000000
          [10733.781874] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
          [10733.788995] Control: 10c5387d  Table: 2c18806a  DAC: 00000051
          [10733.794728] Process bash (pid: 6600, stack limit = 0xee322218)
          [10733.800549] Stack: (0xee323df8 to 0xee324000)
          [10733.804896] 3de0:                                                       ec0e6000 00000000
          [10733.813059] 3e00: 00000001 c089cebc ee323f80 b6f18000 ee323e2c ee323e20 c054c204 c0065394
          [10733.821221] 3e20: ee323e44 ee323e30 c02fec60 c054c1f8 ec0e7ec0 ec3fcfc0 ee323e5c ee323e48
          [10733.829384] 3e40: c02fed08 c02fec48 c07dbf74 eeb05a00 ee323e8c ee323e60 c0253828 c02fecac
          [10733.837547] 3e60: 00000001 c0116950 ee323eac ee323e78 00000001 ec3fce00 ed2d9700 ed2d970c
          [10733.845710] 3e80: ee323e9c ee323e90 c02e873c c02537d4 ee323eac ee323ea0 c017bd40 c02e8720
          [10733.853873] 3ea0: ee323ee4 ee323eb0 c017b250 c017bd00 00000000 00000000 f3e47a54 ec128b00
          [10733.862035] 3ec0: c017b10c ee323f80 00000001 c000f504 ee322000 00000000 ee323f4c ee323ee8
          [10733.870197] 3ee0: c011b71c c017b118 ee323fb0 c011bc90 becfa8d9 00000001 ec128b00 00000001
          [10733.878359] 3f00: b6f18000 ee323f80 ee323f4c ee323f18 c011bc90 c0063950 ee323f3c ee323f28
          [10733.886522] 3f20: c0063950 c0549138 00000001 ec128b00 00000001 ec128b00 b6f18000 ee323f80
          [10733.894684] 3f40: ee323f7c ee323f50 c011bed8 c011b6ec c0135fb8 c0135f24 ec128b00 ec128b00
          [10733.902847] 3f60: 00000001 b6f18000 c000f504 ee322000 ee323fa4 ee323f80 c011c664 c011be24
          [10733.911009] 3f80: 00000000 00000000 00000001 b6f18000 b6e79be0 00000004 00000000 ee323fa8
          [10733.919172] 3fa0: c000f340 c011c618 00000001 b6f18000 00000001 b6f18000 00000001 00000000
          [10733.927334] 3fc0: 00000001 b6f18000 b6e79be0 00000004 00000001 00000001 8068a3f1 b6e79c84
          [10733.935496] 3fe0: 00000000 becfa7dc b6de194d b6e20246 400d0030 00000001 7a4536e8 49bda390
          [10733.943664] [<c00653a0>] (do_raw_spin_lock) from [<c054c204>] (_raw_spin_lock+0x18/0x1c)
          [10733.951743] [<c054c204>] (_raw_spin_lock) from [<c02fec60>] (fw_free_buf+0x24/0x64)
          [10733.959388] [<c02fec60>] (fw_free_buf) from [<c02fed08>] (release_firmware+0x68/0x74)
          [10733.967207] [<c02fed08>] (release_firmware) from [<c0253828>] (trigger_async_request_store+0x60/0x124)
          [10733.976501] [<c0253828>] (trigger_async_request_store) from [<c02e873c>] (dev_attr_store+0x28/0x34)
          [10733.985533] [<c02e873c>] (dev_attr_store) from [<c017bd40>] (sysfs_kf_write+0x4c/0x58)
          [10733.993437] [<c017bd40>] (sysfs_kf_write) from [<c017b250>] (kernfs_fop_write+0x144/0x1a8)
          [10734.001689] [<c017b250>] (kernfs_fop_write) from [<c011b71c>] (__vfs_write+0x3c/0xe4)
      
      After this patch:
      
          # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request
          [   32.126322] test_firmware: loading ''
          [   32.129995] test_firmware: failed to async load firmware
          -bash: printf: write error: No such device
      
      Fixes: 471b095d ("firmware_class: make sure fw requests contain a name")
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      Acked-by: NMing Lei <ming.lei@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
      715780ae
  6. 06 8月, 2015 1 次提交
  7. 10 7月, 2015 1 次提交
  8. 01 6月, 2015 1 次提交
  9. 25 5月, 2015 4 次提交
    • L
      firmware: use const for remaining firmware names · e0fd9b1d
      Luis R. Rodriguez 提交于
      We currently use flexible arrays with a char at the
      end for the remaining internal firmware name uses.
      There are two limitations with the way we use this.
      Since we're using a flexible array for a string on the
      struct if we wanted to use two strings it means we'd
      have a disjoint means of handling the strings, one
      using the flexible array, and another a char * pointer.
      We're also currently not using 'const' for the string.
      
      We wish to later extend some firmware data structures
      with other string/char pointers, but we also want to be
      very pedantic about const usage. Since we're going to
      change things to use 'const' we might as well also address
      unified way to use multiple strings on the structs.
      
      Replace the flexible array practice for strings with
      kstrdup_const() and kfree_const(), this will avoid
      allocations when the vmlinux .rodata is used, and just
      allocate a new proper string for us when needed. This
      also means we can simplify the struct allocations by
      removing the string length from the allocation size
      computation, which would otherwise get even more
      complicated when supporting multiple strings.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Kyle McMartin <kyle@kernel.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0fd9b1d
    • L
      firmware: fix possible use after free on name on asynchronous request · f9692b26
      Luis R. Rodriguez 提交于
      Asynchronous firmware loading copies the pointer to the
      name passed as an argument only to be scheduled later and
      used. This behaviour works well for synchronous calling
      but in asynchronous mode there's a chance the caller could
      immediately free the passed string after making the
      asynchronous call. This could trigger a use after free
      having the kernel look on disk for arbitrary file names.
      
      In order to force-test the issue you can use a test-driver
      designed to illustrate this issue on github [0], use the
      next-20150505-fix-use-after-free branch.
      
      With this patch applied you get:
      
      [  283.512445] firmware name: test_module_stuff.bin
      [  287.514020] firmware name: test_module_stuff.bin
      [  287.532489] firmware found
      
      Without this patch applied you can end up with something such as:
      
      [  135.624216] firmware name: \xffffff80BJ
      [  135.624249] platform fake-dev.0: Direct firmware load for \xffffff80Bi failed with error -2
      [  135.624252] No firmware found
      [  135.624252] firmware found
      
      Unfortunatley in the worst and most common case however you
      can typically crash your system with a page fault by trying to
      free something which you cannot, and/or a NULL pointer
      dereference [1].
      
      The fix and issue using schedule_work() for asynchronous
      runs is generalized in the following SmPL grammar patch,
      when applied to next-20150505 only the firmware_class
      code is affected. This grammar patch can and should further
      be generalized to vet for for other kernel asynchronous
      mechanisms.
      
      @ calls_schedule_work @
      type T;
      T *priv_work;
      identifier func, work_func;
      identifier work;
      identifier priv_name, name;
      expression gfp;
      @@
      
       func(..., const char *name, ...)
       {
       	...
       	priv_work = kzalloc(sizeof(T), gfp);
       	...
      -	priv_work->priv_name = name;
      +	priv_work->priv_name = kstrdup_const(name, gfp);
      	...
      (... when any
       	if (...)
       	{
       		...
      + 		kfree_const(priv_work->priv_name);
       		kfree(priv_work);
      		...
       	}
      ) ... when any
       	INIT_WORK(&priv_work->work, work_func);
       	...
       	schedule_work(&priv_work->work);
       	...
       }
      
      @ the_work_func depends on calls_schedule_work @
      type calls_schedule_work.T;
      T *priv_work;
      identifier calls_schedule_work.work_func;
      identifier calls_schedule_work.priv_name;
      identifier calls_schedule_work.work;
      identifier some_work;
      @@
      
       work_func(...)
       {
       	...
       	priv_work = container_of(some_work, T, work);
       	...
      +	kfree_const(priv_work->priv_name);
       	kfree(priv_work);
       	...
       }
      
      [0] https://github.com/mcgrof/fake-firmware-test.git
      [1] The following kernel ring buffer splat:
      
      firmware name: test_module_stuff.bin
      firmware name:
      firmware found
      general protection fault: 0000 [#1] SMP
      Modules linked in: test(O) <...etc-it-does-not-matter>
       drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
      CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G           O    4.0.0-00010-g22b5bb0-dirty #176
      Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
      Workqueue: events request_firmware_work_func
      task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
      RIP: 0010:[<ffffffff814a586c>]  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
      RSP: 0000:ffff8800c7f97d78  EFLAGS: 00010286
      RAX: ffffffff81ae3700 RBX: ffffffff816d1181 RCX: 0000000000000006
      RDX: 0001ee850ff68500 RSI: 0000000000000246 RDI: c35d5f415e415d41
      RBP: ffff8800c7f97d88 R08: 000000000000000a R09: 0000000000000000
      R10: 0000000000000358 R11: ffff8800c7f97a7e R12: ffff8800c7ec1e80
      R13: ffff88021e2d4cc0 R14: ffff88021e2dff00 R15: 00000000000000c0
      FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000034b8cd8 CR3: 000000021073c000 CR4: 00000000001407e0
      Stack:
       ffffffff816d1181 ffff8800c7ec1e80 ffff8800c7f97da8 ffffffff814a58f8
       000000000000000a ffffffff816d1181 ffff8800c7f97dc8 ffffffffa047002c
       ffff88021e2dff00 ffff8802116ac1c0 ffff8800c7f97df8 ffffffff814a65fe
      Call Trace:
       [<ffffffff816d1181>] ? __schedule+0x361/0x940
       [<ffffffff814a58f8>] release_firmware+0x58/0x80
       [<ffffffff816d1181>] ? __schedule+0x361/0x940
       [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
       [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
       [<ffffffff816d1181>] ? __schedule+0x361/0x940
       [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
       [<ffffffff8108d911>] worker_thread+0x121/0x460
       [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
       [<ffffffff810928f9>] kthread+0xc9/0xe0
       [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
       [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
       [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
      Code: c7 c6 dd ad a3 81 48 c7 c7 20 97 ce 81 31 c0 e8 0b b2 ed ff e9 78 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 53 <4c> 8b 67 38 48 89 fb 4c 89 e7 e8 85 f7 22 00 f0 83 2b 01 74 0f
      RIP  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
       RSP <ffff8800c7f97d78>
      ---[ end trace 4e62c56a58d0eac1 ]---
      BUG: unable to handle kernel paging request at ffffffffffffffd8
      IP: [<ffffffff81093ee0>] kthread_data+0x10/0x20
      PGD 1c13067 PUD 1c15067 PMD 0
      Oops: 0000 [#2] SMP
      Modules linked in: test(O) <...etc-it-does-not-matter>
       drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
      CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G      D    O    4.0.0-00010-g22b5bb0-dirty #176
      Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
      task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
      RIP: 0010:[<ffffffff81092ee0>]  [<ffffffff81092ee0>] kthread_data+0x10/0x20
      RSP: 0018:ffff8800c7f97b18  EFLAGS: 00010096
      RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000000d
      RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffff8800c7f8e290
      RBP: ffff8800c7f97b18 R08: 000000000000bc00 R09: 0000000000007e76
      R10: 0000000000000001 R11: 000000000000002f R12: ffff8800c7f8e290
      R13: 00000000000154c0 R14: 0000000000000003 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000028 CR3: 0000000210675000 CR4: 00000000001407e0
      Stack:
       ffff8800c7f97b38 ffffffff8108dcd5 ffff8800c7f97b38 ffff88021e2d54c0
       ffff8800c7f97b88 ffffffff816d1500 ffff880213d42368 ffff8800c7f8e290
       ffff8800c7f97b88 ffff8800c7f97fd8 ffff8800c7f8e710 0000000000000246
      Call Trace:
       [<ffffffff8108dcd5>] wq_worker_sleeping+0x15/0xa0
       [<ffffffff816d1500>] __schedule+0x6e0/0x940
       [<ffffffff816d1797>] schedule+0x37/0x90
       [<ffffffff810779bc>] do_exit+0x6bc/0xb40
       [<ffffffff8101898f>] oops_end+0x9f/0xe0
       [<ffffffff81018efb>] die+0x4b/0x70
       [<ffffffff81015622>] do_general_protection+0xe2/0x170
       [<ffffffff816d74e8>] general_protection+0x28/0x30
       [<ffffffff816d1181>] ? __schedule+0x361/0x940
       [<ffffffff814a586c>] ? fw_free_buf+0xc/0x40
       [<ffffffff816d1181>] ? __schedule+0x361/0x940
       [<ffffffff814a58f8>] release_firmware+0x58/0x80
       [<ffffffff816d1181>] ? __schedule+0x361/0x940
       [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
       [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
       [<ffffffff816d1181>] ? __schedule+0x361/0x940
       [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
       [<ffffffff8108d911>] worker_thread+0x121/0x460
       [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
       [<ffffffff810928f9>] kthread+0xc9/0xe0
       [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
       [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
       [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
      Code: 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 87 30 05 00 00 55 48 89 e5 <48> 8b 40 d8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
      RIP  [<ffffffff81092ee0>] kthread_data+0x10/0x20
       RSP <ffff8800c7f97b18>
      CR2: ffffffffffffffd8
      ---[ end trace 4e62c56a58d0eac2 ]---
      Fixing recursive fault but reboot is needed!
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Kyle McMartin <kyle@kernel.org>
      Generated-by: Coccinelle SmPL
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9692b26
    • L
      firmware: check for file truncation on direct firmware loading · 1ba4de17
      Luis R. Rodriguez 提交于
      When direct firmware loading is used we iterate over a list
      of possible firmware paths and concatenate the desired firmware
      name with each path and look for the file there. Should the
      passed firmware name be too long we end up truncating the
      file we want to look for, the search however is still done.
      Add a check for truncation instead of looking for a
      truncated firmware filename.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@kernel.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ba4de17
    • L
      firmware: fix __getname() missing failure check · f5727b05
      Luis R. Rodriguez 提交于
      The request_firmware*() APIs uses __getname() to iterate
      over the list of paths possible for firmware to be found,
      the code however never checked for failure on __getname().
      Although *very unlikely*, this can still happen. Add the
      missing check.
      
      There is still no checks on the concatenation of the path
      and filename passed, that requires a bit more work and
      subsequent patches address this. The commit that introduced
      this is abb139e7 ("firmware: teach the kernel to load
      firmware files directly from the filesystem").
      
      mcgrof@ergon ~/linux (git::firmware-fixes) $ git describe --contains abb139e7
      v3.7-rc1~120
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@kernel.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5727b05
  10. 25 3月, 2015 3 次提交
  11. 12 2月, 2015 1 次提交
  12. 04 2月, 2015 3 次提交
  13. 27 11月, 2014 2 次提交
    • M
      firmware class: Deletion of an unnecessary check before the function call "vunmap" · daa3d67f
      Markus Elfring 提交于
      The vunmap() function performes also input parameter validation. Thus the test
      around the call is not needed.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      daa3d67f
    • K
      firmware loader: fix hung task warning dump · 000deba7
      Kweh, Hock Leong 提交于
      When using request_firmware_nowait() with FW_ACTION_NOHOTPLUG param to
      expose user helper interface, if the user do not react immediately, after
      120 seconds there will be a hung task warning message dumped as below:
      
      [ 3000.784235] INFO: task kworker/0:0:8259 blocked for more than 120 seconds.
      [ 3000.791281]       Tainted: G            E 3.16.0-rc1-yocto-standard #41
      [ 3000.798082] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 3000.806072] kworker/0:0     D cd0075c8     0  8259      2 0x00000000
      [ 3000.812765] Workqueue: events request_firmware_work_func
      [ 3000.818253]  cd375e18 00000046 0000000e cd0075c8 000000f0 cd40ea00 cd375fec 1b883e89
      [ 3000.826374]  0000026b cd40ea00 80000000 00000001 cd0075c8 00000000 cd375de4 c119917f
      [ 3000.834492]  cd563360 cd375df4 c119a0ab cd563360 00000000 cd375e24 c119a1d6 00000000
      [ 3000.842616] Call Trace:
      [ 3000.845252]  [<c119917f>] ? kernfs_next_descendant_post+0x3f/0x50
      [ 3000.851543]  [<c119a0ab>] ? kernfs_activate+0x6b/0xc0
      [ 3000.856790]  [<c119a1d6>] ? kernfs_add_one+0xd6/0x130
      [ 3000.862047]  [<c15fdb02>] schedule+0x22/0x60
      [ 3000.866548]  [<c15fd195>] schedule_timeout+0x175/0x1d0
      [ 3000.871887]  [<c119b391>] ? __kernfs_create_file+0x71/0xa0
      [ 3000.877574]  [<c119bb9a>] ? sysfs_add_file_mode_ns+0xaa/0x180
      [ 3000.883533]  [<c15fe84f>] wait_for_completion+0x6f/0xb0
      [ 3000.888961]  [<c1065200>] ? wake_up_process+0x40/0x40
      [ 3000.894219]  [<c13cb600>] _request_firmware+0x750/0x9f0
      [ 3000.899666]  [<c1382a7f>] ? n_tty_receive_buf2+0x1f/0x30
      [ 3000.905200]  [<c13cba02>] request_firmware_work_func+0x22/0x50
      [ 3000.911235]  [<c10550d2>] process_one_work+0x122/0x380
      [ 3000.916571]  [<c1055859>] worker_thread+0xf9/0x470
      [ 3000.921555]  [<c1055760>] ? create_and_start_worker+0x50/0x50
      [ 3000.927497]  [<c1055760>] ? create_and_start_worker+0x50/0x50
      [ 3000.933448]  [<c105a5ff>] kthread+0x9f/0xc0
      [ 3000.937850]  [<c15ffd40>] ret_from_kernel_thread+0x20/0x30
      [ 3000.943548]  [<c105a560>] ? kthread_worker_fn+0x100/0x100
      
      This patch change the wait_for_completion() function call to
      wait_for_completion_interruptible() function call for solving the issue.
      
      Cc: Matt Fleming <matt.fleming@intel.com>
      Signed-off-by: NKweh, Hock Leong <hock.leong.kweh@intel.com>
      Acked-by: NMing Lei <ming.lei@canonical.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      000deba7
  14. 24 9月, 2014 1 次提交
  15. 26 7月, 2014 1 次提交
  16. 24 7月, 2014 1 次提交
  17. 09 7月, 2014 4 次提交
    • L
      firmware loader: inform direct failure when udev loader is disabled · c868edf4
      Luis R. Rodriguez 提交于
      Now that the udev firmware loader is optional request_firmware()
      will not provide any information on the kernel ring buffer if
      direct firmware loading failed and udev firmware loading is disabled.
      If no information is needed request_firmware_direct() should be used
      for optional firmware, at which point drivers can take on the onus
      over informing of any failures, if udev firmware loading is disabled
      though we should at the very least provide some sort of information
      as when the udev loader was enabled by default back in the days.
      
      With this change with a simple firmware load test module [0]:
      
      Example output without FW_LOADER_USER_HELPER_FALLBACK
      
      platform fake-dev.0: Direct firmware load for fake.bin failed
      with error -2
      
      Example with FW_LOADER_USER_HELPER_FALLBACK
      
      platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
      platform fake-dev.0: Falling back to user helper
      
      Without this change without FW_LOADER_USER_HELPER_FALLBACK we
      get no output logged upon failure.
      
      Cc: Tom Gundersen <teg@jklm.no>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Abhay Salunke <Abhay_Salunke@dell.com>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c868edf4
    • F
      firmware: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN · a76040d8
      Fabian Frederick 提交于
      use mm.h definition
      
      Cc: Ming Lei <ming.lei@canonical.com>
      Signed-off-by: NFabian Frederick <fabf@skynet.be>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a76040d8
    • D
      firmware: read firmware size using i_size_read() · 6af6b163
      Dmitry Kasatkin 提交于
      There is no need to read attr because inode structure contains size
      of the file. Use i_size_read() instead.
      Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Acked-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6af6b163
    • T
      firmware loader: allow disabling of udev as firmware loader · 5a1379e8
      Takashi Iwai 提交于
      [The patch was originally proposed by Tom Gundersen, and rewritten
       afterwards by me; most of changelogs below borrowed from Tom's
       original patch -- tiwai]
      
      Currently (at least) the dell-rbu driver selects FW_LOADER_USER_HELPER,
      which means that distros can't really stop loading firmware through
      udev without breaking other users (though some have).
      
      Ideally we would remove/disable the udev firmware helper in both the
      kernel and in udev, but if we were to disable it in udev and not the
      kernel, the result would be (seemingly) hung kernels as no one would
      be around to cancel firmware requests.
      
      This patch allows udev firmware loading to be disabled while still
      allowing non-udev firmware loading, as done by the dell-rbu driver, to
      continue working. This is achieved by only using the fallback
      mechanism when the uevent is suppressed.
      
      The patch renames the user-selectable Kconfig from FW_LOADER_USER_HELPER
      to FW_LOADER_USER_HELPER_FALLBACK, and the former is reverse-selected
      by the latter or the drivers that need userhelper like dell-rbu.
      
      Also, the "default y" is removed together with this change, since it's
      been deprecated in udev upstream, thus rather better to disable it
      nowadays.
      
      Tested with
          FW_LOADER_USER_HELPER=n
          LATTICE_ECP3_CONFIG=y
          DELL_RBU=y
      and udev without the firmware loading support, but I don't have the
      hardware to test the lattice/dell drivers, so additional testing would
      be appreciated.
      Reviewed-by: NTom Gundersen <teg@jklm.no>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Abhay Salunke <Abhay_Salunke@dell.com>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Kay Sievers <kay@vrfy.org>
      Tested-by: NBalaji Singh <B_B_Singh@DELL.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a1379e8
  18. 26 2月, 2014 1 次提交
  19. 16 2月, 2014 2 次提交
    • S
      firmware: use power efficient workqueue for unloading and aborting fw load · bce6618a
      Shaibal Dutta 提交于
      Allow the scheduler to select the most appropriate CPU for running the
      firmware load timeout routine and delayed routine for firmware unload.
      This extends idle residency times and conserves power.
      
      This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
      
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NShaibal Dutta <shaibal.dutta@broadcom.com>
      [zoran.markovic@linaro.org: Rebased to latest kernel, added commit message.
      Fixed code alignment.]
      Signed-off-by: NZoran Markovic <zoran.markovic@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bce6618a
    • Z
      firmware: give a protection when map page failed · 2b1278cb
      zhang jun 提交于
      so, we need give a protection and return a error value.
      [ 7341.474236] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work!
      [ 7341.494464] atomisp-css2400b0_v21 0000:00:03.0: unhandled css stored event: 0x20
      [ 7341.503627] vmap allocation for size 208896 failed: use vmalloc=<size> to increase size.<=================== map failed
      [ 7341.507135] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work!
      [ 7341.503848] BUG: unable to handle kernel NULL pointer dereference at   (null)
      [ 7341.520394] IP: [<c18f5c1b>] sst_load_all_modules_elf+0x1bb/0x850
      [ 7341.527216] *pdpt = 0000000030dfe001 *pde = 0000000000000000
      [ 7341.533640] Oops: 0000 [#1] PREEMPT SMP
      [ 7341.540360] [drm:do_intel_finish_page_flip] *ERROR* invalid or inactive unpin_work!
      [ 7341.538037] Modules linked in: atomisp_css2400b0_v21 lm3554 ov2722 imx1x5 atmel_mxt_ts vxd392 videobuf_vmalloc videobuf_core lm_dump(O) bcm_bt_lpm hdmi_audio bcm4334x(O)
      [ 7341.563531] CPU: 1 PID: 525 Comm: mediaserver Tainted: G        W  O 3.10.20-262518-ga83c053 #1
      [ 7341.573253] task: f0994ec0 ti: f09f0000 task.ti: f09f0000
      [ 7341.579284] EIP: 0060:[<c18f5c1b>] EFLAGS: 00010246 CPU: 1
      [ 7341.585415] EIP is at sst_load_all_modules_elf+0x1bb/0x850
      [ 7341.591541] EAX: 00000000 EBX: e3595ba0 ECX: 00000000 EDX: 00031c1c
      [ 7341.598541] ESI: e04a0000 EDI: 00000000 EBP: f09f1d80 ESP: f09f1cf4
      [ 7341.605542]  DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068
      [ 7341.611573] CR0: 80050033 CR2: 00000000 CR3: 30db4000 CR4: 001007f0
      [ 7341.618573] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [ 7341.625575] DR6: ffff0ff0 DR7: 00000400
      [ 7341.629856] Stack:
      [ 7341.632097]  f09f1d57 00000019 c1d656d7 c1d658d3 c1d56409 00000f28 c1d64af9 18000103
      [ 7341.640766]  01000001 00080000 c1f910a0 f326f4c8 00000034 f326f520 00000002 e04a02bc
      [ 7341.649465]  00000001 f326e014 c1f910b0 e04a0000 c0080100 00031c1c e3595ba0 c0080100
      [ 7341.658149] Call Trace:
      [ 7341.660888]  [<c18f6308>] sst_post_download_byt+0x58/0xb0
      [ 7341.666925]  [<c18f4fbc>] sst_load_fw+0xdc/0x510
      [ 7341.672086]  [<c1a7b2c0>] ? __mutex_lock_slowpath+0x250/0x370
      [ 7341.678507]  [<c1a80e05>] ? sub_preempt_count+0x55/0xe0
      [ 7341.684346]  [<c18f1294>] sst_download_fw+0x14/0x60
      [ 7341.689796]  [<c1a7b403>] ? mutex_lock+0x23/0x30
      [ 7341.694954]  [<c18f191c>] intel_sst_check_device+0x6c/0x120
      [ 7341.701181]  [<c18f1d08>] sst_set_generic_params+0x1b8/0x4a0
      [ 7341.707504]  [<c1a80e05>] ? sub_preempt_count+0x55/0xe0
      [ 7341.713341]  [<c1a80e05>] ? sub_preempt_count+0x55/0xe0
      [ 7341.719178]  [<c1a7b2c0>] ? __mutex_lock_slowpath+0x250/0x370
      [ 7341.725600]  [<c1320d84>] ? __kmalloc_track_caller+0xe4/0x1d0
      [ 7341.732022]  [<c18e35f5>] sst_set_mixer_param+0x25/0x40
      [ 7341.737859]  [<c18e3853>] lpe_mixer_ihf_set+0xb3/0x160
      [ 7341.743602]  [<c1855b99>] snd_ctl_ioctl+0xa89/0xb40
      [ 7341.749052]  [<c1331e65>] ? path_openat+0xa5/0x3d0
      [ 7341.754409]  [<c1447857>] ? avc_has_perm_flags+0xc7/0x170
      [ 7341.760441]  [<c1855110>] ? snd_ctl_elem_add_user+0x540/0x540
      [ 7341.766862]  [<c1334047>] do_vfs_ioctl+0x77/0x5e0
      [ 7341.772117]  [<c144842a>] ? inode_has_perm.isra.42.constprop.79+0x3a/0x50
      [ 7341.779705]  [<c14490a0>] ? file_has_perm+0xa0/0xb0
      [ 7341.785155]  [<c14493b8>] ? selinux_file_ioctl+0x48/0xe0
      [ 7341.791090]  [<c1334628>] SyS_ioctl+0x78/0x90
      [ 7341.795958]  [<c1a7dde8>] syscall_call+0x7/0xb
      [ 7341.800925]  [<c1a70000>] ? mm_fault_error+0x13c/0x198
      Signed-off-by: Nzhang jun <jun.zhang@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b1278cb
  20. 09 1月, 2014 2 次提交
  21. 09 12月, 2013 3 次提交
  22. 27 9月, 2013 1 次提交