15 Nov, 2014

40 commits

  • Greg Kroah-Hartman
     
  • commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream.

    Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far
    jumps") introduced a bug that caused the fix to be incomplete. Due to
    incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit
    segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may
    not trigger #GP. As we know, this imposes a security problem.

    In addition, the condition for two warnings was incorrect.

    Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715
    Reported-by: Dan Carpenter
    Signed-off-by: Nadav Amit
    [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo]
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Greg Kroah-Hartman

    Nadav Amit
     
  • commit f974008f07a62171a9dede08250c9a35c2b2b986 upstream.

    Add keyboard input assist controls usages from approved
    hid usage table request HUTTR42:
    http://www.usb.org/developers/hidpage/HUTRR42c.pdf

    Signed-off-by: Olivier Gay
    Acked-by: Dmitry Torokhov
    Signed-off-by: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Olivier Gay
     
  • commit 002758992693ae63c04122603ea9261a0a58d728 upstream.

    The bulkstat main loop progress is tracked by the "lastino"
    variable, which is a full 64 bit inode. However, the loop actually
    works on agno/agino pairs, and so there's a significant disconnect
    between the rest of the loop and the main cursor. Convert this to
    use the agino, and pass the agino into the chunk formatting function
    and convert it too.

    This gets rid of the inconsistency in the loop processing, and
    finally makes it simple for us to skip inodes at any point in the
    loop simply by incrementing the agino cursor.

    Signed-off-by: Dave Chinner
    Reviewed-by: Brian Foster
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit febe3cbe38b0bc0a925906dc90e8d59048851f87 upstream.

    The error propagation is a horror - xfs_bulkstat() returns
    a rval variable which is only set if there are formatter errors. Any
    sort of btree walk error or corruption will cause the bulkstat walk
    to terminate but will not pass an error back to userspace. Worse
    is the fact that formatter errors will also be ignored if any inodes
    were correctly formatted into the user buffer.

    Hence bulkstat can fail badly yet still report success to userspace.
    This causes significant issues with xfsdump not dumping everything
    in the filesystem yet reporting success. It's not until a restore
    fails that there is any indication that the dump was bad and tha
    bulkstat failed. This patch now triggers xfsdump to fail with
    bulkstat errors rather than silently missing files in the dump.

    This now causes bulkstat to fail when the lastino cookie does not
    fall inside an existing inode chunk. The pre-3.17 code tolerated
    that error by allowing the code to move to the next inode chunk
    as the agino target is guaranteed to fall into the next btree
    record.

    With the fixes up to this point in the series, xfsdump now passes on
    the troublesome filesystem image that exposes all these bugs.

    Signed-off-by: Dave Chinner
    Reviewed-by: Brian Foster
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit 6e57c542cb7e0e580eb53ae76a77875c7d92b4b1 upstream.

    There are a bunch of variables tha tare more wildy scoped than they
    need to be, obfuscated user buffer checks and tortured "next inode"
    tracking. This all needs cleaning up to expose the real issues that
    need fixing.

    Signed-off-by: Dave Chinner
    Reviewed-by: Brian Foster
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit 2b831ac6bc87d3cbcbb1a8816827b6923403e461 upstream.

    The loop construct has issues:
    - clustidx is completely unused, so remove it.
    - the loop tries to be smart by terminating when the
    "freecount" tells it that all inodes are free. Just drop
    it as in most cases we have to scan all inodes in the
    chunk anyway.
    - move the "user buffer left" condition check to the only
    point where we consume space int eh user buffer.
    - move the initialisation of agino out of the loop, leaving
    just a simple loop control logic using the clusteridx.

    Also, double handling of the user buffer variables leads to problems
    tracking the current state - use the cursor variables directly
    rather than keeping local copies and then having to update the
    cursor before returning.

    Signed-off-by: Dave Chinner
    Reviewed-by: Brian Foster
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit bf4a5af20d25ecc8876978ad34b8db83b4235f3c upstream.

    The xfs_bulkstat_agichunk formatting cursor takes buffer values from
    the main loop and passes them via the structure to the chunk
    formatter, and the writes the changed values back into the main loop
    local variables. Unfortunately, this complex dance is full of corner
    cases that aren't handled correctly.

    The biggest problem is that it is double handling the information in
    both the main loop and the chunk formatting function, leading to
    inconsistent updates and endless loops where progress is not made.

    To fix this, push the struct xfs_bulkstat_agichunk outwards to be
    the primary holder of user buffer information. this removes the
    double handling in the main loop.

    Also, pass the last inode processed by the chunk formatter as a
    separate parameter as it purely an output variable and is not
    related to the user buffer consumption cursor.

    Finally, the chunk formatting code is not shared by anyone, so make
    it local to xfs_itable.c.

    Signed-off-by: Dave Chinner
    Reviewed-by: Brian Foster
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit afa947cb52a8e73fe71915a0b0af6fcf98dfbe1a upstream.

    The bulkstat code has several different ways of detecting the end of
    an AG when doing a walk. They are not consistently detected, and the
    code that checks for the end of AG conditions is not consistently
    coded. Hence the are conditions where the walk code can get stuck in
    an endless loop making no progress and not triggering any
    termination conditions.

    Convert all the "tmp/i" status return codes from btree operations
    to a common name (stat) and apply end-of-ag detection to these
    operations consistently.

    Signed-off-by: Dave Chinner
    Reviewed-by: Brian Foster
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit 7a19dee116c8fae7ba7a778043c245194289f5a2 upstream.

    xfs_bulkstat() doesn't check error return from xfs_btree_increment(). In
    case of specific fs corruption that could result in xfs_bulkstat()
    entering an infinite loop because we would be looping over the same
    chunk over and over again. Fix the problem by checking the return value
    and terminating the loop properly.

    Coverity-id: 1231338
    Signed-off-by: Jan Kara
    Reviewed-by: Jie Liu
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Jan Kara
     
  • commit a6bbce54efa9145dbcf3029c885549f7ebc40a3b upstream.

    The recent refactoring of the bulkstat code left a small landmine in
    the code. If a inobt read fails, then the tree walk is aborted and
    returns without releasing the AGI buffer or freeing the cursor. This
    can lead to a subsequent bulkstat call hanging trying to grab the
    AGI buffer again.

    Signed-off-by: Dave Chinner
    Reviewed-by: Brian Foster
    Reviewed-by: Eric Sandeen
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit 6e5aafb27419f32575b27ef9d6a31e5d54661aca upstream.

    If we hit any errors in btrfs_lookup_csums_range, we'll loop through all
    the csums we allocate and free them. But the code was using list_entry
    incorrectly, and ended up trying to free the on-stack list_head instead.

    This bug came from commit 0678b6185

    btrfs: Don't BUG_ON kzalloc error in btrfs_lookup_csums_range()

    Signed-off-by: Chris Mason
    Reported-by: Erik Berg
    Signed-off-by: Greg Kroah-Hartman

    Chris Mason
     
  • commit a87fa1d81a9fb5e9adca9820e16008c40ad09f33 upstream.

    The string property read helpers will run off the end of the buffer if
    it is handed a malformed string property. Rework the parsers to make
    sure that doesn't happen. At the same time add new test cases to make
    sure the functions behave themselves.

    The original implementations of of_property_read_string_index() and
    of_property_count_strings() both open-coded the same block of parsing
    code, each with it's own subtly different bugs. The fix here merges
    functions into a single helper and makes the original functions static
    inline wrappers around the helper.

    One non-bugfix aspect of this patch is the addition of a new wrapper,
    of_property_read_string_array(). The new wrapper is needed by the
    device_properties feature that Rafael is working on and planning to
    merge for v3.19. The implementation is identical both with and without
    the new static inline wrapper, so it just got left in to reduce the
    churn on the header file.

    Signed-off-by: Grant Likely
    Cc: Rafael J. Wysocki
    Cc: Mika Westerberg
    Cc: Rob Herring
    Cc: Arnd Bergmann
    Cc: Darren Hart
    Signed-off-by: Greg Kroah-Hartman

    Grant Likely
     
  • commit 92c9e0c780e61f821ab8a08f0d4d4fd33ba1197c upstream.

    The Parallella board comes with a U-Boot bootloader that loads one of
    two predefined FPGA bitstreams before booting the kernel. Both define an
    AXI interface to the on-board Epiphany processor.

    Enable clocks FCLK0..FCLK3 for the Programmable Logic by default.

    Otherwise accessing, e.g., the ESYSRESET register freezes the board,
    as seen with the Epiphany SDK tools e-reset and e-hw-rev, using /dev/mem.

    Signed-off-by: Andreas Färber
    Acked-by: Michal Simek
    Signed-off-by: Olof Johansson
    Signed-off-by: Greg Kroah-Hartman

    Andreas Färber
     
  • commit e4a60d139060975eb956717e4f63ae348d4d8cc5 upstream.

    There is a race condition when removing glue directory.
    It can be reproduced in following test:

    path 1: Add first child device
    device_add()
    get_device_parent()
    /*find parent from glue_dirs.list*/
    list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
    if (k->parent == parent_kobj) {
    kobj = kobject_get(k);
    break;
    }
    ....
    class_dir_create_and_add()

    path2: Remove last child device under glue dir
    device_del()
    cleanup_device_parent()
    cleanup_glue_dir()
    kobject_put(glue_dir);

    If path2 has been called cleanup_glue_dir(), but not
    call kobject_put(glue_dir), the glue dir is still
    in parent's kset list. Meanwhile, path1 find the glue
    dir from the glue_dirs.list. Path2 may release glue dir
    before path1 call kobject_get(). So kernel will report
    the warning and bug_on.

    This is a "classic" problem we have of a kref in a list
    that can be found while the last instance could be removed
    at the same time.

    This patch reuse gdp_mutex to fix this race condition.

    The following calltrace is captured in kernel 3.4, but
    the latest kernel still has this bug.

    -----------------------------------------------------
    [ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
    [ 3965.441474] Hardware name: Romley
    [ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
    ...
    [ 3965.441605] Call Trace:
    [ 3965.441611] [] warn_slowpath_common+0x7a/0xb0
    [ 3965.441615] [] warn_slowpath_null+0x15/0x20
    [ 3965.441618] [] kobject_get+0x33/0x40
    [ 3965.441624] [] get_device_parent.isra.11+0x135/0x1f0
    [ 3965.441627] [] device_add+0xd4/0x6d0
    [ 3965.441631] [] ? dev_set_name+0x3c/0x40
    ....
    [ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
    [ 3965.441915] invalid opcode: 0000 [#1] SMP
    ...
    [ 3965.686743] [] sysfs_create_group+0xe/0x10
    [ 3965.686748] [] blk_trace_init_sysfs+0x14/0x20
    [ 3965.686753] [] blk_register_queue+0x3b/0x120
    [ 3965.686756] [] add_disk+0x1cc/0x490
    ....
    -------------------------------------------------------

    Signed-off-by: Yijing Wang
    Signed-off-by: Weng Meiling
    Signed-off-by: Greg Kroah-Hartman

    Yijing Wang
     
  • commit 11cfbfb098b22d3e57f1f2be217cad20e2d48463 upstream.

    iowait is for blkio [1]. I2C shouldn't use it.

    [1] https://lkml.org/lkml/2014/11/3/317

    Signed-off-by: Wolfram Sang
    Acked-by: Ludovic Desroches
    Signed-off-by: Greg Kroah-Hartman

    Wolfram Sang
     
  • commit 758e8366754d3fa57da978fef9d2c652f7b55c02 upstream.

    In both Armada-375 and Armada-38x MPIC interrupts should be identified by
    reading cause register multiplied by the interrupt mask.

    A lack of above mentioned multiplication resulted in a bug, caused by the
    fact that in Armada-375 and Armada-38x some of the interrupts
    (e.g. network interrupts) can be handled either as a GIC or MPIC interrupts.
    Therefore during MPIC interrupts handling, cause register shows hits from
    interrupts even if they are masked for MPIC but unmasked for a GIC.

    This resulted in 'bad IRQ' error, because masked MPIC interrupt without
    registered interrupt handler, was trying to be handled during interrupt
    handling procedure of some other unmasked MPIC interrupt (e.g. local timer
    irq).

    This commit fixes that by ensuring that during MPIC interrupt handling only
    interrupts that are unmasked for MPIC are processed.

    Signed-off-by: Grzegorz Jaszczyk
    Reviewed-by: Gregory CLEMENT
    Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
    Acked-by: Ezequiel Garcia
    Link: https://lkml.kernel.org/r/1411643839-64925-3-git-send-email-jaz@semihalf.com
    Signed-off-by: Jason Cooper
    Signed-off-by: Greg Kroah-Hartman

    Grzegorz Jaszczyk
     
  • commit 298dcb2dd0267d51e4f7c94a628cd0765a50ad75 upstream.

    The MSI interrupts use the 16 high doorbells, which are notified by using IRQ1
    of the main interrupt controller.

    The MSI interrupts were handled correctly for Armada-XP and Armada-370 but not
    for Armada-375 and Armada-38x, which use chained handler for the MPIC.

    This commit fixes that by checking proper interrupt number in chained handler
    for the MPIC.

    Signed-off-by: Grzegorz Jaszczyk
    Reviewed-by: Gregory CLEMENT
    Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
    Acked-by: Ezequiel Garcia
    Link: https://lkml.kernel.org/r/1411643839-64925-2-git-send-email-jaz@semihalf.com
    Signed-off-by: Jason Cooper
    Signed-off-by: Greg Kroah-Hartman

    Grzegorz Jaszczyk
     
  • commit ca0c37a0b489bb14bf3e1549e7a8d0c9a17f4919 upstream.

    Driver allocated on stack struct regulator_config but didn't initialize
    it fully. Few fields (driver_data, ena_gpio) were left untouched. This
    lead to using random ena_gpio values as GPIOs for max77693 regulators.

    On occasion these values could match real GPIO numbers leading to
    interfering with other drivers and to unsuccessful enable/disable of
    regulator.

    Signed-off-by: Krzysztof Kozlowski
    Fixes: 80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.")
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Krzysztof Kozlowski
     
  • commit c922c4e87b9b5a3b50d4d17b96f189121430f511 upstream.

    Without the fix, the mute led can't work on these three machines.

    After apply this fix, these three machines will fall back on the led
    control quirk as below, and through testing, the mute led works very
    well.
    PIN_QUIRK(0x10ec0282, 0x103c, "HP", ALC269_FIXUP_HP_LINE1_MIC1_LED,
    ALC282_STANDARD_PINS,
    {0x12, 0x90a60140},
    ...

    BugLink: https://bugs.launchpad.net/bugs/1389497
    Tested-by: TieFu Chen
    Cc: Kailang Yang
    Signed-off-by: Hui Wang
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Hui Wang
     
  • commit 808be31426af57af22268ef0fcb42617beb3d15b upstream.

    Back in 7230c5644188 ("powerpc: Rework lazy-interrupt handling") we
    added a call out to restore_interrupts() (written in c) before calling
    do_notify_resume:

    bl restore_interrupts
    addi r3,r1,STACK_FRAME_OVERHEAD
    bl do_notify_resume

    Unfortunately do_notify_resume takes two arguments, the second one
    being the thread_info flags:

    void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)

    We do populate r4 (the second argument) earlier, but
    restore_interrupts() is free to muck it up all it wants. My guess is
    the gcc compiler gods shone down on us and its register allocator
    never used r4. Sometimes, rarely, luck is on our side.

    LLVM on the other hand did trample r4.

    Signed-off-by: Anton Blanchard
    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Anton Blanchard
     
  • commit 325e4114043469e5f9923d902b4d30bcc2be8163 upstream.

    Endian is hard, especially when I designed a stupid FW interface, and
    I should know better... oh well, this is attempt #2 at fixing this
    properly. This time it seems to work with all access sizes and I
    can run my flashing tool (which exercises all sort of access sizes
    and types to access the SPI controller in the BMC) just fine.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     
  • commit 10ccaf178b2b961d8bca252d647ed7ed8aae2a20 upstream.

    In powerpc pseries platform dlpar operations, use device_online() and
    device_offline() instead of cpu_up() and cpu_down().

    Calling cpu_up/down() directly does not update the cpu device offline
    field, which is used to online/offline a cpu from sysfs. Calling
    device_online/offline() instead keeps the sysfs cpu online value
    correct. The hotplug lock, which is required to be held when calling
    device_online/offline(), is already held when dlpar_online/offline_cpu()
    are called, since they are called only from cpu_probe|release_store().

    This patch fixes errors on phyp (PowerVM) systems that have cpu(s)
    added/removed using dlpar operations; without this patch, the
    /sys/devices/system/cpu/cpuN/online nodes do not correctly show the
    online state of added/removed cpus.

    Signed-off-by: Dan Streetman
    Cc: Nathan Fontenot
    Fixes: 0902a9044fa5 ("Driver core: Use generic offline/online for CPU offline/online")
    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Dan Streetman
     
  • commit cde7fc879969f933614b1256df2625d6ff637bab upstream.

    The commit 2111667b4677 ("ARM: pxa: call debug_ll_io_init for
    earlyprintk") triggers in the current kernel the attached backtrace on
    PXA/tosa early in the boot time when DEBUG_LL is enabled.

    It is due to overlap between uart virtual memory defined in
    DEBUG_UART_VIRT and mapped by debug_ll_io_init() and peripheral bus
    mapped by pxa_map_io at the same address, 0xf2100000.

    As hinted by Arnd, map early virtual memory for low level debug on
    address 0xf6200000, even if that means 2 virtual mappings will give
    access to the pxa internal UARTs (FFUART, BTUART, STUART, ...).

    ------------[ cut here ]------------
    kernel BUG at /home/lumag/linux/mm/vmalloc.c:1143!
    Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-00032-g8e0d202-dirty #23
    task: c062a5a8 ti: c0620000 task.ti: c0620000
    PC is at vm_area_add_early+0x54/0x84
    LR is at add_static_vm_early+0xc/0x60
    pc : [] lr : [] psr: 800001d3
    sp : c0621f04 ip : c03efa74 fp : c03edf84
    r10: c0637e98 r9 : 40000001 r8 : c03da57c
    r7 : c3ffcfb0 r6 : 00000000 r5 : c3ffcfb0 r4 : 02000000
    r3 : c3ffcfd8 r2 : f2100000 r1 : f4000000 r0 : c3ffcfb0
    Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
    Control: 00007977 Table: a0004000 DAC: 00000017
    Process swapper (pid: 0, stack limit = 0xc06201c8)
    Stack: (0xc0621f04 to 0xc0622000)
    1f00: c3ffcfd8 40000001 c3ffcfd8 c03ee08c c03da570 c03db90c c0637d24
    1f20: 00000000 c03ec7cc c066e654 a0700000 000a0700 c03db914 c03db90c c03daf84
    1f40: 00000000 000a0000 c0000000 c03ec7cc 000a0700 c0700000 ffff1000 000a3fff
    1f60: 00001000 00000007 00000000 c03ec7cc c0008000 c03ed748 c0621fd4 c03d5d18
    1f80: 69052d00 a03ec48c 00000000 c03d8ad0 0000006c 00007977 c036c6e8 00000001
    1fa0: c0621fd4 c03ed744 c0628000 a0004000 69052d00 a03ec48c 00000000 c03d68d4
    1fc0: 00000000 00000000 00000000 00000000 00000000 c03ed748 c0649894 c062801c
    1fe0: c03ed744 c062b2f0 a0004000 69052d00 a03ec48c a0008040 00000000 00000000
    [] (vm_area_add_early) from [] (add_static_vm_early+0xc/0x60)
    [] (add_static_vm_early) from [] (iotable_init.part.6+0xa8/0xb4)
    [] (iotable_init.part.6) from [] (pxa25x_map_io+0x8/0x24)
    [] (pxa25x_map_io) from [] (paging_init+0x744/0x8d8)
    [] (paging_init) from [] (setup_arch+0x354/0x608)
    [] (setup_arch) from [] (start_kernel+0xa8/0x3dc)
    [] (start_kernel) from [] (0xa0008040)
    Code: e5904008 e0811004 e1520001 2a000005 (e7f001f2)
    ---[ end trace f24b6c88ae00fa9a ]---
    Kernel panic - not syncing: Attempted to kill the idle task!
    ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

    Reported-by: Dmitry Eremin-Solenikov
    Signed-off-by: Robert Jarzmik
    Acked-by: Arnd Bergmann
    Signed-off-by: Greg Kroah-Hartman

    Robert Jarzmik
     
  • commit d90c33818967c5e5371961604ad98b4dea4fa3f4 upstream.

    Even if a gpio pin is set to output, we still need to set INPUT_EN
    functionality (by clearing INPUT_EN bit) to be able to read the pin's
    level.

    E.g. without this change, we'll always read low level state from sysfs.

    Cc: Mathias Nyman
    Signed-off-by: David Cohen
    Reviewed-by: Felipe Balbi
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    David Cohen
     
  • commit 7e8631e8b9d4e9f698c09c7e7309c96249180ff9 upstream.

    uninitialized msghdr. Broken in "ocfs2: don't open-code kernel_recvmsg()"
    by me ;-/

    Signed-off-by: Al Viro
    Signed-off-by: Greg Kroah-Hartman

    Al Viro
     
  • commit 5a1426c99f9b7aa11d60c4e6b7a3211bb5321696 upstream.

    The acpi-video backlight interface on the NC210 does not work, blacklist it
    and use the samsung-laptop interface instead.

    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=861573
    Signed-off-by: Hans de Goede
    Signed-off-by: Darren Hart
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit 183fd8fcd7f8afb7ac5ec68f83194872f9fecc84 upstream.

    The acpi-video backlight interface on the Acer KAV80 is broken, and worse
    it causes the entire machine to slow down significantly after a suspend/resume.

    Blacklist it, and use the acer-wmi backlight interface instead. Note that
    the KAV80 is somewhat unique in that it is the only Acer model where we
    fall back to acer-wmi after blacklisting, rather then using the native
    (e.g. intel) backlight driver. This is done because there is no native
    backlight interface on this model.

    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1128309
    Signed-off-by: Hans de Goede
    Signed-off-by: Darren Hart
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit a8d4205623ae965e36c68629db306ca0695a2771 upstream.

    When we fail to allocate page vector in rbd_obj_read_sync() we just
    basically ignore the problem and continue which will result in an oops
    later. Fix the problem by returning proper error.

    CC: Yehuda Sadeh
    CC: Sage Weil
    CC: ceph-devel@vger.kernel.org
    Coverity-id: 1226882
    Signed-off-by: Jan Kara
    Signed-off-by: Ilya Dryomov
    Signed-off-by: Greg Kroah-Hartman

    Jan Kara
     
  • commit f022d8cb7ec70fe8edd56383d876001317ee76b1 upstream.

    If activation of the CMA area fails its mutex won't be initialized,
    leading to an oops at allocation time when trying to lock the mutex. Fix
    this by setting the cma area count field to 0 when activation fails,
    leading to allocation returning NULL immediately.

    Signed-off-by: Laurent Pinchart
    Acked-by: Michal Nazarewicz
    Signed-off-by: Marek Szyprowski
    Signed-off-by: Greg Kroah-Hartman

    Laurent Pinchart
     
  • commit b2a9601c587dbc5536546aa54009d1130adedd72 upstream.

    commit c675949ec58ca50d5a3ae3c757892f1560f6e896
    Author: Jani Nikula
    Date: Wed Apr 9 11:31:37 2014 +0300

    drm/i915: do not setup backlight if not available according to VBT

    prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT
    check so backlight is set up properly.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438
    Signed-off-by: Jens Stein Jørgensen
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    jens stein
     
  • commit 6be1e3d3ea29354d7c834a3936e796e185d5c73b upstream.

    vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.

    This is a regression from:
    commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727
    Author: Ville Syrjälä
    Date: Fri Jun 13 13:37:54 2014 +0300

    drm/i915: Kill duplicated cdclk readout code from i2c

    Signed-off-by: Ville Syrjälä
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Ville Syrjälä
     
  • commit f6a1906674005377b64ee5431c1418077c1b2425 upstream.

    Sometimes we seem to get utter garbage from DPCD reads. The resulting
    buffer is filled with the same byte, and the operation completed without
    errors. My HP ZR24w monitor seems particularly susceptible to this
    problem once it's gone into a sleep mode.

    The issue seems to happen only for the first AUX message that wakes the
    sink up. But as the first AUX read we often do is the DPCD receiver
    cap it does wreak a bit of havoc with subsequent link training etc. when
    the receiver cap bw/lane/etc. information is garbage.

    A sufficient workaround seems to be to perform a single byte dummy read
    before reading the actual data. I suppose that just wakes up the sink
    sufficiently and we can just throw away the returned data in case it's
    crap. DP_DPCD_REV seems like a sufficiently safe location to read here.

    Signed-off-by: Ville Syrjälä
    Reviewed-by: Todd Previte
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Ville Syrjälä
     
  • commit 8c3e434769b1707fd2d24de5a2eb25fedc634c4a upstream.

    0x4c6e is a secondary device id so should not be used
    by the driver.

    Noticed-by: Mark Kettenis
    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit 72b3f9183ed57e4a2f0601a1c25ae2fd39855952 upstream.

    - bapm seems to cause CPU stuck messages so disable it.
    - nb dpm seems to prevent GPU dpm from getting enabled, so
    disable it.

    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=85107

    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit e5a5fd4df21b9c4acb67e815ec949cce594860f8 upstream.

    Should avoid kmalloc failures due to large number of array entries.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81991
    Reviewed-by: Dave Airlie
    Reviewed-by: Christian König
    Signed-off-by: Michel Dänzer
    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Michel Dänzer
     
  • commit 6fa455935ab956248b165f150ec6ae9106210077 upstream.

    Causes problems on some boards.

    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=82889

    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit 9a72384d86b26cb8a2b25106677e1197f606668f upstream.

    When screen objects are enabled, the bpp is assumed to be 32, otherwise
    it is set to 16.

    v2:
    * Use u32 instead of u64 for assumed_bpp.
    * Fixed mechanism to check for screen objects
    * Limit the back buffer size to VRAM.

    Signed-off-by: Sinclair Yeh
    Reviewed-by: Thomas Hellstrom
    Signed-off-by: Greg Kroah-Hartman

    Sinclair Yeh
     
  • commit f18298595aefa2c836a128ec6e0f75f39965dd81 upstream.

    Intel MID platforms has no legacy interrupts, so no IRQ descriptors
    preallocated. We need to call mp_map_gsi_to_irq() to create IRQ
    descriptors for APB timers and RTC timers, otherwise it may cause
    invalid memory access as:
    [ 0.116839] BUG: unable to handle kernel NULL pointer dereference at
    0000003a
    [ 0.123803] IP: [] setup_irq+0xf/0x4d

    Tested-by: Andy Shevchenko
    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Joerg Roedel
    Cc: Greg Kroah-Hartman
    Cc: H. Peter Anvin
    Cc: Benjamin Herrenschmidt
    Cc: Rafael J. Wysocki
    Cc: Bjorn Helgaas
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Borislav Petkov
    Cc: David Cohen
    Link: http://lkml.kernel.org/r/1414387308-27148-3-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Jiang Liu
     
  • commit f1e3a0932f3a9554371792a7daaf1e0eb19f66d5 upstream.

    Probability of use-after-free isn't zero in this place.

    Signed-off-by: Kirill Tkhai
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Paul E. McKenney
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/20140922183636.11015.83611.stgit@localhost
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Kirill Tkhai