1. 10 6月, 2015 1 次提交
  2. 01 6月, 2015 6 次提交
  3. 27 5月, 2015 1 次提交
  4. 25 5月, 2015 8 次提交
    • 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
    • S
      drivers: of/base: move of_init to driver_init · f4445f8b
      Sudeep Holla 提交于
      Commit 5590f319 ("drivers/core/of: Add symlink to device-tree from
      devices with an OF node") adds the symlink `of_node` for each device
      pointing to it's device tree node while creating/initialising it.
      
      However the devicetree sysfs is created and setup in of_init which is
      executed at core_initcall level. For all the devices created before
      of_init, the following error is thrown:
      	"Error -2(-ENOENT) creating of_node link"
      
      Like many other components in driver model, initialize the sysfs support
      for OF/devicetree from driver_init so that it's ready before any devices
      are created.
      
      Fixes: 5590f319 ("drivers/core/of: Add symlink to device-tree from
      	devices with an OF node")
      Suggested-by: NRob Herring <robh+dt@kernel.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Tested-by: NRobert Schwebel <r.schwebel@pengutronix.de>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4445f8b
    • W
      drivers/base: cacheinfo: fix annoying typo when DT nodes are absent · 2539b258
      Will Deacon 提交于
      s/hierarcy/hierarchy/
      
      Maybe the typo will annoy people enough so that they add the missing
      nodes to their device-tree files, but I still think this is better off
      fixed.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2539b258
    • D
      driver-core: fix build for !CONFIG_MODULES · 80c6e146
      Dmitry Torokhov 提交于
      Commit f2411da7 ("driver-core: add driver module asynchronous probe
      support") broke build in case modules are disabled, because in this case
      "struct module" is not defined and we can't dereference it. Let's define
      module_requested_async_probing() helper and stub it out if modules are
      disabled.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c6e146
    • D
      driver-core: make __device_attach() static · 802a87fd
      Dmitry Torokhov 提交于
      It is only used within dd.c and thus need not be global.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      802a87fd
  5. 20 5月, 2015 6 次提交
  6. 16 4月, 2015 2 次提交
  7. 15 4月, 2015 2 次提交
    • D
      mm, hotplug: fix concurrent memory hot-add deadlock · 30467e0b
      David Rientjes 提交于
      There's a deadlock when concurrently hot-adding memory through the probe
      interface and switching a memory block from offline to online.
      
      When hot-adding memory via the probe interface, add_memory() first takes
      mem_hotplug_begin() and then device_lock() is later taken when registering
      the newly initialized memory block.  This creates a lock dependency of (1)
      mem_hotplug.lock (2) dev->mutex.
      
      When switching a memory block from offline to online, dev->mutex is first
      grabbed in device_online() when the write(2) transitions an existing
      memory block from offline to online, and then online_pages() will take
      mem_hotplug_begin().
      
      This creates a lock inversion between mem_hotplug.lock and dev->mutex.
      Vitaly reports that this deadlock can happen when kworker handling a probe
      event races with systemd-udevd switching a memory block's state.
      
      This patch requires the state transition to take mem_hotplug_begin()
      before dev->mutex.  Hot-adding memory via the probe interface creates a
      memory block while holding mem_hotplug_begin(), there is no way to take
      dev->mutex first in this case.
      
      online_pages() and offline_pages() are only called when transitioning
      memory block state.  We now require that mem_hotplug_begin() is taken
      before calling them -- this requires exporting the mem_hotplug_begin() and
      mem_hotplug_done() to generic code.  In all hot-add and hot-remove cases,
      mem_hotplug_begin() is done prior to device_online().  This is all that is
      needed to avoid the deadlock.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Reported-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Zhang Zhen <zhenzhang.zhang@huawei.com>
      Cc: Vladimir Davydov <vdavydov@parallels.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      30467e0b
    • S
      memory hotplug: use macro to switch between section and pfn · 19c07d5e
      Sheng Yong 提交于
      Use macro section_nr_to_pfn() to switch between section and pfn, instead
      of open-coding it.  No semantic changes.
      Signed-off-by: NSheng Yong <shengyong1@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      19c07d5e
  8. 04 4月, 2015 2 次提交
    • R
      device property: Introduce firmware node type for platform data · 16ba08d5
      Rafael J. Wysocki 提交于
      Introduce data structures and code allowing "built-in" properties
      to be associated with devices in such a way that they will be used
      by the device_property_* API if no proper firmware node (neither DT
      nor ACPI) is present for the given device.
      
      Each property is to be represented by a property_entry structure.
      An array of property_entry structures (terminated with a null
      entry) can be pointed to by the properties field of struct
      property_set that can be added as a firmware node to a struct
      device using device_add_property_set().  That will cause the
      device_property_* API to use that property_set as the source
      of properties if the given device does not have a DT node or
      an ACPI companion device object associated with it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16ba08d5
    • R
      device property: Make it possible to use secondary firmware nodes · 97badf87
      Rafael J. Wysocki 提交于
      Add a secondary pointer to struct fwnode_handle so as to make it
      possible for a device to have two firmware nodes associated with
      it at the same time, for example, an ACPI node and a node with
      a set of properties provided by platform initialization code.
      
      In the future that will allow device property lookup to fall back
      from the primary firmware node to the secondary one if the given
      property is not present there to make it easier to provide defaults
      for device properties used by device drivers.
      
      Introduce two helper routines, set_primary_fwnode() and
      set_secondary_fwnode() allowing callers to add a primary/secondary
      firmware node to the given device in such a way that
      
       (1) If there's only one firmware node for that device, it will be
           pointed to by the device's firmware node pointer.
       (2) If both the primary and secondary firmware nodes are present,
           the primary one will be pointed to by the device's firmware
           node pointer, while the secondary one will be pointed to by the
           primary node's secondary pointer.
       (3) If one of these nodes is removed (by calling one of the new
           nelpers with NULL as the second argument), the other one will
           be preserved.
      
      Make ACPI use set_primary_fwnode() for attaching its firmware nodes
      to devices.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97badf87
  9. 26 3月, 2015 2 次提交
  10. 25 3月, 2015 10 次提交