Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Oct 25, 2011
  1. @gregkh

    Linux 3.0.8

    gregkh authored
  2. @gregkh

    hfsplus: Fix kfree of wrong pointers in hfsplus_fill_super() error path

    Seth Forshee authored gregkh committed
    commit f588c96 upstream.
    
    Commit 6596528 ("hfsplus: ensure bio requests are not smaller than
    the hardware sectors") changed the pointers used for volume header
    allocations but failed to free the correct pointers in the error path
    path of hfsplus_fill_super() and hfsplus_read_wrapper.
    
    The second hunk came from a separate patch by Pavel Ivanov.
    
    Reported-by: Pavel Ivanov <paivanof@gmail.com>
    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: Christoph Hellwig <hch@tuxera.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @tiwai @gregkh

    ALSA: hda - Add position_fix quirk for Dell Inspiron 1010

    tiwai authored gregkh committed
    commit 051a8cb upstream.
    
    The previous fix for the position-buffer check gives yet another
    regression on a Dell laptop.  The safest fix right now is to add a
    static quirk for this device (and better to apply it for stable
    kernels too).
    
    Reported-by: Éric Piel <Eric.Piel@tremplin-utc.net>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    ALSA: HDA: conexant support for Lenovo T520/W520

    Daniel Suchy authored gregkh committed
    commit ca201c0 upstream.
    
    This is patch for Conexant codec of Intel HDA driver, adding new quirk
    for Lenovo Thinkpad T520 and W520. Conexant autodetection works fine for
    T520 (similar subsystem ID is used also in W520 model) and detects more
    mixer features compared to generic (fallback) Lenovo quirk with
    hardcoded options in Conexant codec.
    
    Patch was activelly tested with Linux 3.0.4, 3.0.6 and 3.0.7 without any
    problems.
    
    Signed-off-by: Daniel Suchy <danny@danysek.cz>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    crypto: ghash - Avoid null pointer dereference if no key is set

    Nick Bowler authored gregkh committed
    commit 7ed47b7 upstream.
    
    The ghash_update function passes a pointer to gf128mul_4k_lle which will
    be NULL if ghash_setkey is not called or if the most recent call to
    ghash_setkey failed to allocate memory.  This causes an oops.  Fix this
    up by returning an error code in the null case.
    
    This is trivially triggered from unprivileged userspace through the
    AF_ALG interface by simply writing to the socket without setting a key.
    
    The ghash_final function has a similar issue, but triggering it requires
    a memory allocation failure in ghash_setkey _after_ at least one
    successful call to ghash_update.
    
      BUG: unable to handle kernel NULL pointer dereference at 00000670
      IP: [<d88c92d4>] gf128mul_4k_lle+0x23/0x60 [gf128mul]
      *pde = 00000000
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: ghash_generic gf128mul algif_hash af_alg nfs lockd nfs_acl sunrpc bridge ipv6 stp llc
    
      Pid: 1502, comm: hashatron Tainted: G        W   3.1.0-rc9-00085-ge9308cf #32 Bochs Bochs
      EIP: 0060:[<d88c92d4>] EFLAGS: 00000202 CPU: 0
      EIP is at gf128mul_4k_lle+0x23/0x60 [gf128mul]
      EAX: d69db1f0 EBX: d6b8ddac ECX: 00000004 EDX: 00000000
      ESI: 00000670 EDI: d6b8ddac EBP: d6b8ddc8 ESP: d6b8dda4
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process hashatron (pid: 1502, ti=d6b8c000 task=d6810000 task.ti=d6b8c000)
      Stack:
       00000000 d69db1f0 00000163 00000000 d6b8ddc8 c101a520 d69db1f0 d52aa000
       00000ff0 d6b8dde8 d88d310f d6b8a3f8 d52aa000 00001000 d88d502c d6b8ddfc
       00001000 d6b8ddf4 c11676ed d69db1e8 d6b8de24 c11679ad d52aa000 00000000
      Call Trace:
       [<c101a520>] ? kmap_atomic_prot+0x37/0xa6
       [<d88d310f>] ghash_update+0x85/0xbe [ghash_generic]
       [<c11676ed>] crypto_shash_update+0x18/0x1b
       [<c11679ad>] shash_ahash_update+0x22/0x36
       [<c11679cc>] shash_async_update+0xb/0xd
       [<d88ce0ba>] hash_sendpage+0xba/0xf2 [algif_hash]
       [<c121b24c>] kernel_sendpage+0x39/0x4e
       [<d88ce000>] ? 0xd88cdfff
       [<c121b298>] sock_sendpage+0x37/0x3e
       [<c121b261>] ? kernel_sendpage+0x4e/0x4e
       [<c10b4dbc>] pipe_to_sendpage+0x56/0x61
       [<c10b4e1f>] splice_from_pipe_feed+0x58/0xcd
       [<c10b4d66>] ? splice_from_pipe_begin+0x10/0x10
       [<c10b51f5>] __splice_from_pipe+0x36/0x55
       [<c10b4d66>] ? splice_from_pipe_begin+0x10/0x10
       [<c10b6383>] splice_from_pipe+0x51/0x64
       [<c10b63c2>] ? default_file_splice_write+0x2c/0x2c
       [<c10b63d5>] generic_splice_sendpage+0x13/0x15
       [<c10b4d66>] ? splice_from_pipe_begin+0x10/0x10
       [<c10b527f>] do_splice_from+0x5d/0x67
       [<c10b6865>] sys_splice+0x2bf/0x363
       [<c129373b>] ? sysenter_exit+0xf/0x16
       [<c104dc1e>] ? trace_hardirqs_on_caller+0x10e/0x13f
       [<c129370c>] sysenter_do_call+0x12/0x32
      Code: 83 c4 0c 5b 5e 5f c9 c3 55 b9 04 00 00 00 89 e5 57 8d 7d e4 56 53 8d 5d e4 83 ec 18 89 45 e0 89 55 dc 0f b6 70 0f c1 e6 04 01 d6 <f3> a5 be 0f 00 00 00 4e 89 d8 e8 48 ff ff ff 8b 45 e0 89 da 0f
      EIP: [<d88c92d4>] gf128mul_4k_lle+0x23/0x60 [gf128mul] SS:ESP 0068:d6b8dda4
      CR2: 0000000000000670
      ---[ end trace 4eaa2a86a8e2da24 ]---
      note: hashatron[1502] exited with preempt_count 1
      BUG: scheduling while atomic: hashatron/1502/0x10000002
      INFO: lockdep is turned off.
      [...]
    
    Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    x25: Prevent skb overreads when checking call user data

    Matthew Daley authored gregkh committed
    commit 7f81e25 upstream.
    
    x25_find_listener does not check that the amount of call user data given
    in the skb is big enough in per-socket comparisons, hence buffer
    overreads may occur.  Fix this by adding a check.
    
    Signed-off-by: Matthew Daley <mattjd@gmail.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Andrew Hendry <andrew.hendry@gmail.com>
    Acked-by: Andrew Hendry <andrew.hendry@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    mm: fix race between mremap and removing migration entry

    Hugh Dickins authored gregkh committed
    commit 486cf46 upstream.
    
    I don't usually pay much attention to the stale "? " addresses in
    stack backtraces, but this lucky report from Pawel Sikora hints that
    mremap's move_ptes() has inadequate locking against page migration.
    
     3.0 BUG_ON(!PageLocked(p)) in migration_entry_to_page():
     kernel BUG at include/linux/swapops.h:105!
     RIP: 0010:[<ffffffff81127b76>]  [<ffffffff81127b76>]
                           migration_entry_wait+0x156/0x160
      [<ffffffff811016a1>] handle_pte_fault+0xae1/0xaf0
      [<ffffffff810feee2>] ? __pte_alloc+0x42/0x120
      [<ffffffff8112c26b>] ? do_huge_pmd_anonymous_page+0xab/0x310
      [<ffffffff81102a31>] handle_mm_fault+0x181/0x310
      [<ffffffff81106097>] ? vma_adjust+0x537/0x570
      [<ffffffff81424bed>] do_page_fault+0x11d/0x4e0
      [<ffffffff81109a05>] ? do_mremap+0x2d5/0x570
      [<ffffffff81421d5f>] page_fault+0x1f/0x30
    
    mremap's down_write of mmap_sem, together with i_mmap_mutex or lock,
    and pagetable locks, were good enough before page migration (with its
    requirement that every migration entry be found) came in, and enough
    while migration always held mmap_sem; but not enough nowadays, when
    there's memory hotremove and compaction.
    
    The danger is that move_ptes() lets a migration entry dodge around
    behind remove_migration_pte()'s back, so it's in the old location when
    looking at the new, then in the new location when looking at the old.
    
    Either mremap's move_ptes() must additionally take anon_vma lock(), or
    migration's remove_migration_pte() must stop peeking for is_swap_entry()
    before it takes pagetable lock.
    
    Consensus chooses the latter: we prefer to add overhead to migration
    than to mremapping, which gets used by JVMs and by exec stack setup.
    
    Reported-and-tested-by: Paweł Sikora <pluto@agmk.net>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Andrea Arcangeli <aarcange@redhat.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    hwmon: (w83627ehf) Fix negative 8-bit temperature values

    Jean Delvare authored gregkh committed
    commit 133d324 upstream.
    
    Since 8-bit temperature values are now handled in 16-bit struct
    members, values have to be cast to s8 for negative temperatures to be
    properly handled. This is broken since kernel version 2.6.39
    (commit bce26c5.)
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Cc: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @tiwai @gregkh

    x86: Fix S4 regression

    tiwai authored gregkh committed
    commit 8548c84 upstream.
    
    Commit 4b239f4 ("x86-64, mm: Put early page table high") causes a S4
    regression since 2.6.39, namely the machine reboots occasionally at S4
    resume.  It doesn't happen always, overall rate is about 1/20.  But,
    like other bugs, once when this happens, it continues to happen.
    
    This patch fixes the problem by essentially reverting the memory
    assignment in the older way.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Cc: Yinghai Lu <yinghai.lu@oracle.com>
    [ We'll hopefully find the real fix, but that's too late for 3.1 now ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @bootc @gregkh

    firewire: sbp2: fix panic after rmmod with slow targets

    bootc authored gregkh committed
    commit 0278ccd upstream.
    
    If firewire-sbp2 starts a login to a target that doesn't complete ORBs
    in a timely manner (and has to retry the login), and the module is
    removed before the operation times out, you end up with a null-pointer
    dereference and a kernel panic.
    
    [SR:  This happens because sbp2_target_get/put() do not maintain
    module references.  scsi_device_get/put() do, but at occasions like
    Chris describes one, nobody holds a reference to an SBP-2 sdev.]
    
    This patch cancels pending work for each unit in sbp2_remove(), which
    hopefully means there are no extra references around that prevent us
    from unloading. This fixes my crash.
    
    Signed-off-by: Chris Boot <bootc@bootc.net>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    xfs: revert to using a kthread for AIL pushing

    Christoph Hellwig authored gregkh committed
    commit 0030807 upstream
    
    Currently we have a few issues with the way the workqueue code is used to
    implement AIL pushing:
    
     - it accidentally uses the same workqueue as the syncer action, and thus
       can be prevented from running if there are enough sync actions active
       in the system.
     - it doesn't use the HIGHPRI flag to queue at the head of the queue of
       work items
    
    At this point I'm not confident enough in getting all the workqueue flags and
    tweaks right to provide a perfectly reliable execution context for AIL
    pushing, which is the most important piece in XFS to make forward progress
    when the log fills.
    
    Revert back to use a kthread per filesystem which fixes all the above issues
    at the cost of having a task struct and stack around for each mounted
    filesystem.  In addition this also gives us much better ways to diagnose
    any issues involving hung AIL pushing and removes a small amount of code.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Stefan Priebe <s.priebe@profihost.ag>
    Tested-by: Stefan Priebe <s.priebe@profihost.ag>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    xfs: force the log if we encounter pinned buffers in .iop_pushbuf

    Christoph Hellwig authored gregkh committed
    commit 17b3847 upstream
    
    We need to check for pinned buffers even in .iop_pushbuf given that inode
    items flush into the same buffers that may be pinned directly due operations
    on the unlinked inode list operating directly on buffers.  To do this add a
    return value to .iop_pushbuf that tells the AIL push about this and use
    the existing log force mechanisms to unpin it.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Stefan Priebe <s.priebe@profihost.ag>
    Tested-by: Stefan Priebe <s.priebe@profihost.ag>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    xfs: do not update xa_last_pushed_lsn for locked items

    Christoph Hellwig authored gregkh committed
    commit bc6e588 upstream
    
    If an item was locked we should not update xa_last_pushed_lsn and thus skip
    it when restarting the AIL scan as we need to be able to lock and write it
    out as soon as possible.  Otherwise heavy lock contention might starve AIL
    pushing too easily, especially given the larger backoff once we moved
    xa_last_pushed_lsn all the way to the target lsn.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Stefan Priebe <s.priebe@profihost.ag>
    Tested-by: Stefan Priebe <s.priebe@profihost.ag>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    xfs: use a cursor for bulk AIL insertion

    Dave Chinner authored gregkh committed
    commit 1d8c95a upstream
    
    
    xfs: use a cursor for bulk AIL insertion
    
    Delayed logging can insert tens of thousands of log items into the
    AIL at the same LSN. When the committing of log commit records
    occur, we can get insertions occurring at an LSN that is not at the
    end of the AIL. If there are thousands of items in the AIL on the
    tail LSN, each insertion has to walk the AIL to find the correct
    place to insert the new item into the AIL. This can consume large
    amounts of CPU time and block other operations from occurring while
    the traversals are in progress.
    
    To avoid this repeated walk, use a AIL cursor to record
    where we should be inserting the new items into the AIL without
    having to repeat the walk. The cursor infrastructure already
    provides this functionality for push walks, so is a simple extension
    of existing code. While this will not avoid the initial walk, it
    will avoid repeating it tens of thousands of times during a single
    checkpoint commit.
    
    This version includes logic improvements from Christoph Hellwig.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    xfs: start periodic workers later

    Christoph Hellwig authored gregkh committed
    commit 2bcf6e9 upstream
    
    Start the periodic sync workers only after we have finished xfs_mountfs
    and thus fully set up the filesystem structures.  Without this we can
    call into xfs_qm_sync before the quotainfo strucute is set up if the
    mount takes unusually long, and probably hit other incomplete states
    as well.
    
    Also clean up the xfs_fs_fill_super error path by using consistent
    label names, and removing an impossible to reach case.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
    Reviewed-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @piastry @gregkh

    CIFS: Fix ERR_PTR dereference in cifs_get_root

    piastry authored gregkh committed
    commit 5b980b0 upstream.
    
    move it to the beginning of the loop.
    
    Signed-off-by: Pavel Shilovsky <piastryyy@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    drm/ttm: unbind ttm before destroying node in accel move cleanup

    Ben Skeggs authored gregkh committed
    commit eac2095 upstream.
    
    Nouveau makes the assumption that if a TTM is bound there will be a mm_node
    around for it and the backwards ordering here resulted in a use-after-free
    on some eviction paths.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    drm/ttm: ensure ttm for new node is bound before calling move_notify()

    Ben Skeggs authored gregkh committed
    commit 8d3bb23 upstream.
    
    This was true for new TTM_PL_SYSTEM and new TTM_PL_TT cases, but wasn't
    the case on TTM_PL_SYSTEM<->TTM_PL_TT moves, which causes trouble on some
    paths as nouveau's move_notify() hook requires that the dma addresses be
    valid at this point.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    hfsplus: ensure bio requests are not smaller than the hardware sectors

    Seth Forshee authored gregkh committed
    commit 6596528 upstream.
    
    Currently all bio requests are 512 bytes, which may fail for media
    whose physical sector size is larger than this. Ensure these
    requests are not smaller than the block device logical block size.
    
    BugLink: http://bugs.launchpad.net/bugs/734883
    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @pinchartl @gregkh

    uvcvideo: Fix crash when linking entities

    pinchartl authored gregkh committed
    commit 4d9b2eb upstream.
    
    The uvc_mc_register_entity() function wrongfully selects the
    media_entity associated with a UVC entity when creating links. This
    results in access to uninitialized media_entity structures and can hit a
    BUG_ON statement in media_entity_create_link(). Fix it.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    HID: magicmouse: ignore 'ivalid report id' while switching modes, v2

    Jiri Kosina authored gregkh committed
    commit 35d851d upstream.
    
    This is basically a more generic respin of 23746a6 ("HID: magicmouse: ignore
    'ivalid report id' while switching modes") which got reverted later by
    c3a492.
    
    It turns out that on some configurations, this is actually still the case
    and we are not able to detect in runtime.
    
    The device reponds with 'invalid report id' when feature report switching it
    into multitouch mode is sent to it.
    
    This has been silently ignored before 0825411 ("HID: bt: Wait for ACK
    on Sent Reports"), but since this commit, it propagates -EIO from the _raw
    callback .
    
    So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's
    how the device reacts in normal mode.
    
    Sad, but following reality.
    
    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022
    
    Reported-by: Chase Douglas <chase.douglas@canonical.com>
    Reported-by: Jaikumar Ganesh <jaikumarg@android.com>
    Tested-by: Chase Douglas <chase.douglas@canonical.com>
    Tested-by: Jaikumar Ganesh <jaikumarg@android.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @tcourbon @gregkh

    Platform: fix samsung-laptop DMI identification for N150/N210/220/N230

    tcourbon authored gregkh committed
    commit 78a7539 upstream.
    
    Some samsung latop of the N150/N2{10,20,30} serie are badly detected by the samsung-laptop platform driver, see bug # 36082.
    It appears that N230 identifies itself as N150/N210/N220/N230 whereas the other identify themselves as N150/N210/220.
    This patch attemtp fix #36082 allowing correct identification for all the said netbook model.
    
    Reported-by: Daniel Eklöf <daniel@ekloef.se>
    Signed-off-by: Thomas Courbon <thcourbon@gmail.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    fuse: fix memory leak

    Miklos Szeredi authored gregkh committed
    commit 5dfcc87 upstream.
    
    kmemleak is reporting that 32 bytes are being leaked by FUSE:
    
      unreferenced object 0xe373b270 (size 32):
      comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s)
      hex dump (first 32 bytes):
        01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<b05517d7>] kmemleak_alloc+0x27/0x50
        [<b0196435>] kmem_cache_alloc+0xc5/0x180
        [<b02455be>] fuse_alloc_forget+0x1e/0x20
        [<b0245670>] fuse_alloc_inode+0xb0/0xd0
        [<b01b1a8c>] alloc_inode+0x1c/0x80
        [<b01b290f>] iget5_locked+0x8f/0x1a0
        [<b0246022>] fuse_iget+0x72/0x1a0
        [<b02461da>] fuse_get_root_inode+0x8a/0x90
        [<b02465cf>] fuse_fill_super+0x3ef/0x590
        [<b019e56f>] mount_nodev+0x3f/0x90
        [<b0244e95>] fuse_mount+0x15/0x20
        [<b019d1bc>] mount_fs+0x1c/0xc0
        [<b01b5811>] vfs_kern_mount+0x41/0x90
        [<b01b5af9>] do_kern_mount+0x39/0xd0
        [<b01b7585>] do_mount+0x2e5/0x660
        [<b01b7966>] sys_mount+0x66/0xa0
    
    This leak report is consistent and happens once per boot on
    3.1.0-rc5-dirty.
    
    This happens if a FORGET request is queued after the fuse device was
    released.
    
    Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    cputimer: Cure lock inversion

    Peter Zijlstra authored gregkh committed
    commit bcd5cff upstream.
    
    There's a lock inversion between the cputimer->lock and rq->lock;
    notably the two callchains involved are:
    
     update_rlimit_cpu()
       sighand->siglock
       set_process_cpu_timer()
         cpu_timer_sample_group()
           thread_group_cputimer()
             cputimer->lock
             thread_group_cputime()
               task_sched_runtime()
                 ->pi_lock
                 rq->lock
    
     scheduler_tick()
       rq->lock
       task_tick_fair()
         update_curr()
           account_group_exec()
             cputimer->lock
    
    Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and
    the second one is keeping up-to-date.
    
    This problem was introduced by e8abccb ("posix-cpu-timers: Cure
    SMP accounting oddities").
    
    Cure the problem by removing the cputimer->lock and rq->lock nesting,
    this leaves concurrent enablers doing duplicate work, but the time
    wasted should be on the same order otherwise wasted spinning on the
    lock and the greater-than assignment filter should ensure we preserve
    monotonicity.
    
    Reported-by: Dave Jones <davej@redhat.com>
    Reported-by: Simon Kirby <sim@hostway.ca>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Link: http://lkml.kernel.org/r/1318928713.21167.4.camel@twins
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    drm/radeon/kms/atom: fix handling of FB scratch indices

    Alex Deucher authored gregkh committed
    commit 5a6e848 upstream.
    
    FB scratch indices are dword indices, but we were treating
    them as byte indices.  As such, we were getting the wrong
    FB scratch data for non-0 indices.  Fix the indices and
    guard the indexing against indices larger than the scratch
    allocation.
    
    Fixes memory corruption on some boards if data was written
    past the end of the FB scratch array.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reported-by: Dave Airlie <airlied@redhat.com>
    Tested-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @torvalds @gregkh

    Avoid using variable-length arrays in kernel/sys.c

    torvalds authored gregkh committed
    commit a84a79e upstream.
    
    The size is always valid, but variable-length arrays generate worse code
    for no good reason (unless the function happens to be inlined and the
    compiler sees the length for the simple constant it is).
    
    Also, there seems to be some code generation problem on POWER, where
    Henrik Bakken reports that register r28 can get corrupted under some
    subtle circumstances (interrupt happening at the wrong time?).  That all
    indicates some seriously broken compiler issues, but since variable
    length arrays are bad regardless, there's little point in trying to
    chase it down.
    
    "Just don't do that, then".
    
    Reported-by: Henrik Grindal Bakken <henribak@cisco.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    hwmon: (w83627ehf) Properly report thermal diode sensors

    Jean Delvare authored gregkh committed
    commit bf164c5 upstream.
    
    The w83627ehf driver is improperly reporting thermal diode sensors as
    type 2, instead of 3. This caused "sensors" and possibly other
    monitoring tools to report these sensors as "transistor" instead of
    "thermal diode".
    
    Furthermore, diode subtype selection (CPU vs. external) is only
    supported by the original W83627EHF/EHG. All later models only support
    CPU diode type, and some (NCT6776F) don't even have the register in
    question so we should avoid reading from it.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @sprg @gregkh

    HID: usbhid: Add support for SiGma Micro chip

    sprg authored gregkh committed
    commit f5e4282 upstream.
    
    Patch to add SiGma Micro-based keyboards (1c4f:0002) to hid-quirks.
    
    These keyboards dont seem to allow the records to be initialized, and hence a
    timeout occurs when the usbhid driver attempts to initialize them. The patch
    just adds the signature for these keyboards to the hid-quirks list with the
    setting HID_QUIRK_NO_INIT_REPORTS. This removes the 5-10 second wait for the
    timeout to occur.
    
    Signed-off-by: Jeremiah Matthey <sprg86@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @wildea01 @gregkh

    ARM: 7117/1: perf: fix HW_CACHE_* events on Cortex-A9

    wildea01 authored gregkh committed
    commit 29a541f upstream.
    
    Using COHERENT_LINE_{MISS,HIT} for cache misses and references
    respectively is completely wrong. Instead, use the L1D events which
    are a better and more useful approximation despite ignoring instruction
    traffic.
    
    Reported-by: Alasdair Grant <alasdair.grant@arm.com>
    Reported-by: Matt Horsnell <matt.horsnell@arm.com>
    Reported-by: Michael Williams <michael.williams@arm.com>
    Cc: Jean Pihet <j-pihet@ti.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @linusw @gregkh

    ARM: 7113/1: mm: Align bank start to MAX_ORDER_NR_PAGES

    linusw authored gregkh committed
    commit 002ea9e upstream.
    
    The VM subsystem assumes that there are valid memmap entries from
    the bank start aligned to MAX_ORDER_NR_PAGES.
    
    On the Ux500 we have a lot of mem=N arguments on the commandline
    triggering this bug several times over and causing kernel
    oops messages.
    
    Cc: Michael Bohan <mbohan@codeaurora.org>
    Cc: Nicolas Pitre <nico@fluxnic.net>
    Signed-off-by: Johan Palsson <johan.palsson@stericsson.com>
    Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on Oct 16, 2011
  1. @gregkh

    Linux 3.0.7

    gregkh authored
  2. @gregkh

    e1000e: workaround for packet drop on 82579 at 100Mbps

    Bruce Allan authored gregkh committed
    commit 0ed013e upstream.
    
    The MAC can drop short packets when the PHY detects noise on the line at
    100Mbps due to a timing issue.  Workaround the issue by increasing the PLL
    counter so the PHY properly recognizes the synchronization pattern from the
    MAC.
    
    Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
    Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Cc: Leann Ogasawara <leann.ogasawara@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    ftrace: Fix warning when CONFIG_FUNCTION_TRACER is not defined

    Steven Rostedt authored gregkh committed
    commit 04da85b upstream.
    
    The struct ftrace_hash was declared within CONFIG_FUNCTION_TRACER
    but was referenced outside of it.
    
    Reported-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
  4. @gregkh

    ftrace: Fix regression where ftrace breaks when modules are loaded

    Steven Rostedt authored gregkh committed
    commit f7bc8b6 upstream.
    
    Enabling function tracer to trace all functions, then load a module and
    then disable function tracing will cause ftrace to fail.
    
    This can also happen by enabling function tracing on the command line:
    
      ftrace=function
    
    and during boot up, modules are loaded, then you disable function tracing
    with 'echo nop > current_tracer' you will trigger a bug in ftrace that
    will shut itself down.
    
    The reason is, the new ftrace code keeps ref counts of all ftrace_ops that
    are registered for tracing. When one or more ftrace_ops are registered,
    all the records that represent the functions that the ftrace_ops will
    trace have a ref count incremented. If this ref count is not zero,
    when the code modification runs, that function will be enabled for tracing.
    If the ref count is zero, that function will be disabled from tracing.
    
    To make sure the accounting was working, FTRACE_WARN_ON()s were added
    to updating of the ref counts.
    
    If the ref count hits its max (> 2^30 ftrace_ops added), or if
    the ref count goes below zero, a FTRACE_WARN_ON() is triggered which
    disables all modification of code.
    
    Since it is common for ftrace_ops to trace all functions in the kernel,
    instead of creating > 20,000 hash items for the ftrace_ops, the hash
    count is just set to zero, and it represents that the ftrace_ops is
    to trace all functions. This is where the issues arrise.
    
    If you enable function tracing to trace all functions, and then add
    a module, the modules function records do not get the ref count updated.
    When the function tracer is disabled, all function records ref counts
    are subtracted. Since the modules never had their ref counts incremented,
    they go below zero and the FTRACE_WARN_ON() is triggered.
    
    The solution to this is rather simple. When modules are loaded, and
    their functions are added to the the ftrace pool, look to see if any
    ftrace_ops are registered that trace all functions. And for those,
    update the ref count for the module function records.
    
    Reported-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
  5. @gregkh

    ftrace: Fix regression of :mod:module function enabling

    Steven Rostedt authored gregkh committed
    commit 43dd61c upstream.
    
    The new code that allows different utilities to pick and choose
    what functions they trace broke the :mod: hook that allows users
    to trace only functions of a particular module.
    
    The reason is that the :mod: hook bypasses the hash that is setup
    to allow individual users to trace their own functions and uses
    the global hash directly. But if the global hash has not been
    set up, it will cause a bug:
    
    echo '*:mod:radeon' > /sys/kernel/debug/set_ftrace_filter
    
    produces:
    
     [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
     [drm:radeon_crtc_page_flip] *ERROR* failed to reserve new rbo buffer before flip
     BUG: unable to handle kernel paging request at ffffffff8160ec90
     IP: [<ffffffff810d9136>] add_hash_entry+0x66/0xd0
     PGD 1a05067 PUD 1a09063 PMD 80000000016001e1
     Oops: 0003 [#1] SMP Jul  7 04:02:28 phyllis kernel: [55303.858604] CPU 1
     Modules linked in: cryptd aes_x86_64 aes_generic binfmt_misc rfcomm bnep ip6table_filter hid radeon r8169 ahci libahci mii ttm drm_kms_helper drm video i2c_algo_bit intel_agp intel_gtt
    
     Pid: 10344, comm: bash Tainted: G        WC  3.0.0-rc5 #1 Dell Inc. Inspiron N5010/0YXXJJ
     RIP: 0010:[<ffffffff810d9136>]  [<ffffffff810d9136>] add_hash_entry+0x66/0xd0
     RSP: 0018:ffff88003a96bda8  EFLAGS: 00010246
     RAX: ffff8801301735c0 RBX: ffffffff8160ec80 RCX: 0000000000306ee0
     RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880137c92940
     RBP: ffff88003a96bdb8 R08: ffff880137c95680 R09: 0000000000000000
     R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff81c9df78
     R13: ffff8801153d1000 R14: 0000000000000000 R15: 0000000000000000
     FS: 00007f329c18a700(0000) GS:ffff880137c80000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: ffffffff8160ec90 CR3: 000000003002b000 CR4: 00000000000006e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
     Process bash (pid: 10344, threadinfo ffff88003a96a000, task ffff88012fcfc470)
     Stack:
      0000000000000fd0 00000000000000fc ffff88003a96be38 ffffffff810d92f5
      ffff88011c4c4e00 ffff880000000000 000000000b69f4d0 ffffffff8160ec80
      ffff8800300e6f06 0000000081130295 0000000000000282 ffff8800300e6f00
     Call Trace:
      [<ffffffff810d92f5>] match_records+0x155/0x1b0
      [<ffffffff810d940c>] ftrace_mod_callback+0xbc/0x100
      [<ffffffff810dafdf>] ftrace_regex_write+0x16f/0x210
      [<ffffffff810db09f>] ftrace_filter_write+0xf/0x20
      [<ffffffff81166e48>] vfs_write+0xc8/0x190
      [<ffffffff81167001>] sys_write+0x51/0x90
      [<ffffffff815c7e02>] system_call_fastpath+0x16/0x1b
     Code: 48 8b 33 31 d2 48 85 f6 75 33 49 89 d4 4c 03 63 08 49 8b 14 24 48 85 d2 48 89 10 74 04 48 89 42 08 49 89 04 24 4c 89 60 08 31 d2
     RIP [<ffffffff810d9136>] add_hash_entry+0x66/0xd0
      RSP <ffff88003a96bda8>
     CR2: ffffffff8160ec90
     ---[ end trace a5d031828efdd88e ]---
    
    Reported-by: Brian Marete <marete@toshnix.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.