linux-stable.git/drivers/base, branch v4.1.41

firmware: fix usermode helper fallback loading

2017-01-13T01:56:54+00:00

[ Upstream commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 ]

When you use the firmware usermode helper fallback with a timeout value set to a
value greater than INT_MAX (2147483647) a cast overflow issue causes the
timeout value to go negative and breaks all usermode helper loading. This
regression was introduced through commit 68ff2a00dbf5 ("firmware_loader:
handle timeout via wait_for_completion_interruptible_timeout()") on kernel
v4.0.

The firmware_class drivers relies on the firmware usermode helper
fallback as a mechanism to look for firmware if the direct filesystem
search failed only if:

  a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):

  Then all of these callers will rely on the fallback mechanism in case
  the firmware is not found through an initial direct filesystem lookup:

  o request_firmware()
  o request_firmware_into_buf()
  o request_firmware_nowait()

  b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):

  Then only callers using request_firmware_nowait() with the second
  argument set to false, this explicitly is requesting the UMH firmware
  fallback to be relied on in case the first filesystem lookup fails.

  Using Coccinelle SmPL grammar we have identified only two drivers
  explicitly requesting the UMH firmware fallback mechanism:

  - drivers/firmware/dell_rbu.c
  - drivers/leds/leds-lp55xx-common.c

Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
biggest impact of this regression are users of the dell_rbu and
leds-lp55xx-common device driver which required the UMH to find their
respective needed firmwares.

The default timeout for the UMH is set to 60 seconds always, as of
commit 68ff2a00dbf5 ("firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()") the timeout was bumped
to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
value was also used if the timeout was configured by a user to 0.

The following works:

echo 2147483647 > /sys/class/firmware/timeout

But both of the following set the timeout to MAX_JIFFY_OFFSET even if
we display 0 back to userspace:

echo 2147483648 > /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

echo 0> /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
another cast with simple_strtol().

This fixes the secondary cast (the first one is simple_strtol() but its an
issue only by forcing an implicit limit) by re-using the timeout variable and
only setting retval in appropriate cases.

Lastly worth noting systemd had ripped out the UMH firmware fallback
mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
("udev: remove userspace firmware loading support"), so as of systemd v217.

Signed-off-by: Yves-Alexis Perez 
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez 
Cc: Ming Lei 
Cc: Bjorn Andersson 
Cc: Greg Kroah-Hartman 
Cc: stable@vger.kernel.org
Acked-by: Luis R. Rodriguez 
Reviewed-by: Bjorn Andersson 
[mcgrof@kernel.org: gave commit log a whole lot of love]
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Sasha Levin

base: make module_create_drivers_dir race-free

2016-07-11T00:19:58+00:00

[ Upstream commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 ]

Modules which register drivers via standard path (driver_register) in
parallel can cause a warning:
WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
sysfs: cannot create duplicate filename '/module/saa7146/drivers'
Modules linked in: hexium_gemini(+) mxb(+) ...
...
Call Trace:
...
 [] sysfs_warn_dup+0x62/0x80
 [] sysfs_create_dir_ns+0x77/0x90
 [] kobject_add_internal+0xb4/0x340
 [] kobject_add+0x68/0xb0
 [] kobject_create_and_add+0x31/0x70
 [] module_add_driver+0xc3/0xd0
 [] bus_add_driver+0x154/0x280
 [] driver_register+0x60/0xe0
 [] __pci_register_driver+0x60/0x70
 [] saa7146_register_extension+0x64/0x90 [saa7146]
 [] hexium_init_module+0x11/0x1000 [hexium_gemini]
...

As can be (mostly) seen, driver_register causes this call sequence:
  -> bus_add_driver
    -> module_add_driver
      -> module_create_drivers_dir
The last one creates "drivers" directory in /sys/module/<...>. When
this is done in parallel, the directory is attempted to be created
twice at the same time.

This can be easily reproduced by loading mxb and hexium_gemini in
parallel:
while :; do
  modprobe mxb &
  modprobe hexium_gemini
  wait
  rmmod mxb hexium_gemini saa7146_vv saa7146
done

saa7146 calls pci_register_driver for both mxb and hexium_gemini,
which means /sys/module/saa7146/drivers is to be created for both of
them.

Fix this by a new mutex in module_create_drivers_dir which makes the
test-and-create "drivers" dir atomic.

I inverted the condition and removed 'return' to avoid multiple
unlocks or a goto.

Signed-off-by: Jiri Slaby 
Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed)
Cc: v2.6.21+ 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

PM / sleep: Handle failures in device_suspend_late() consistently

2016-06-06T23:12:32+00:00

[ Upstream commit 3a17fb329da68cb00558721aff876a80bba2fdb9 ]

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Tested-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
Cc: All applicable 
Signed-off-by: Sasha Levin

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-06-03T23:15:31+00:00

[ Upstream commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f ]

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the ->runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Cc: 3.15+  # 3.15+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case

2016-05-17T17:42:37+00:00

[ Upstream commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 ]

Specifically for the case of reads that use the Extended Register
Read Long command, a multi-byte read operation is broken up into
8-byte chunks.  However the call to spmi_ext_register_readl() is
incorrectly passing 'val_size', which if greater than 8 will
always fail.  The argument should instead be 'len'.

Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces")
Signed-off-by: Jack Pham 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

cpu/cacheinfo: Fix teardown path

2015-10-22T21:43:23+00:00

commit 2110d70c5e58326a10e93cfefdc0b3686e2ada12 upstream.

Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
box. A fragment of the splat was enough to pinpoint the issue:

  task: f58e0000 ti: f58e8000 task.ti: f58e800
  EIP: 0060:[] EFLAGS: 00010206 CPU: 0
  EIP is at free_cache_attributes+0x83/0xd0
  EAX: 00000001 EBX: f589d46c ECX: 00000090 EDX: 360c2000
  ESI: 00000000 EDI: c1724a80 EBP: f58e9ec0 ESP: f58e9ea0
   DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
  CR0: 8005003b CR2: 000000ac CR3: 01731000 CR4: 000006d0

cache_shared_cpu_map_setup() did check sibling CPUs cacheinfo descriptor
while the respective teardown path cache_shared_cpu_map_remove() didn't.
Fix that.

>From tglx's version: to be on the safe side, move the cacheinfo
descriptor check to free_cache_attributes(), thus cleaning up the
hotplug path a little and making this even more robust.

Reported-and-tested-by: Philip Müller 
Reviewed-by: Thomas Gleixner 
Acked-by: Sudeep Holla 
Cc: Andre Przywara 
Cc: Guenter Roeck 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
Cc: manjaro-dev@manjaro.org
Cc: Philip Müller 
Link: https://lkml.kernel.org/r/55B47BB8.6080202@manjaro.org
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

regmap: debugfs: Don't bother actually printing when calculating max length

2015-10-22T21:43:22+00:00

commit 176fc2d5770a0990eebff903ba680d2edd32e718 upstream.

The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.

Reported-by: Rasmus Villemoes 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: debugfs: Ensure we don't underflow when printing access masks

2015-10-22T21:43:22+00:00

commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 upstream.

If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.

Reported-by: Rasmus Villemoes 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

device property: fix potential NULL pointer dereference

2015-10-22T21:43:22+00:00

commit ecc87eed7beeb50c0be0b73322d62135277ea2b0 upstream.

In device_add_property_set() we check pset parameter for a NULL, but few lines
later we do a pointer arithmetic without check that will crash kernel in the
set_secondary_fwnode().

Here we check if pset parameter is NULL and return immediately.

Fixes: 16ba08d5c9ec (device property: Introduce firmware node type for platform data)
Signed-off-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

mm: check if section present during memory block registering

2015-09-29T17:26:06+00:00

commit 04697858d89e4bf2650364f8d6956e2554e8ef88 upstream.

Tony Luck found on his setup, if memory block size 512M will cause crash
during booting.

  BUG: unable to handle kernel paging request at ffffea0074000020
  IP: get_nid_for_pfn+0x17/0x40
  PGD 128ffcb067 PUD 128ffc9067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
  ...
  Call Trace:
     ? register_mem_sect_under_node+0x66/0xe0
     register_one_node+0x17b/0x240
     ? pci_iommu_alloc+0x6e/0x6e
     topology_init+0x3c/0x95
     do_one_initcall+0xcd/0x1f0

The system has non continuous RAM address:
 BIOS-e820: [mem 0x0000001300000000-0x0000001cffffffff] usable
 BIOS-e820: [mem 0x0000001d70000000-0x0000001ec7ffefff] usable
 BIOS-e820: [mem 0x0000001f00000000-0x0000002bffffffff] usable
 BIOS-e820: [mem 0x0000002c18000000-0x0000002d6fffefff] usable
 BIOS-e820: [mem 0x0000002e00000000-0x00000039ffffffff] usable

So there are start sections in memory block not present.  For example:

    memory block : [0x2c18000000, 0x2c20000000) 512M

first three sections are not present.

The current register_mem_sect_under_node() assume first section is
present, but memory block section number range [start_section_nr,
end_section_nr] would include not present section.

For arch that support vmemmap, we don't setup memmap for struct page
area within not present sections area.

So skip the pfn range that belong to absent section.

[akpm@linux-foundation.org: simplification]
[rientjes@google.com: more simplification]
Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large memory x86-64 systems")
Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
Signed-off-by: Yinghai Lu 
Signed-off-by: David Rientjes 
Reported-by: Tony Luck 
Tested-by: Tony Luck 
Cc: Greg KH 
Cc: Ingo Molnar 
Tested-by: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman