22 Jul, 2015

40 commits

  • commit 0867a57c4f80a566dda1bac975b42fcd857cb489 upstream.

    Since commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on
    local node"), we handle THP allocations on page fault in a special way -
    for non-interleave memory policies, the allocation is only attempted on
    the node local to the current CPU, if the policy's nodemask allows the
    node.

    This is motivated by the assumption that THP benefits cannot offset the
    cost of remote accesses, so it's better to fallback to base pages on the
    local node (which might still be available, while huge pages are not due
    to fragmentation) than to allocate huge pages on a remote node.

    The nodemask check prevents us from violating e.g. MPOL_BIND policies
    where the local node is not among the allowed nodes. However, the
    current implementation can still give surprising results for the
    MPOL_PREFERRED policy when the preferred node is different than the
    current CPU's local node.

    In such case we should honor the preferred node and not use the local
    node, which is what this patch does. If hugepage allocation on the
    preferred node fails, we fall back to base pages and don't try other
    nodes, with the same motivation as is done for the local node hugepage
    allocations. The patch also moves the MPOL_INTERLEAVE check around to
    simplify the hugepage specific test.

    The difference can be demonstrated using in-tree transhuge-stress test
    on the following 2-node machine where half memory on one node was
    occupied to show the difference.

    > numactl --hardware
    available: 2 nodes (0-1)
    node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 24 25 26 27 28 29 30 31 32 33 34 35
    node 0 size: 7878 MB
    node 0 free: 3623 MB
    node 1 cpus: 12 13 14 15 16 17 18 19 20 21 22 23 36 37 38 39 40 41 42 43 44 45 46 47
    node 1 size: 8045 MB
    node 1 free: 7818 MB
    node distances:
    node 0 1
    0: 10 21
    1: 21 10

    Before the patch:
    > numactl -p0 -C0 ./transhuge-stress
    transhuge-stress: 2.197 s/loop, 0.276 ms/page, 7249.168 MiB/s 7962 succeed, 0 failed, 1786 different pages

    > numactl -p0 -C12 ./transhuge-stress
    transhuge-stress: 2.962 s/loop, 0.372 ms/page, 5376.172 MiB/s 7962 succeed, 0 failed, 3873 different pages

    Number of successful THP allocations corresponds to free memory on node 0 in
    the first case and node 1 in the second case, i.e. -p parameter is ignored and
    cpu binding "wins".

    After the patch:
    > numactl -p0 -C0 ./transhuge-stress
    transhuge-stress: 2.183 s/loop, 0.274 ms/page, 7295.516 MiB/s 7962 succeed, 0 failed, 1760 different pages

    > numactl -p0 -C12 ./transhuge-stress
    transhuge-stress: 2.878 s/loop, 0.361 ms/page, 5533.638 MiB/s 7962 succeed, 0 failed, 1750 different pages

    > numactl -p1 -C0 ./transhuge-stress
    transhuge-stress: 4.628 s/loop, 0.581 ms/page, 3440.893 MiB/s 7962 succeed, 0 failed, 3918 different pages

    The -p parameter is respected regardless of cpu binding.

    > numactl -C0 ./transhuge-stress
    transhuge-stress: 2.202 s/loop, 0.277 ms/page, 7230.003 MiB/s 7962 succeed, 0 failed, 1750 different pages

    > numactl -C12 ./transhuge-stress
    transhuge-stress: 3.020 s/loop, 0.379 ms/page, 5273.324 MiB/s 7962 succeed, 0 failed, 3916 different pages

    Without -p parameter, hugepage restriction to CPU-local node works as before.

    Fixes: 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node")
    Signed-off-by: Vlastimil Babka
    Cc: Aneesh Kumar K.V
    Acked-by: David Rientjes
    Cc: Kirill A. Shutemov
    Cc: Andrea Arcangeli
    Cc: Michal Hocko
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Vlastimil Babka
     
  • commit 8a8c35fadfaf55629a37ef1a8ead1b8fb32581d2 upstream.

    Beginning at commit d52d3997f843 ("ipv6: Create percpu rt6_info"), the
    following INFO splat is logged:

    ===============================
    [ INFO: suspicious RCU usage. ]
    4.1.0-rc7-next-20150612 #1 Not tainted
    -------------------------------
    kernel/sched/core.c:7318 Illegal context switch in RCU-bh read-side critical section!
    other info that might help us debug this:
    rcu_scheduler_active = 1, debug_locks = 0
    3 locks held by systemd/1:
    #0: (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1f/0x40
    #1: (rcu_read_lock_bh){......}, at: [] ipv6_add_addr+0x62/0x540
    #2: (addrconf_hash_lock){+...+.}, at: [] ipv6_add_addr+0x184/0x540
    stack backtrace:
    CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612 #1
    Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014
    Call Trace:
    dump_stack+0x4c/0x6e
    lockdep_rcu_suspicious+0xe7/0x120
    ___might_sleep+0x1d5/0x1f0
    __might_sleep+0x4d/0x90
    kmem_cache_alloc+0x47/0x250
    create_object+0x39/0x2e0
    kmemleak_alloc_percpu+0x61/0xe0
    pcpu_alloc+0x370/0x630

    Additional backtrace lines are truncated. In addition, the above splat
    is followed by several "BUG: sleeping function called from invalid
    context at mm/slub.c:1268" outputs. As suggested by Martin KaFai Lau,
    these are the clue to the fix. Routine kmemleak_alloc_percpu() always
    uses GFP_KERNEL for its allocations, whereas it should follow the gfp
    from its callers.

    Reviewed-by: Catalin Marinas
    Reviewed-by: Kamalesh Babulal
    Acked-by: Martin KaFai Lau
    Signed-off-by: Larry Finger
    Cc: Martin KaFai Lau
    Cc: Catalin Marinas
    Cc: Tejun Heo
    Cc: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Larry Finger
     
  • commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream.

    The kmemleak scanning thread can run for minutes. Callbacks like
    kmemleak_free() are allowed during this time, the race being taken care
    of by the object->lock spinlock. Such lock also prevents a memory block
    from being freed or unmapped while it is being scanned by blocking the
    kmemleak_free() -> ... -> __delete_object() function until the lock is
    released in scan_object().

    When a kmemleak error occurs (e.g. it fails to allocate its metadata),
    kmemleak_enabled is set and __delete_object() is no longer called on
    freed objects. If kmemleak_scan is running at the same time,
    kmemleak_free() no longer waits for the object scanning to complete,
    allowing the corresponding memory block to be freed or unmapped (in the
    case of vfree()). This leads to kmemleak_scan potentially triggering a
    page fault.

    This patch separates the kmemleak_free() enabling/disabling from the
    overall kmemleak_enabled nob so that we can defer the disabling of the
    object freeing tracking until the scanning thread completed. The
    kmemleak_free_part() is deliberately ignored by this patch since this is
    only called during boot before the scanning thread started.

    Signed-off-by: Catalin Marinas
    Reported-by: Vignesh Radhakrishnan
    Tested-by: Vignesh Radhakrishnan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Catalin Marinas
     
  • commit 6f1a6ae87c0c60d7c462ef8fd071f291aa7a9abb upstream.

    When building the kernel with a bare-metal (ELF) toolchain, the -shared
    option may not be passed down to collect2, resulting in silent corruption
    of the vDSO image (in particular, the DYNAMIC section is omitted).

    The effect of this corruption is that the dynamic linker fails to find
    the vDSO symbols and libc is instead used for the syscalls that we
    intended to optimise (e.g. gettimeofday). Functionally, there is no
    issue as the sigreturn trampoline is still intact and located by the
    kernel.

    This patch fixes the problem by explicitly passing -shared to the linker
    when building the vDSO.

    Reported-by: Szabolcs Nagy
    Reported-by: James Greenlaigh
    Signed-off-by: Will Deacon
    Signed-off-by: Catalin Marinas
    Signed-off-by: Greg Kroah-Hartman

    Will Deacon
     
  • commit b9bcc919931611498e856eae9bf66337330d04cc upstream.

    The memmap freeing code in free_unused_memmap() computes the end of
    each memblock by adding the memblock size onto the base. However,
    if SPARSEMEM is enabled then the value (start) used for the base
    may already have been rounded downwards to work out which memmap
    entries to free after the previous memblock.

    This may cause memmap entries that are in use to get freed.

    In general, you're not likely to hit this problem unless there
    are at least 2 memblocks and one of them is not aligned to a
    sparsemem section boundary. Note that carve-outs can increase
    the number of memblocks by splitting the regions listed in the
    device tree.

    This problem doesn't occur with SPARSEMEM_VMEMMAP, because the
    vmemmap code deals with freeing the unused regions of the memmap
    instead of requiring the arch code to do it.

    This patch gets the memblock base out of the memblock directly when
    computing the block end address to ensure the correct value is used.

    Signed-off-by: Dave Martin
    Signed-off-by: Catalin Marinas
    Signed-off-by: Greg Kroah-Hartman

    Dave P Martin
     
  • commit 46b0567c851cf85d6ba6f23eef385ec9111d09bc upstream.

    Commit 6c81fe7925cc4c42 ("arm64: enable context tracking") did not
    update el0_sp_pc to use ct_user_exit, but this appears to have been
    unintentional. In commit 6ab6463aeb5fbc75 ("arm64: adjust el0_sync so
    that a function can be called") we made x0 available, and in the return
    to userspace we call ct_user_enter in the kernel_exit macro.

    Due to this, we currently don't correctly inform RCU of the user->kernel
    transition, and may erroneously account for time spent in the kernel as
    if we were in an extended quiescent state when CONFIG_CONTEXT_TRACKING
    is enabled.

    As we do record the kernel->user transition, a userspace application
    making accesses from an unaligned stack pointer can demonstrate the
    imbalance, provoking the following warning:

    ------------[ cut here ]------------
    WARNING: CPU: 2 PID: 3660 at kernel/context_tracking.c:75 context_tracking_enter+0xd8/0xe4()
    Modules linked in:
    CPU: 2 PID: 3660 Comm: a.out Not tainted 4.1.0-rc7+ #8
    Hardware name: ARM Juno development board (r0) (DT)
    Call trace:
    [] dump_backtrace+0x0/0x124
    [] show_stack+0x10/0x1c
    [] dump_stack+0x84/0xc8
    [] warn_slowpath_common+0x98/0xd0
    [] warn_slowpath_null+0x14/0x20
    [] context_tracking_enter+0xd4/0xe4
    [] preempt_schedule_irq+0xd4/0x114
    [] el1_preempt+0x4/0x28
    [] exit_files+0x38/0x4c
    [] do_exit+0x430/0x978
    [] do_group_exit+0x40/0xd4
    [] get_signal+0x23c/0x4f4
    [] do_signal+0x1ac/0x518
    [] do_notify_resume+0x5c/0x68
    ---[ end trace 963c192600337066 ]---

    This patch adds the missing ct_user_exit to the el0_sp_pc entry path,
    correcting the context tracking for this case.

    Signed-off-by: Mark Rutland
    Acked-by: Will Deacon
    Fixes: 6c81fe7925cc ("arm64: enable context tracking")
    Signed-off-by: Catalin Marinas
    Signed-off-by: Greg Kroah-Hartman

    Mark Rutland
     
  • commit 565630d503ef24e44c252bed55571b3a0d68455f upstream.

    After secondary CPU boot or hotplug, the active_mm of the idle thread is
    &init_mm. The init_mm.pgd (swapper_pg_dir) is only meant for TTBR1_EL1
    and must not be set in TTBR0_EL1. Since when active_mm == &init_mm the
    TTBR0_EL1 is already set to the reserved value, there is no need to
    perform any context reset.

    Signed-off-by: Catalin Marinas
    Signed-off-by: Greg Kroah-Hartman

    Catalin Marinas
     
  • commit fe292283c23329218e384bffc6cb4bfa3fd92277 upstream.

    HW has to be in known state before the initialisation
    sequence is started. The polling step for settling aliveness
    was set to 200ms while in practise this can be done in up to 30msecs.

    Signed-off-by: Tomas Winkler
    Signed-off-by: Barak Yoresh
    Signed-off-by: Greg Kroah-Hartman

    Tomas Winkler
     
  • commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 upstream.

    Fix the hbm power gating state machine so it will wait till it receives
    confirmation interrupt for the PG_ISOLATION_EXIT message.

    In process of the suspend flow the devices first have to exit from the
    power gating state (runtime pm resume).
    If we do not handle the confirmation interrupt after sending
    PG_ISOLATION_EXIT message, we may receive it already after the suspend
    flow has changed the device state and interrupt will be interpreted as a
    spurious event, consequently link reset will be invoked which will
    prevent the device from completing the suspend flow

    kernel: [6603] mei_reset:136: mei_me 0000:00:16.0: powering down: end of reset
    kernel: [476] mei_me_irq_thread_handler:643: mei_me 0000:00:16.0: function called after ISR to handle the interrupt processing.
    kernel: mei_me 0000:00:16.0: FW not ready: resetting

    Cc: Gabriele Mazzotta
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=86241
    Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770397
    Tested-by: Gabriele Mazzotta
    Signed-off-by: Alexander Usyskin
    Signed-off-by: Tomas Winkler
    Signed-off-by: Greg Kroah-Hartman

    Alexander Usyskin
     
  • commit 7f1a57fdd6cb6e7be2ed31878a34655df38e1861 upstream.

    Don't call the power_supply_changed() from power_supply_register() when
    parent is still probing because it may lead to accessing parent too
    early.

    In bq27x00_battery this caused NULL pointer exception because uevent of
    power_supply_changed called back the the get_property() method provided
    by the driver. The get_property() method accessed pointer which should
    be returned by power_supply_register().

    Starting from bq27x00_battery_probe():
    di->bat = power_supply_register()
    power_supply_changed()
    kobject_uevent()
    power_supply_uevent()
    power_supply_show_property()
    power_supply_get_property()
    bq27x00_battery_get_property()
    dereference of di->bat which is NULL here

    The dereference of di->bat (value returned by power_supply_register())
    is the currently visible problem. However calling back the methods
    provided by driver before ending the probe may lead to accessing other
    driver-related data which is not yet initialized.

    The call to power_supply_changed() is postponed till probing ends -
    mutex of parent device is released.

    Reported-by: H. Nikolaus Schaller
    Signed-off-by: Krzysztof Kozlowski
    Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
    Tested-By: Dr. H. Nikolaus Schaller
    Signed-off-by: Sebastian Reichel
    Signed-off-by: Greg Kroah-Hartman

    Krzysztof Kozlowski
     
  • commit 8e59c7f23410d5ca6b350a178b861a3d68c49edf upstream.

    Power supply is often registered during probe of a driver. The
    power_supply_register() returns pointer to newly allocated structure as
    return value. However before returning the power_supply_register()
    calls back the get_property() method provided by the driver through
    uevent.

    In that time the driver probe is still in progress and driver did not
    assigned pointer to power supply to its local variables. This leads to
    NULL pointer dereference from get_property() function.
    Starting from bq27x00_battery_probe():
    di->bat = power_supply_register()
    device_add()
    kobject_uevent()
    power_supply_uevent()
    power_supply_show_property()
    power_supply_get_property()
    bq27x00_battery_get_property()
    dereference of (di->bat) which is NULL here

    The first uevent of power supply (the one coming from device creation)
    should not call back to the driver. To prevent that from happening,
    increment the atomic use counter at the end of power_supply_register().
    This means that power_supply_get_property() will return -ENODEV.

    IMPORTANT:
    The patch has impact on this first uevent sent from power supply because
    it will not contain properties from power supply.

    The uevent with properties will be sent later after indicating that
    power supply has changed. This also has a race now, but will be fixed in
    other patches.

    Reported-by: H. Nikolaus Schaller
    Signed-off-by: Krzysztof Kozlowski
    Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
    Tested-By: Dr. H. Nikolaus Schaller
    Signed-off-by: Sebastian Reichel
    Signed-off-by: Greg Kroah-Hartman

    Krzysztof Kozlowski
     
  • commit 7002f77541f877a5590615ceb3da32b114f14b62 upstream.

    static arc_pmu in the arch/arc/kernel/perf_event.c is not initialized as
    it's shadowed by a local variable of the same name in the
    arc_pmu_device_probe.

    Signed-off-by: Max Filippov
    Fixes: 03c94fcf954d "ARC: perf: make @arc_pmu static global"
    Signed-off-by: Vineet Gupta
    Signed-off-by: Greg Kroah-Hartman

    Max Filippov
     
  • commit d57f727264f1425a94689bafc7e99e502cb135b5 upstream.

    When auditing cmpxchg call sites, Chuck noted that gcc was optimizing
    away some of the desired LDs.

    | do {
    | new = old = *ipi_data_ptr;
    | new |= 1U << msg;
    | } while (cmpxchg(ipi_data_ptr, old, new) != old);

    was generating to below

    | 8015cef8: ld r2,[r4,0]
    Acked-by: Peter Zijlstra (Intel)
    Signed-off-by: Vineet Gupta
    Signed-off-by: Greg Kroah-Hartman

    Vineet Gupta
     
  • commit 2576c28e3f623ed401db7e6197241865328620ef upstream.

    - arch_spin_lock/unlock were lacking the ACQUIRE/RELEASE barriers
    Since ARCv2 only provides load/load, store/store and all/all, we need
    the full barrier

    - LLOCK/SCOND based atomics, bitops, cmpxchg, which return modified
    values were lacking the explicit smp barriers.

    - Non LLOCK/SCOND varaints don't need the explicit barriers since that
    is implicity provided by the spin locks used to implement the
    critical section (the spin lock barriers in turn are also fixed in
    this commit as explained above

    Cc: Paul E. McKenney
    Acked-by: Peter Zijlstra (Intel)
    Signed-off-by: Vineet Gupta
    Signed-off-by: Greg Kroah-Hartman

    Vineet Gupta
     
  • commit 60df4642a83546fa6ea8286f5094ce8c0906c3ec upstream.

    Make 3.81 doesn't have the 'undefine' command. Using undefine
    to clear LDFLAGS fails when make version 3.81 is used. Fix it
    to use override to clear LDFLAGS.

    Tested-by: Shuah Khan
    Cc: David Ahern
    Cc: Ingo Molnar
    Cc: Michael Ellerman
    Link: http://lkml.kernel.org/r/20150514151225.GH23588@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Shuah Khan
    Cc: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Arnaldo Carvalho de Melo
     
  • commit 61e2c70da9cfc79e8485eafa0f98b5919b04bbe1 upstream.

    This id has been seen in the DSDT of the Teclast X98 Air 3G tablet based
    on Intel Bay Trail.

    Signed-off-by: Antonio Ospite
    Cc: Bastien Nocera
    Reviewed-by: Daniel Baluta
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Antonio Ospite
     
  • commit 0f1b414d190724617eb1cdd615592fa8cd9d0b50 upstream.

    Commit b9a5e5e18fbf "ACPI / init: Fix the ordering of
    acpi_reserve_resources()" overlooked the fact that the memory
    and/or I/O regions reserved by acpi_reserve_resources() may
    conflict with those reserved by the PNP "system" driver.

    If that conflict actually takes place, it causes the reservations
    made by the "system" driver to fail while before commit b9a5e5e18fbf
    all reservations made by it and by acpi_reserve_resources() would be
    successful. In turn, that allows the resources that haven't been
    reserved by the "system" driver to be used by others (e.g. PCI) which
    sometimes leads to functional problems (up to and including boot
    failures).

    To fix that issue, introduce a common resource reservation routine,
    acpi_reserve_region(), to be used by both acpi_reserve_resources()
    and the "system" driver, that will track all resources reserved by
    it and avoid making conflicting requests.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
    Link: http://marc.info/?t=143389402600001&r=1&w=2
    Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
    Reported-by: Roland Dreier
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     
  • commit 3d56402d3fa8d10749eeb36293dd1992bd5ad0c3 upstream.

    Add missing invocation of pm_generic_complete() to
    acpi_subsys_complete() to allow ->complete callbacks provided
    by the drivers of devices using the ACPI PM domain to be executed
    during system resume.

    Fixes: f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend)
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     
  • commit b064a8fa77dfead647564c46ac8fc5b13bd1ab73 upstream.

    Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
    timekeeping_init()" moved the ACPI subsystem initialization,
    including the ACPI mode enabling, to an earlier point in the
    initialization sequence, to allow the timekeeping subsystem
    use ACPI early. Unfortunately, that resulted in boot regressions
    on some systems and the early ACPI initialization was moved toward
    its original position in the kernel initialization code by commit
    c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".

    However, that turns out to be insufficient, as boot is still broken
    on the Tyan S8812 mainboard.

    To fix that issue, split the ACPI early initialization code into
    two pieces so the majority of it still located in acpi_early_init()
    and the part switching over the platform into the ACPI mode goes into
    a new function, acpi_subsystem_init(), executed at the original early
    ACPI initialization spot.

    That fixes the Tyan S8812 boot problem, but still allows ACPI
    tables to be loaded earlier which is useful to the EFI code in
    efi_enter_virtual_mode().

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
    Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
    Reported-and-tested-by: Marius Tolzmann
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Toshi Kani
    Reviewed-by: Hanjun Guo
    Reviewed-by: Lee, Chun-Yi
    Signed-off-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     
  • commit 4275554dccdf0afac07b2b638ba7456095629558 upstream.

    Dell E7450 [0128:062e] needs the same quirk as other E7xx models.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100571
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 4df3fd1700abbb53bd874143dfd1f9ac9e7cbf4b upstream.

    Fujitsu Lifebook E780 sets the sequence number 0x0f to only only of
    the two headphones, thus the driver tries to assign another as the
    line-out, and this results in the inconsistent mapping between the
    created jack ctl and the actual I/O. Due to this, PulseAudio doesn't
    handle it properly and gets the silent output.

    The fix is to ignore the non-HP sequencer checks.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99681
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 7819717b11346b8a5420b223b46600e394049c66 upstream.

    Acer Aspire V5 with ALC282 codec needs the similar quirk like Dell
    laptops to support the headset mic. The headset mic pin is 0x19 and
    it's not exposed by BIOS, thus we need to fix the pincfg as well.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 831bfdf9520e389357cfeee42a6174a73ce7bdb7 upstream.

    Those FIXUPs were applied to the machines through pin quirks, but
    recently the PCI_QUIRK makes them can't apply to the machines.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99851
    Signed-off-by: Hui Wang
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Hui Wang
     
  • commit 735c75cf4d434862e38c01dcfb2ce8d2fcb9035f upstream.

    The widget power-save that was enabled in 4.1 kernel seems resulting
    in the silent output on VIA codecs by some reason. Some widgets get
    wrong power states.

    As a quick fix, turn this flag off while keeping power_down_unused
    flag. This will bring back to the state of 4.0.x.

    Fixes: 688b12cc3ca8 ('ALSA: hda - Use the new power control for VIA codecs')
    Reported-and-tested-by: Harald Dunkel
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 650474fb737c3e0ea0f6ab8e43c2cd161080ce5c upstream.

    Fixes audio problems on newer asics.

    Noticed by: Kelly Anderson
    Signed-off-by: Alex Deucher
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit ec56af67a10a0d82b79027878a81fce08d002d50 upstream.

    Thinkpad X250, when attached to a dock, has two headphone outs but
    no line out. Make sure we don't try to turn this into one headphone
    and one line out (since that disables the headphone amp on the dock).

    Alsa-info at http://www.alsa-project.org/db/?f=36f8764e1d782397928feec715d0ef90dfddd4c1

    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    David Henningsson
     
  • commit 60b93030b44a8c2cd015cebe5624fd7552ec67ec upstream.

    The pcm_class sysfs of each PCM substream gives only "none" since the
    recent code change to embed the struct device. Fix the code to point
    directly to the embedded device object properly.

    Fixes: ef46c7af93f9 ('ALSA: pcm: Embed struct device')
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.

    Disable write buffering on the Toshiba ToPIC95 if it is enabled by
    somebody (it is not supposed to be a power-on default according to
    the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
    will work under heavy load without locking up the whole system if
    this is left enabled. I tried about a dozen. It does not affect
    16-bit cards. This is similar to the O2 bugs in early controller
    revisions it seems.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961
    Signed-off-by: Ryan C. Underwood
    Signed-off-by: Dominik Brodowski
    Signed-off-by: Greg Kroah-Hartman

    Ryan Underwood
     
  • commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream.

    Increase the default init stage change timeout from 15 seconds to 30 seconds.
    This resolves issues we have seen with some adapters not transitioning
    to the first init stage within 15 seconds, which results in adapter
    initialization failures.

    Signed-off-by: Brian King
    Signed-off-by: James Bottomley
    Signed-off-by: Greg Kroah-Hartman

    Brian King
     
  • commit 6e91f8cb138625be96070b778d9ba71ce520ea7e upstream.

    If, at the time __rcu_process_callbacks() is invoked, there are callbacks
    in Tiny RCU's callback list, but none of them are ready to be invoked,
    the current list-management code will knit the non-ready callbacks out
    of the list. This can result in hangs and possibly worse. This commit
    therefore inserts a check for there being no callbacks that can be
    invoked immediately.

    This bug is unlikely to occur -- you have to get a new callback between
    the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to
    __rcu_process_callbacks(). It was detected by the addition of RCU-bh
    testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's
    mutation testing. Although this bug was made much more likely by
    915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this
    did not cause the bug, but rather made it much more probable. That
    said, it takes more than 40 hours of rcutorture testing, on average,
    for this bug to appear, so this fix cannot be considered an emergency.

    Signed-off-by: Paul E. McKenney
    Reviewed-by: Josh Triplett
    Signed-off-by: Greg Kroah-Hartman

    Paul E. McKenney
     
  • commit 501ef0f95a57e7c32138733c468394a52244c85b upstream.

    If an interrupt controller doesn't support wake-up configuration,
    irq_set_irq_wake() returns an error code. Then any subsequent call
    trying to deconfigure wake-up will cause an imbalance, and a warning
    will be printed:

    WARNING: CPU: 1 PID: 1341 at kernel/irq/manage.c:540 irq_set_irq_wake+0x9c/0xf8()
    Unbalanced IRQ 26 wake disable

    To fix this, refrain from any further parent interrupt controller
    (de)configuration if irq_set_irq_wake() failed.

    Alternative fixes would be:
    - calling "gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE)" from the
    platform code,
    - setting "gic_chip.flags = IRQCHIP_SKIP_SET_WAKE" in the GIC driver
    code,
    but these were withheld as the GIC hardware doesn't really support
    wake-up interrupts.

    Fixes: ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable when wake-up is enabled")
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Geert Uytterhoeven
     
  • commit 61e749d7e1627d375156553ea0ae83c4f6bb5a9b upstream.

    The CrystalCove GPIO irqchip doesn't have irq_set_wake callback defined
    so we should set IRQCHIP_SKIP_SET_WAKE for it or it would cause an irq
    desc's wake_depth unbalanced warning during system resume phase from the
    gpio_keys driver, which is the driver for the power button of the ASUS
    T100 laptop.

    Signed-off-by: Aaron Lu
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Aaron Lu
     
  • commit 8c6cf9cc829fcd0b179b59f7fe288941d0e31108 upstream.

    Ignore an existing mount if the locked readonly, nodev or atime
    attributes are less permissive than the desired attributes
    of the new mount.

    On success ensure the new mount locks all of the same readonly, nodev and
    atime attributes as the old mount.

    The nosuid and noexec attributes are not checked here as this change
    is destined for stable and enforcing those attributes causes a
    regression in lxc and libvirt-lxc where those applications will not
    start and there are no known executables on sysfs or proc and no known
    way to create exectuables without code modifications

    Fixes: e51db73532955 ("userns: Better restrictions on when proc and sysfs can be mounted")
    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit 1b852bceb0d111e510d1a15826ecc4a19358d512 upstream.

    Fresh mounts of proc and sysfs are a very special case that works very
    much like a bind mount. Unfortunately the current structure can not
    preserve the MNT_LOCK... mount flags. Therefore refactor the logic
    into a form that can be modified to preserve those lock bits.

    Add a new filesystem flag FS_USERNS_VISIBLE that requires some mount
    of the filesystem be fully visible in the current mount namespace,
    before the filesystem may be mounted.

    Move the logic for calling fs_fully_visible from proc and sysfs into
    fs/namespace.c where it has greater access to mount namespace state.

    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit 7236c85e1be51a9e25ba0f6e087a66ca89605a49 upstream.

    fs_fully_visible attempts to make fresh mounts of proc and sysfs give
    the mounter no more access to proc and sysfs than if they could have
    by creating a bind mount. One aspect of proc and sysfs that makes
    this particularly tricky is that there are other filesystems that
    typically mount on top of proc and sysfs. As those filesystems are
    mounted on empty directories in practice it is safe to ignore them.
    However testing to ensure filesystems are mounted on empty directories
    has not been something the in kernel data structures have supported so
    the current test for an empty directory which checks to see
    if nlink i_mode) && i_nlink
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit f9bb48825a6b5d02f4cabcc78967c75db903dcdc upstream.

    This allows for better documentation in the code and
    it allows for a simpler and fully correct version of
    fs_fully_visible to be written.

    The mount points converted and their filesystems are:
    /sys/hypervisor/s390/ s390_hypfs
    /sys/kernel/config/ configfs
    /sys/kernel/debug/ debugfs
    /sys/firmware/efi/efivars/ efivarfs
    /sys/fs/fuse/connections/ fusectl
    /sys/fs/pstore/ pstore
    /sys/kernel/tracing/ tracefs
    /sys/fs/cgroup/ cgroup
    /sys/kernel/security/ securityfs
    /sys/fs/selinux/ selinuxfs
    /sys/fs/smackfs/ smackfs

    Acked-by: Greg Kroah-Hartman
    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit 87d2846fcf88113fae2341da1ca9a71f0d916f2c upstream.

    Add two functions sysfs_create_mount_point and
    sysfs_remove_mount_point that hang a permanently empty directory off
    of a kobject or remove a permanently emptpy directory hanging from a
    kobject. Export these new functions so modular filesystems can use
    them.

    Acked-by: Greg Kroah-Hartman
    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit ea015218f2f7ace2dad9cedd21ed95bdba2886d7 upstream.

    Add a new function kernfs_create_empty_dir that can be used to create
    directory that can not be modified.

    Update the code to use make_empty_dir_inode when reporting a
    permanently empty directory to the vfs.

    Update the code to not allow adding to permanently empty directories.

    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit eb6d38d5427b3ad42f5268da0f1dd31bb0af1264 upstream.

    Add a new function proc_create_mount_point that when used to creates a
    directory that can not be added to.

    Add a new function is_empty_pde to test if a function is a mount
    point.

    Update the code to use make_empty_dir_inode when reporting
    a permanently empty directory to the vfs.

    Update the code to not allow adding to permanently empty directories.

    Update /proc/openprom and /proc/fs/nfsd to be permanently empty directories.

    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit f9bd6733d3f11e24f3949becf277507d422ee1eb upstream.

    Add a magic sysctl table sysctl_mount_point that when used to
    create a directory forces that directory to be permanently empty.

    Update the code to use make_empty_dir_inode when accessing permanently
    empty directories.

    Update the code to not allow adding to permanently empty directories.

    Update /proc/sys/fs/binfmt_misc to be a permanently empty directory.

    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman