linux-stable.git/drivers, branch v3.16.82

mmc: sdhci-s3c: solve problem with sleeping in atomic context

2020-02-11T20:03:57+00:00

commit 017210d1c0dc2e2d3b142985cb31d90b98dc0f0f upstream.

This change addresses following problem:

[    2.560726] ------------[ cut here ]------------
[    2.565341] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2744 lockdep_trace_alloc+0xec/0x118()
[    2.574439] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    2.579821] Modules linked in:
[    2.583038] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W      3.18.0-next-20141216-00002-g4ff197fc1902-dirty #1318
[    2.593796] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    2.599892] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[    2.607612] [] (show_stack) from [] (dump_stack+0x70/0xbc)
[    2.614822] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
[    2.622885] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40)
[    2.631569] [] (warn_slowpath_fmt) from [] (lockdep_trace_alloc+0xec/0x118)
[    2.640246] [] (lockdep_trace_alloc) from [] (__kmalloc+0x3c/0x1cc)
[    2.648240] [] (__kmalloc) from [] (clk_fetch_parent_index+0xb8/0xd4)
[    2.656390] [] (clk_fetch_parent_index) from [] (clk_calc_new_rates+0xe0/0x1fc)
[    2.665415] [] (clk_calc_new_rates) from [] (clk_calc_new_rates+0x1b4/0x1fc)
[    2.674181] [] (clk_calc_new_rates) from [] (clk_set_rate+0x50/0xc8)
[    2.682265] [] (clk_set_rate) from [] (sdhci_cmu_set_clock+0x68/0x16c)
[    2.690503] [] (sdhci_cmu_set_clock) from [] (sdhci_do_set_ios+0xf0/0x64c)
[    2.699095] [] (sdhci_do_set_ios) from [] (sdhci_set_ios+0x20/0x2c)
[    2.707080] [] (sdhci_set_ios) from [] (mmc_power_up+0x118/0x1fc)
[    2.714889] [] (mmc_power_up) from [] (mmc_start_host+0x44/0x6c)
[    2.722615] [] (mmc_start_host) from [] (mmc_add_host+0x58/0x7c)
[    2.730341] [] (mmc_add_host) from [] (sdhci_add_host+0x968/0xd94)
[    2.738240] [] (sdhci_add_host) from [] (sdhci_s3c_probe+0x354/0x52c)
[    2.746406] [] (sdhci_s3c_probe) from [] (platform_drv_probe+0x48/0xa4)
[    2.754733] [] (platform_drv_probe) from [] (driver_probe_device+0x13c/0x37c)
[    2.763585] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98)
[    2.772003] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[    2.780163] [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200)
[    2.788322] [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[    2.796308] [] (driver_register) from [] (do_one_initcall+0xac/0x1f0)
[    2.804473] [] (do_one_initcall) from [] (kernel_init_freeable+0x10c/0x1d8)
[    2.813153] [] (kernel_init_freeable) from [] (kernel_init+0x28/0x108)
[    2.821398] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
[    2.828939] ---[ end trace 03cc00e539849d1f ]---

clk_set_rate() tries to take clk's prepare_lock mutex while being in atomic
context entered in sdhci_do_set_ios().

The solution is inspired by similar situation in sdhci_set_power() also called
from sdhci_do_set_ios():

                spin_unlock_irq(&host->lock);
                mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
                spin_lock_irq(&host->lock);

Note that since sdhci_s3c_set_clock() sets SDHCI_CLOCK_CARD_EN, proposed change
first resets this bit. It is reset anyway (by setting SDHCI_CLOCK_INT_EN bit
only) after call to clk_set_rate() in order to wait for the clock to stabilize
and is set again as soon as the clock becomes stable.

Signed-off-by: Paul Osmialowski 
Tested-by: Jaehoon Chung 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: sdhci-s3c: Check if clk_set_rate() succeeds

2020-02-11T20:03:57+00:00

commit cd0cfdd2485e6252b3c69284bf09d06c4d303116 upstream.

It is possible that we may fail to set the clock rate, if we do so then
log the failure and don't bother reprogramming the IP.

Signed-off-by: Mark Brown 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

xen/blkback: Avoid unmapping unmapped grant pages

2020-02-11T20:03:54+00:00

commit f9bd84a8a845d82f9b5a081a7ae68c98a11d2e84 upstream.

For each I/O request, blkback first maps the foreign pages for the
request to its local pages.  If an allocation of a local page for the
mapping fails, it should unmap every mapping already made for the
request.

However, blkback's handling mechanism for the allocation failure does
not mark the remaining foreign pages as unmapped.  Therefore, the unmap
function merely tries to unmap every valid grant page for the request,
including the pages not mapped due to the allocation failure.  On a
system that fails the allocation frequently, this problem leads to
following kernel crash.

  [  372.012538] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
  [  372.012546] IP: [] gnttab_unmap_refs.part.7+0x1c/0x40
  [  372.012557] PGD 16f3e9067 PUD 16426e067 PMD 0
  [  372.012562] Oops: 0002 [#1] SMP
  [  372.012566] Modules linked in: act_police sch_ingress cls_u32
  ...
  [  372.012746] Call Trace:
  [  372.012752]  [] gnttab_unmap_refs+0x34/0x40
  [  372.012759]  [] xen_blkbk_unmap+0x83/0x150 [xen_blkback]
  ...
  [  372.012802]  [] dispatch_rw_block_io+0x970/0x980 [xen_blkback]
  ...
  Decompressing Linux... Parsing ELF... done.
  Booting the kernel.
  [    0.000000] Initializing cgroup subsys cpuset

This commit fixes this problem by marking the grant pages of the given
request that didn't mapped due to the allocation failure as invalid.

Fixes: c6cc142dac52 ("xen-blkback: use balloon pages for all mappings")

Reviewed-by: David Woodhouse 
Reviewed-by: Maximilian Heyne 
Reviewed-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Signed-off-by: SeongJae Park 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

drm/radeon: fix r1xx/r2xx register checker for POT textures

2020-02-11T20:03:54+00:00

commit 008037d4d972c9c47b273e40e52ae34f9d9e33e7 upstream.

Shift and mask were reversed.  Noticed by chance.

Tested-by: Meelis Roos 
Reviewed-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

ACPI: bus: Fix NULL pointer check in acpi_bus_get_private_data()

2020-02-11T20:03:52+00:00

commit 627ead724eff33673597216f5020b72118827de4 upstream.

kmemleak reported backtrace:
    [] kmem_cache_alloc_trace+0x128/0x260
    [<6677f215>] i2c_acpi_install_space_handler+0x4b/0xe0
    [<1180f4fc>] i2c_register_adapter+0x186/0x400
    [<6083baf7>] i2c_add_adapter+0x4e/0x70
    [] intel_gmbus_setup+0x1a2/0x2c0 [i915]
    [<84cb69ae>] i915_driver_probe+0x8d8/0x13a0 [i915]
    [<81911d4b>] i915_pci_probe+0x48/0x160 [i915]
    [<4b159af1>] pci_device_probe+0xdc/0x160
    [] really_probe+0x1ee/0x450
    [] driver_probe_device+0x142/0x1b0
    [] device_driver_attach+0x49/0x50
    [] __driver_attach+0xc9/0x150
    [] bus_for_each_dev+0x56/0xa0
    [<80089bba>] driver_attach+0x19/0x20
    [] bus_add_driver+0x177/0x220
    [<7b29d8c7>] driver_register+0x56/0xf0

In i2c_acpi_remove_space_handler(), a leak occurs whenever the
"data" parameter is initialized to 0 before being passed to
acpi_bus_get_private_data().

This is because the NULL pointer check in acpi_bus_get_private_data()
(condition->if(!*data)) returns EINVAL and, in consequence, memory is
never freed in i2c_acpi_remove_space_handler().

Fix the NULL pointer check in acpi_bus_get_private_data() to follow
the analogous check in acpi_get_data_full().

Signed-off-by: Vamshi K Sthambamkadi 
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI: OSL: only free map once in osl.c

2020-02-11T20:03:51+00:00

commit 833a426cc471b6088011b3d67f1dc4e147614647 upstream.

acpi_os_map_cleanup checks map->refcount outside of acpi_ioremap_lock
before freeing the map. This creates a race condition the can result
in the map being freed more than once.
A panic can be caused by running

for ((i=0; i<10; i++))
do
        for ((j=0; j<100000; j++))
        do
                cat /sys/firmware/acpi/tables/data/BERT >/dev/null
        done &
done

This patch makes sure that only the process that drops the reference
to 0 does the freeing.

Fixes: b7c1fadd6c2e ("ACPI: Do not use krefs under a mutex in osl.c")
Signed-off-by: Francesco Ruggeri 
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI / osl: speedup grace period in acpi_os_map_cleanup

2020-02-11T20:03:51+00:00

commit 74b51ee152b6d99e61ba329799a039453fb9438f upstream.

ACPI maintains cache of ioremap regions to speed up operations and
access to them from irq context where ioremap() calls aren't allowed.
This code abuses synchronize_rcu() on unmap path for synchronization
with fast-path in acpi_os_read/write_memory which uses this cache.

Since v3.10 CPUs are allowed to enter idle state even if they have RCU
callbacks queued, see commit c0f4dfd4f90f1667d234d21f15153ea09a2eaa66
("rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks").
That change caused problems with nvidia proprietary driver which calls
acpi_os_map/unmap_generic_address several times during initialization.
Each unmap calls synchronize_rcu and adds significant delay. Totally
initialization is slowed for a couple of seconds and that is enough to
trigger timeout in hardware, gpu decides to "fell off the bus". Widely
spread workaround is reducing "rcu_idle_gp_delay" from 4 to 1 jiffy.

This patch replaces synchronize_rcu() with synchronize_rcu_expedited()
which is much faster.

Link: https://devtalk.nvidia.com/default/topic/567297/linux/linux-3-10-driver-crash/
Signed-off-by: Konstantin Khlebnikov 
Reported-and-tested-by: Alexander Monakov 
Reviewed-by: Paul E. McKenney 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PCI/MSI: Fix incorrect MSI-X masking on resume

2020-02-11T20:03:50+00:00

commit e045fa29e89383c717e308609edd19d2fd29e1be upstream.

When a driver enables MSI-X, msix_program_entries() reads the MSI-X Vector
Control register for each vector and saves it in desc->masked.  Each
register is 32 bits and bit 0 is the actual Mask bit.

When we restored these registers during resume, we previously set the Mask
bit if *any* bit in desc->masked was set instead of when the Mask bit
itself was set:

  pci_restore_state
    pci_restore_msi_state
      __pci_restore_msix_state
        for_each_pci_msi_entry
          msix_mask_irq(entry, entry->masked)   <-- entire u32 word
            __pci_msix_desc_mask_irq(desc, flag)
              mask_bits = desc->masked & ~PCI_MSIX_ENTRY_CTRL_MASKBIT
              if (flag)       <-- testing entire u32, not just bit 0
                mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT
              writel(mask_bits, desc_addr + PCI_MSIX_ENTRY_VECTOR_CTRL)

This means that after resume, MSI-X vectors were masked when they shouldn't
be, which leads to timeouts like this:

  nvme nvme0: I/O 978 QID 3 timeout, completion polled

On resume, set the Mask bit only when the saved Mask bit from suspend was
set.

This should remove the need for 19ea025e1d28 ("nvme: Add quirk for Kingston
NVME SSD running FW E8FK11.T").

[bhelgaas: commit log, move fix to __pci_msix_desc_mask_irq()]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Link: https://lore.kernel.org/r/20191008034238.2503-1-jian-hong@endlessm.com
Fixes: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

macvlan: schedule bc_work even if error

2020-02-11T20:03:50+00:00

commit 1d7ea55668878bb350979c377fc72509dd6f5b21 upstream.

While enqueueing a broadcast skb to port->bc_queue, schedule_work()
is called to add port->bc_work, which processes the skbs in
bc_queue, to "events" work queue. If port->bc_queue is full, the
skb will be discarded and schedule_work(&port->bc_work) won't be
called. However, if port->bc_queue is full and port->bc_work is not
running or pending, port->bc_queue will keep full and schedule_work()
won't be called any more, and all broadcast skbs to macvlan will be
discarded. This case can happen:

macvlan_process_broadcast() is the pending function of port->bc_work,
it moves all the skbs in port->bc_queue to the queue "list", and
processes the skbs in "list". During this, new skbs will keep being
added to port->bc_queue in macvlan_broadcast_enqueue(), and
port->bc_queue may already full when macvlan_process_broadcast()
return. This may happen, especially when there are a lot of real-time
threads and the process is preempted.

Fix this by calling schedule_work(&port->bc_work) even if
port->bc_work is full in macvlan_broadcast_enqueue().

Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
Signed-off-by: Menglong Dong 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

platform/x86: hp-wmi: Fix ACPI errors caused by passing 0 as input size

2020-02-11T20:03:49+00:00

commit f3e4f3fc8ee9729c4b1b27a478c68b713df53c0c upstream.

The AML code implementing the WMI methods creates a variable length
field to hold the input data we pass like this:

        CreateDWordField (Arg1, 0x0C, DSZI)
        Local5 = DSZI /* \HWMC.DSZI */
        CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN)

If we pass 0 as bios_args.datasize argument then (Local5 * 0x08)
is 0 which results in these errors:

[   71.973305] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20190816/dsopcode-133)
[   71.973332] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529)
[   71.973413] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529)

And in our HPWMI_WIRELESS2_QUERY calls always failing. for read commands
like HPWMI_WIRELESS2_QUERY the DSZI value is not used / checked, except for
read commands where extra input is needed to specify exactly what to read.

So for HPWMI_WIRELESS2_QUERY we can safely pass the size of the expected
output as insize to hp_wmi_perform_query(), as we are already doing for all
other HPWMI_READ commands we send. Doing so fixes these errors.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
Signed-off-by: Hans de Goede 
Signed-off-by: Andy Shevchenko 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings