linux.git/drivers/base, branch v4.1.29

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

drivercore: Fix unregistration path of platform devices

2015-09-21T17:05:44+00:00

commit 7f5dcaf1fdf289767a126a0a5cc3ef39b5254b06 upstream.

The unregister path of platform_device is broken. On registration, it
will register all resources with either a parent already set, or
type==IORESOURCE_{IO,MEM}. However, on unregister it will release
everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
are also cases where resources don't get registered in the first place,
like with devices created by of_platform_populate()*.

Fix the unregister path to be symmetrical with the register path by
checking the parent pointer instead of the type field to decide which
resources to unregister. This is safe because the upshot of the
registration path algorithm is that registered resources have a parent
pointer, and non-registered resources do not.

* It can be argued that of_platform_populate() should be registering
  it's resources, and they argument has some merit. However, there are
  quite a few platforms that end up broken if we try to do that due to
  overlapping resources in the device tree. Until that is fixed, we need
  to solve the immediate problem.

Cc: Pantelis Antoniou 
Cc: Wolfram Sang 
Cc: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Ricardo Ribalda Delgado 
Signed-off-by: Grant Likely 
Tested-by: Ricardo Ribalda Delgado 
Tested-by: Wolfram Sang 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman