Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on May 2, 2011
  1. Merge branch 'configs-2.6.38' into pf-2.6.38

    Oleksandr Natalenko authored
  2. configs-2.6.38: update config for Dell Inspiron 1525 laptop

    Oleksandr Natalenko authored
  3. Merge branch 'version-2.6.38' into pf-2.6.38

    Oleksandr Natalenko authored
  4. version-2.6.38: bump to v2.6.38-pf7

    Oleksandr Natalenko authored
  5. fix merge conflict

    Oleksandr Natalenko authored
  6. @gregkh

    Linux 2.6.38.5

    gregkh authored
  7. @gregkh

    Input: xen-kbdfront - fix mouse getting stuck after save/restore

    Igor Mammedov authored gregkh committed
    commit c36b58e upstream.
    
    Mouse gets "stuck" after restore of PV guest but buttons are in working
    condition.
    
    If driver has been configured for ABS coordinates at start it will get
    XENKBD_TYPE_POS events and then suddenly after restore it'll start getting
    XENKBD_TYPE_MOTION events, that will be dropped later and they won't get
    into user-space.
    
    Regression was introduced by hunk 5 and 6 of
    5ea5254
    ("Input: xen-kbdfront - advertise either absolute or relative
    coordinates").
    
    Driver on restore should ask xen for request-abs-pointer again if it is
    available. So restore parts that did it before 5ea5254.
    
    Acked-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Igor Mammedov <imammedo@redhat.com>
    [v1: Expanded the commit description]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
  8. @sgruszka @gregkh

    iwlegacy: fix tx_power initialization

    sgruszka authored gregkh committed
    commit 332704a upstream.
    
    priv->tx_power_next is not initialized to max supported power,
    but instead default value is used, what cause errors like
    
    [   58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
    [   58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).
    
    if maximum tx power read from the eeprom is smaller than default.
    In consequence card is unable to initialize properly. Fix the problem
    and cleanup tx power initialization.
    
    Reported-and-tested-by: Robin Dong <hao.bigrat@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @sgruszka @gregkh

    iwl3945: disable hw scan by default

    sgruszka authored gregkh committed
    commit 0263aa4 upstream.
    
    After new NetworkManager 0.8.996 changes, hardware scanning is causing
    microcode errors as reported here:
    https://bugzilla.redhat.com/show_bug.cgi?id=683571
    and sometimes kernel crashes:
    https://bugzilla.redhat.com/show_bug.cgi?id=688252
    
    Also with hw scan there are very bad performance on some systems
    as reported here:
    https://bugzilla.redhat.com/show_bug.cgi?id=671366
    
    Since Intel no longer supports 3945, there is no chance to get proper
    firmware fixes, we need workaround problems by disable hardware scanning
    by default.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @sgruszka @gregkh

    iwl3945: do not deprecate software scan

    sgruszka authored gregkh committed
    commit 3bda50e upstream.
    
    Software scanning can be used for workaround some performance problems,
    so do not deprecate it.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @sgruszka @gregkh

    iwlwifi: do not set tx power when channel is changing

    sgruszka authored gregkh committed
    commit f844a70 upstream.
    
    Mac80211 can request for tx power and channel change in one ->config
    call. If that happens, *_send_tx_power functions will try to setup tx
    power for old channel, what can be not correct because we already change
    the band. I.e  error  "Failed to get channel info for channel 140 [0]",
    can be printed frequently when operating in software scanning mode.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    agp: fix OOM and buffer overflow

    Vasiliy Kulikov authored gregkh committed
    commit b522f02 upstream.
    
    page_count is copied from userspace.  agp_allocate_memory() tries to
    check whether this number is too big, but doesn't take into account the
    wrap case.  Also agp_create_user_memory() doesn't check whether
    alloc_size is calculated from num_agp_pages variable without overflow.
    This may lead to allocation of too small buffer with following buffer
    overflow.
    
    Another problem in agp code is not addressed in the patch - kernel memory
    exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls).  It is not checked
    whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()).
    Each allocation is limited to 16KB, though, there is no per-process limit.
    This might lead to OOM situation, which is not even solved in case of the
    caller death by OOM killer - the memory is allocated for another (faked) process.
    
    Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    agp: fix arbitrary kernel memory writes

    Vasiliy Kulikov authored gregkh committed
    commit 194b3da upstream.
    
    pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl
    cmds of agp_ioctl() and passed to agpioc_bind_wrap().  As said in the
    comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND,
    and it is not checked at all in case of AGPIOC_UNBIND.  As a result, user
    with sufficient privileges (usually "video" group) may generate either
    local DoS or privilege escalation.
    
    Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    drm: select FRAMEBUFFER_CONSOLE_PRIMARY if we have FRAMEBUFFER_CONSOLE

    Dave Airlie authored gregkh committed
    commit bf5192e upstream.
    
    Multi-gpu/switcheroo relies on this option to get the console on the
    correct GPU at bootup, some distros enable it but it seems some get
    it wrong.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @richardweinberger @gregkh

    um: mdd support for 64 bit atomic operations

    richardweinberger authored gregkh committed
    commit 57d8e02 upstream.
    
    This adds support for 64 bit atomic operations on 32 bit UML systems.  XFS
    needs them since 2.6.38.
    
      $ make ARCH=um SUBARCH=i386
      ...
        LD      .tmp_vmlinux1
      fs/built-in.o: In function `xlog_regrant_reserve_log_space':
      xfs_log.c:(.text+0xd8584): undefined reference to `atomic64_read_386'
      xfs_log.c:(.text+0xd85ac): undefined reference to `cmpxchg8b_emu'
      ...
    
    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=32812
    
    Reported-by: Martin Walch <walch.martin@web.de>
    Tested-by: Martin Walch <walch.martin@web.de>
    Cc: Martin Walch <walch.martin@web.de>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    NFSv4.1: Ensure state manager thread dies on last umount

    Trond Myklebust authored gregkh committed
    commit 47c2199 upstream.
    
    Currently, the state manager may continue to try recovering state forever
    even after the last filesystem to reference that nfs_client has umounted.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    nfs: don't lose MS_SYNCHRONOUS on remount of noac mount

    Jeff Layton authored gregkh committed
    commit 26c4c17 upstream.
    
    On a remount, the VFS layer will clear the MS_SYNCHRONOUS bit on the
    assumption that the flags on the mount syscall will have it set if the
    remounted fs is supposed to keep it.
    
    In the case of "noac" though, MS_SYNCHRONOUS is implied. A remount of
    such a mount will lose the MS_SYNCHRONOUS flag since "sync" isn't part
    of the mount options.
    
    Reported-by: Max Matveev <makc@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    vfs: avoid large kmalloc()s for the fdtable

    Andrew Morton authored gregkh committed
    commit 6d4831c upstream.
    
    Azurit reports large increases in system time after 2.6.36 when running
    Apache.  It was bisected down to a892e2d ("vfs: use kmalloc()
    to allocate fdmem if possible").
    
    That patch caused the vfs to use kmalloc() for very large allocations and
    this is causing excessive work (and presumably excessive reclaim) within
    the page allocator.
    
    Fix it by falling back to vmalloc() earlier - when the allocation attempt
    would have been considered "costly" by reclaim.
    
    Reported-by: azurIt <azurit@pobox.sk>
    Tested-by: azurIt <azurit@pobox.sk>
    Acked-by: Changli Gao <xiaosuo@gmail.com>
    Cc: Americo Wang <xiyou.wangcong@gmail.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    m68k/mm: Set all online nodes in N_NORMAL_MEMORY

    Michael Schmitz authored gregkh committed
    commit 4aac0b4 upstream.
    
    For m68k, N_NORMAL_MEMORY represents all nodes that have present memory
    since it does not support HIGHMEM.  This patch sets the bit at the time
    node_present_pages has been set by free_area_init_node.
    At the time the node is brought online, the node state would have to be
    done unconditionally since information about present memory has not yet
    been recorded.
    
    If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it
    uses this nodemask to setup per-cache kmem_cache_node data structures.
    
    This pach is an alternative to the one proposed by David Rientjes
    <rientjes@google.com> attempting to set node state immediately when
    bringing the node online.
    
    Signed-off-by: Michael Schmitz <schmitz@debian.org>
    Tested-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups

    Andrea Arcangeli authored gregkh committed
    commit 78f11a2 upstream.
    
    The huge_memory.c THP page fault was allowed to run if vm_ops was null
    (which would succeed for /dev/zero MAP_PRIVATE, as the f_op->mmap wouldn't
    setup a special vma->vm_ops and it would fallback to regular anonymous
    memory) but other THP logics weren't fully activated for vmas with vm_file
    not NULL (/dev/zero has a not NULL vma->vm_file).
    
    So this removes the vm_file checks so that /dev/zero also can safely use
    THP (the other albeit safer approach to fix this bug would have been to
    prevent the THP initial page fault to run if vm_file was set).
    
    After removing the vm_file checks, this also makes huge_memory.c stricter
    in khugepaged for the DEBUG_VM=y case.  It doesn't replace the vm_file
    check with a is_pfn_mapping check (but it keeps checking for VM_PFNMAP
    under VM_BUG_ON) because for a is_cow_mapping() mapping VM_PFNMAP should
    only be allowed to exist before the first page fault, and in turn when
    vma->anon_vma is null (so preventing khugepaged registration).  So I tend
    to think the previous comment saying if vm_file was set, VM_PFNMAP might
    have been set and we could still be registered in khugepaged (despite
    anon_vma was not NULL to be registered in khugepaged) was too paranoid.
    The is_linear_pfn_mapping check is also I think superfluous (as described
    by comment) but under DEBUG_VM it is safe to stay.
    
    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=33682
    
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Reported-by: Caspar Zhang <bugs@casparzhang.com>
    Acked-by: Mel Gorman <mel@csn.ul.ie>
    Acked-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    mm: check if PTE is already allocated during page fault

    Mel Gorman authored gregkh committed
    commit cc03638 upstream.
    
    With transparent hugepage support, handle_mm_fault() has to be careful
    that a normal PMD has been established before handling a PTE fault.  To
    achieve this, it used __pte_alloc() directly instead of pte_alloc_map as
    pte_alloc_map is unsafe to run against a huge PMD.  pte_offset_map() is
    called once it is known the PMD is safe.
    
    pte_alloc_map() is smart enough to check if a PTE is already present
    before calling __pte_alloc but this check was lost.  As a consequence,
    PTEs may be allocated unnecessarily and the page table lock taken.  Thi
    useless PTE does get cleaned up but it's a performance hit which is
    visible in page_test from aim9.
    
    This patch simply re-adds the check normally done by pte_alloc_map to
    check if the PTE needs to be allocated before taking the page table lock.
    The effect is noticable in page_test from aim9.
    
      AIM9
                      2.6.38-vanilla 2.6.38-checkptenone
      creat-clo      446.10 ( 0.00%)   424.47 (-5.10%)
      page_test       38.10 ( 0.00%)    42.04 ( 9.37%)
      brk_test        52.45 ( 0.00%)    51.57 (-1.71%)
      exec_test      382.00 ( 0.00%)   456.90 (16.39%)
      fork_test       60.11 ( 0.00%)    67.79 (11.34%)
      MMTests Statistics: duration
      Total Elapsed Time (seconds)                611.90    612.22
    
    (While this affects 2.6.38, it is a performance rather than a functional
    bug and normally outside the rules -stable.  While the big performance
    differences are to a microbench, the difference in fork and exec
    performance may be significant enough that -stable wants to consider the
    patch)
    
    Reported-by: Raz Ben Yehuda <raziebe@gmail.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @kosaki @gregkh

    oom: use pte pages in OOM score

    kosaki authored gregkh committed
    commit f755a04 upstream.
    
    PTE pages eat up memory just like anything else, but we do not account for
    them in any way in the OOM scores.  They are also _guaranteed_ to get
    freed up when a process is OOM killed, while RSS is not.
    
    Reported-by: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    virtio: console: Enable call to hvc_remove() on console port remove

    Amit Shah authored gregkh committed
    commit afa2689 upstream.
    
    This call was disabled as hot-unplugging one virtconsole port led to
    another virtconsole port freezing.
    
    Upon testing it again, this now works, so enable it.
    
    In addition, a bug was found in qemu wherein removing a port of one type
    caused the guest output from another port to stop working.  I doubt it
    was just this bug that caused it (since disabling the hvc_remove() call
    did allow other ports to continue working), but since it's all solved
    now, we're fine with hot-unplugging of virtconsole ports.
    
    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci

    Patrick Boettcher authored gregkh committed
    commit b934c20 upstream.
    
    This patch fixes the warning about bad names for sys-fs and other kernel-things. The flexcop-pci driver was using '/'-characters in it, which is not good.
    This has been fixed in several attempts by several people, but obviously never made it into the kernel.
    
    Signed-off-by: Patrick Boettcher <pboettcher@kernellabs.com>
    Cc: Steffen Barszus <steffenbpunkt@googlemail.com>
    Cc: Boris Cuber <me@boris64.net>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    set memory ranges in N_NORMAL_MEMORY when onlined

    David Rientjes authored gregkh committed
    commit d9b41e0 upstream.
    
    When a DISCONTIGMEM memory range is brought online as a NUMA node, it
    also needs to have its bet set in N_NORMAL_MEMORY.  This is necessary for
    generic kernel code that utilizes N_NORMAL_MEMORY as a subset of N_ONLINE
    for memory savings.
    
    These types of hacks can hopefully be removed once DISCONTIGMEM is either
    removed or abstracted away from CONFIG_NUMA.
    
    Fixes a panic in the slub code which only initializes structures for
    N_NORMAL_MEMORY to save memory:
    
    	Backtrace:
    	 [<000000004021c938>] add_partial+0x28/0x98
    	 [<000000004021faa0>] __slab_free+0x1d0/0x1d8
    	 [<000000004021fd04>] kmem_cache_free+0xc4/0x128
    	 [<000000004033bf9c>] ida_get_new_above+0x21c/0x2c0
    	 [<00000000402a8980>] sysfs_new_dirent+0xd0/0x238
    	 [<00000000402a974c>] create_dir+0x5c/0x168
    	 [<00000000402a9ab0>] sysfs_create_dir+0x98/0x128
    	 [<000000004033d6c4>] kobject_add_internal+0x114/0x258
    	 [<000000004033d9ac>] kobject_add_varg+0x7c/0xa0
    	 [<000000004033df20>] kobject_add+0x50/0x90
    	 [<000000004033dfb4>] kobject_create_and_add+0x54/0xc8
    	 [<00000000407862a0>] cgroup_init+0x138/0x1f0
    	 [<000000004077ce50>] start_kernel+0x5a0/0x840
    	 [<000000004011fa3c>] start_parisc+0xa4/0xb8
    	 [<00000000404bb034>] packet_ioctl+0x16c/0x208
    	 [<000000004049ac30>] ip_mroute_setsockopt+0x260/0xf20
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    slub: fix panic with DISCONTIGMEM

    James Bottomley authored gregkh committed
    commit 4a5fa35 upstream.
    
    Slub makes assumptions about page_to_nid() which are violated by
    DISCONTIGMEM and !NUMA.  This violation results in a panic because
    page_to_nid() can be non-zero for pages in the discontiguous ranges and
    this leads to a null return by get_node().  The assertion by the
    maintainer is that DISCONTIGMEM should only be allowed when NUMA is also
    defined.  However, at least six architectures: alpha, ia64, m32r, m68k,
    mips, parisc violate this.  The panic is a regression against slab, so
    just mark slub broken in the problem configuration to prevent users
    reporting these panics.
    
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @rjwysocki @gregkh

    ACPI / PM: Avoid infinite recurrence while registering power resources

    rjwysocki authored gregkh committed
    commit 7bed50c upstream.
    
    There is at least one BIOS with a DSDT containing a power resource
    object with a _PR0 entry pointing back to that power resource.  In
    consequence, while registering that power resource
    acpi_bus_get_power_flags() sees that it depends on itself and tries
    to register it again, which leads to an infinitely deep recurrence.
    This problem was introduced by commit bf325f9
    (ACPI / PM: Register power resource devices as soon as they are
    needed).
    
    To fix this problem use the observation that power resources cannot
    be power manageable and prevent acpi_bus_get_power_flags() from
    being called for power resource objects.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=31872
    Reported-and-tested-by: Pascal Dormeau <pdormeau@free.fr>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Len Brown <lenb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @gregkh

    pfault: fix token handling

    Heiko Carstens authored gregkh committed
    commit e35c76c upstream.
    
    f6649a7 "[S390] cleanup lowcore access from external interrupts" changed
    handling of external interrupts. Instead of letting the external interrupt
    handlers accessing the per cpu lowcore the entry code of the kernel reads
    already all fields that are necessary and passes them to the handlers.
    The pfault interrupt handler was incorrectly converted. It tries to
    dereference a value which used to be a pointer to a lowcore field. After
    the conversion however it is not anymore the pointer to the field but its
    content. So instead of a dereference only a cast is needed to get the
    task pointer that caused the pfault.
    
    Fixes a NULL pointer dereference and a subsequent kernel crash:
    
    Unable to handle kernel pointer dereference at virtual kernel address (null)
    Oops: 0004 [#1] SMP
    Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc
                       loop qeth_l3 qeth vmur ccwgroup ext3 jbd mbcache dm_mod
                       dasd_eckd_mod dasd_diag_mod dasd_mod
    CPU: 0 Not tainted 2.6.38-2-s390x #1
    Process cron (pid: 1106, task: 000000001f962f78, ksp: 000000001fa0f9d0)
    Krnl PSW : 0404200180000000 000000000002c03e (pfault_interrupt+0xa2/0x138)
               R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
    Krnl GPRS: 0000000000000000 0000000000000001 0000000000000000 0000000000000001
               000000001f962f78 0000000000518968 0000000090000002 000000001ff03280
               0000000000000000 000000000064f000 000000001f962f78 0000000000002603
               0000000006002603 0000000000000000 000000001ff7fe68 000000001ff7fe48
    Krnl Code: 000000000002c036: 5820d010            l       %r2,16(%r13)
               000000000002c03a: 1832                lr      %r3,%r2
               000000000002c03c: 1a31                ar      %r3,%r1
              >000000000002c03e: ba23d010            cs      %r2,%r3,16(%r13)
               000000000002c042: a744fffc            brc     4,2c03a
               000000000002c046: a7290002            lghi    %r2,2
               000000000002c04a: e320d0000024        stg     %r2,0(%r13)
               000000000002c050: 07f0                bcr     15,%r0
    Call Trace:
     ([<000000001f962f78>] 0x1f962f78)
      [<000000000001acda>] do_extint+0xf6/0x138
      [<000000000039b6ca>] ext_no_vtime+0x30/0x34
      [<000000007d706e04>] 0x7d706e04
    Last Breaking-Event-Address:
      [<0000000000000000>] 0x0
    
    For stable maintainers:
    the first kernel which contains this bug is 2.6.37.
    
    Reported-by: Stephen Powell <zlinuxman@wowway.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @gregkh

    kvm-390: Let kernel exit SIE instruction on work

    Carsten Otte authored gregkh committed
    commit 9ff4cfb upstream.
    
    From: Christian Borntraeger <borntraeger@de.ibm.com>
    
    This patch fixes the sie exit on interrupts. The low level
    interrupt handler returns to the PSW address in pt_regs and not
    to the PSW address in the lowcore.
    Without this fix a cpu bound guest might never leave guest state
    since the host interrupt handler would blindly return to the
    SIE instruction, even on need_resched and friends.
    
    Signed-off-by: Carsten Otte <cotte@de.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    UBIFS: fix false space checking failure

    Artem Bityutskiy authored gregkh committed
    commit 8c230d9 upstream.
    
    This patch fixes UBIFS mount failure when the debugging support is enabled,
    we are recovering from a power cut, we were first mounter R/O and we are
    re-mounting R/W. In this case we should not assume that the amount of free
    space before we have re-mounted R/W and after are equivalent, because
    when we have mounted R/O the file-system is in a non-committed state so
    the amount of free space is slightly smaller, due to the fact that we cannot
    predict the amount of free space precisely before we commit.
    
    This patch fixes the issue by skipping the debugging check in case of
    recovery. This issue was reported by Caizhiyong <caizhiyong@huawei.com>
    here: http://thread.gmane.org/gmane.linux.drivers.mtd/34350/focus=34387
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Reported-by: Caizhiyong <caizhiyong@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @nbd168 @gregkh

    ath9k_hw: partially revert "fix dma descriptor rx error bit parsing"

    nbd168 authored gregkh committed
    commit 115dad7 upstream.
    
    The rx error bit parsing was changed to consider PHY errors and various
    decryption errors separately. While correct according to the documentation,
    this is causing spurious decryption error reports in some situations.
    
    Fix this by restoring the original order of the checks in those places,
    where the errors are meant to be mutually exclusive.
    
    If a CRC error is reported, then MIC failure and decryption errors
    are irrelevant, and a PHY error is unlikely.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @gregkh

    ACPI battery: fribble sysfs files from a resume notifier

    Kyle McMartin authored gregkh committed
    commit 25be582 upstream.
    
    Commit da8aeb9 re-poked the battery on resume, but Linus reports that
    it broke his eee and partially reverted it in b23fffd. Unfortunately
    this also results in my x201s giving crack values until the sysfs files
    are poked again. In the revert message, it was suggested that we poke it
    from a PM notifier, so let's do that.
    
    With this in place, I haven't noticed the units going nutty on my
    gnome-power-manager across a dozen suspends or so...
    
    Signed-off-by: Kyle McMartin <kyle@redhat.com>
    Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @ikepanhc @gregkh

    ideapad: read brightness setting on brightness key notify

    ikepanhc authored gregkh committed
    commit 2165136 upstream.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=25922
    
    On ideapad Y530, the brightness key notify will be blocked if the last notify
    is not responsed by getting the brightness value. Read value when we get the
    notify shall fix the problem and will not have any difference on other ideapads.
    
    Signed-off-by: Ike Panhc <ike.pan@canonical.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @gregkh

    UBIFS: fix master node recovery

    Artem Bityutskiy authored gregkh committed
    commit 6e0d9fd upstream.
    
    This patch fixes the following symptoms:
    1. Unmount UBIFS cleanly.
    2. Start mounting UBIFS R/W and have a power cut immediately
    3. Start mounting UBIFS R/O, this succeeds
    4. Try to re-mount UBIFS R/W - this fails immediately or later on,
       because UBIFS will write the master node to the flash area
       which has been written before.
    
    The analysis of the problem:
    
    1. UBIFS is unmounted cleanly, both copies of the master node are clean.
    2. UBIFS is being mounter R/W, starts changing master node copy 1, and
       a power cut happens. The copy N1 becomes corrupted.
    3. UBIFS is being mounted R/O. It notices the copy N1 is corrupted and
       reads copy N2. Copy N2 is clean.
    4. Because of R/O mode, UBIFS cannot recover copy 1.
    5. The mount code (ubifs_mount()) sees that the master node is clean,
       so it decides that no recovery is needed.
    6. We are re-mounting R/W. UBIFS believes no recovery is needed and
       starts updating the master node, but copy N1 is still corrupted
       and was not recovered!
    
    Fix this problem by marking the master node as dirty every time we
    recover it and we are in R/O mode. This forces further recovery and
    the UBIFS cleans-up the corruptions and recovers the copy N1 when
    re-mounting R/W later.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.