Permalink
Commits on Jun 23, 2011
  1. Linux 2.6.33.15

    gregkh committed Jun 23, 2011
  2. Revert "iwlagn: Support new 5000 microcode."

    This reverts commit 6f63415.
    
    It turns out this is not what we want to have happen for the .32 and
    .33-longterm kernels as it does not work properly at all.
    
    This was reported by Gentoo, Arch, and Canonical developers as causing
    problems for their users:
    	https://bugs.archlinux.org/task/24302
    	http://bugs.gentoo.org/show_bug.cgi?id=359445
    	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
    
    Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Cc: Gordon Malm <gengor@gentoo.org>
    Cc: Don Fry <donald.h.fry@intel.com>
    Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Cc: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    gregkh committed Jun 15, 2011
  3. netfilter: IPv6: fix DSCP mangle code

    commit 1ed2f73 upstream.
    
    The mask indicates the bits one wants to zero out, so it needs to be
    inverted before applying to the original TOS field.
    
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Fernando Luis Vazquez Cao committed with gregkh May 10, 2011
  4. netfilter: IPv6: initialize TOS field in REJECT target module

    commit 4319cc0 upstream.
    
    The IPv6 header is not zeroed out in alloc_skb so we must initialize
    it properly unless we want to see IPv6 packets with random TOS fields
    floating around. The current implementation resets the flow label
    but this could be changed if deemed necessary.
    
    We stumbled upon this issue when trying to apply a mangle rule to
    the RST packet generated by the REJECT target module.
    
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Fernando Luis Vazquez Cao committed with gregkh May 10, 2011
  5. xfs: properly account for reclaimed inodes

    commit 081003f upstream.
    
    When marking an inode reclaimable, a per-AG counter is increased, the
    inode is tagged reclaimable in its per-AG tree, and, when this is the
    first reclaimable inode in the AG, the AG entry in the per-mount tree
    is also tagged.
    
    When an inode is finally reclaimed, however, it is only deleted from
    the per-AG tree.  Neither the counter is decreased, nor is the parent
    tree's AG entry untagged properly.
    
    Since the tags in the per-mount tree are not cleared, the inode
    shrinker iterates over all AGs that have had reclaimable inodes at one
    point in time.
    
    The counters on the other hand signal an increasing amount of slab
    objects to reclaim.  Since "70e60ce xfs: convert inode shrinker to
    per-filesystem context" this is not a real issue anymore because the
    shrinker bails out after one iteration.
    
    But the problem was observable on a machine running v2.6.34, where the
    reclaimable work increased and each process going into direct reclaim
    eventually got stuck on the xfs inode shrinking path, trying to scan
    several million objects.
    
    Fix this by properly unwinding the reclaimable-state tracking of an
    inode when it is reclaimed.
    
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Backported-by: Stefan Priebe <s.priebe@profihost.ag>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    hnaz committed with gregkh Oct 1, 2010
  6. pata_cm64x: fix boot crash on parisc

    commit 9281b16 upstream.
    
    The old IDE cmd64x checks the status of the CNTRL register to see if
    the ports are enabled before probing them.  pata_cmd64x doesn't do
    this, which causes a HPMC on parisc when it tries to poke at the
    secondary port because apparently the BAR isn't wired up (and a
    non-responding piece of memory causes a HPMC).
    
    Fix this by porting the CNTRL register port detection logic from IDE
    cmd64x.  In addition, following converns from Alan Cox, add a check to
    see if a mobility electronics bridge is the immediate parent and forgo
    the check if it is (prevents problems on hotplug controllers).
    
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    James Bottomley committed with gregkh Apr 24, 2011
  7. pata_cmd64x: remove unused definitions

    commit c754d9b upstream.
    
    s/ARTIM2/ARTTIM23/ in cmd648_bmdma_stop() while at it
    
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    bzolnier committed with gregkh Jan 18, 2010
  8. pata_cmd64x: cmd648_bmdma_stop() fix

    commit 03a849e upstream.
    
    Clear the primary channel pending interrupt bit
    instead of the reserved one.
    
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    bzolnier committed with gregkh Jan 18, 2010
  9. pata_cmd64x: fix PIO setup

    commit a2bd622 upstream.
    
    Fix incorrect handling of recovery clocks value == 16 resulting
    in overclocked recovery timings & potentially underclocked active
    timings.
    
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    bzolnier committed with gregkh Jan 18, 2010
  10. md/raid5: fix raid5_set_bi_hw_segments

    commit 9b2dc8b upstream.
    
    The @bio->bi_phys_segments consists of active stripes count in the
    lower 16 bits and processed stripes count in the upper 16 bits. So
    logical-OR operator should be bitwise one.
    
    This bug has been present since 2.6.27 and the fix is suitable for any
    -stable kernel since then.  Fortunately the bad code is only used on
    error paths and is relatively unlikely to be hit.
    
    Signed-off-by: Namhyung Kim <namhyung@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    namhyung committed with gregkh Jun 13, 2011
  11. md: check ->hot_remove_disk when removing disk

    commit 01393f3 upstream.
    
    Check pers->hot_remove_disk instead of pers->hot_add_disk in slot_store()
    during disk removal. The linear personality only has ->hot_add_disk and
    no ->hot_remove_disk, so that removing disk in the array resulted to
    following kernel bug:
    
    $ sudo mdadm --create /dev/md0 --level=linear --raid-devices=4 /dev/loop[0-3]
    $ echo none | sudo tee /sys/block/md0/md/dev-loop2/slot
     BUG: unable to handle kernel NULL pointer dereference at           (null)
     IP: [<          (null)>]           (null)
     PGD c9f5d067 PUD 8575a067 PMD 0
     Oops: 0010 [#1] SMP
     CPU 2
     Modules linked in: linear loop bridge stp llc kvm_intel kvm asus_atk0110 sr_mod cdrom sg
    
     Pid: 10450, comm: tee Not tainted 3.0.0-rc1-leonard+ #173 System manufacturer System Product Name/P5G41TD-M PRO
     RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
     RSP: 0018:ffff880085757df0  EFLAGS: 00010282
     RAX: ffffffffa00168e0 RBX: ffff8800d1431800 RCX: 000000000000006e
     RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff88008543c000
     RBP: ffff880085757e48 R08: 0000000000000002 R09: 000000000000000a
     R10: 0000000000000000 R11: ffff88008543c2e0 R12: 00000000ffffffff
     R13: ffff8800b4641000 R14: 0000000000000005 R15: 0000000000000000
     FS:  00007fe8c9e05700(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
     CR2: 0000000000000000 CR3: 00000000b4502000 CR4: 00000000000406e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
     Process tee (pid: 10450, threadinfo ffff880085756000, task ffff8800c9f08000)
     Stack:
      ffffffff8138496a ffff8800b4641000 ffff88008543c268 0000000000000000
      ffff8800b4641000 ffff88008543c000 ffff8800d1431868 ffffffff81a78a90
      ffff8800b4641000 ffff88008543c000 ffff8800d1431800 ffff880085757e98
     Call Trace:
      [<ffffffff8138496a>] ? slot_store+0xaa/0x265
      [<ffffffff81384bae>] rdev_attr_store+0x89/0xa8
      [<ffffffff8115a96a>] sysfs_write_file+0x108/0x144
      [<ffffffff81106b87>] vfs_write+0xb1/0x10d
      [<ffffffff8106e6c0>] ? trace_hardirqs_on_caller+0x111/0x135
      [<ffffffff81106cac>] sys_write+0x4d/0x77
      [<ffffffff814fe702>] system_call_fastpath+0x16/0x1b
     Code:  Bad RIP value.
     RIP  [<          (null)>]           (null)
      RSP <ffff880085757df0>
     CR2: 0000000000000000
     ---[ end trace ba5fc64319a826fb ]---
    
    Signed-off-by: Namhyung Kim <namhyung@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    namhyung committed with gregkh Jun 9, 2011
  12. CPUFREQ: Remove cpufreq_stats sysfs entries on module unload.

    commit 13f0675 upstream.
    
    cpufreq_stats leaves behind its sysfs entries, which causes a panic
    when something stumbled across them.
    (Discovered by unloading cpufreq_stats while powertop was loaded).
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    kernelslacker committed with gregkh Jun 12, 2011
  13. oprofile, dcookies: Fix possible circular locking dependency

    commit fe47ae7 upstream.
    
    The lockdep warning below detects a possible A->B/B->A locking
    dependency of mm->mmap_sem and dcookie_mutex. The order in
    sync_buffer() is mm->mmap_sem/dcookie_mutex, while in
    sys_lookup_dcookie() it is vice versa.
    
    Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before
    copy_to_user().
    
    oprofiled/4432 is trying to acquire lock:
     (&mm->mmap_sem){++++++}, at: [<ffffffff810b444b>] might_fault+0x53/0xa3
    
    but task is already holding lock:
     (dcookie_mutex){+.+.+.}, at: [<ffffffff81124d28>] sys_lookup_dcookie+0x45/0x149
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (dcookie_mutex){+.+.+.}:
           [<ffffffff8106557f>] lock_acquire+0xf8/0x11e
           [<ffffffff814634f0>] mutex_lock_nested+0x63/0x309
           [<ffffffff81124e5c>] get_dcookie+0x30/0x144
           [<ffffffffa0000fba>] sync_buffer+0x196/0x3ec [oprofile]
           [<ffffffffa0001226>] task_exit_notify+0x16/0x1a [oprofile]
           [<ffffffff81467b96>] notifier_call_chain+0x37/0x63
           [<ffffffff8105803d>] __blocking_notifier_call_chain+0x50/0x67
           [<ffffffff81058068>] blocking_notifier_call_chain+0x14/0x16
           [<ffffffff8105a718>] profile_task_exit+0x1a/0x1c
           [<ffffffff81039e8f>] do_exit+0x2a/0x6fc
           [<ffffffff8103a5e4>] do_group_exit+0x83/0xae
           [<ffffffff8103a626>] sys_exit_group+0x17/0x1b
           [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b
    
    -> #0 (&mm->mmap_sem){++++++}:
           [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711
           [<ffffffff8106557f>] lock_acquire+0xf8/0x11e
           [<ffffffff810b4478>] might_fault+0x80/0xa3
           [<ffffffff81124de7>] sys_lookup_dcookie+0x104/0x149
           [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b
    
    other info that might help us debug this:
    
    1 lock held by oprofiled/4432:
     #0:  (dcookie_mutex){+.+.+.}, at: [<ffffffff81124d28>] sys_lookup_dcookie+0x45/0x149
    
    stack backtrace:
    Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9
    Call Trace:
     [<ffffffff81063193>] print_circular_bug+0xae/0xbc
     [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711
     [<ffffffff8102ef13>] ? get_parent_ip+0x11/0x42
     [<ffffffff810b444b>] ? might_fault+0x53/0xa3
     [<ffffffff8106557f>] lock_acquire+0xf8/0x11e
     [<ffffffff810b444b>] ? might_fault+0x53/0xa3
     [<ffffffff810d7d54>] ? path_put+0x22/0x27
     [<ffffffff810b4478>] might_fault+0x80/0xa3
     [<ffffffff810b444b>] ? might_fault+0x53/0xa3
     [<ffffffff81124de7>] sys_lookup_dcookie+0x104/0x149
     [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=13809
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Robert Richter committed with gregkh May 31, 2011
  14. ALSA: hda: Fix quirk for Dell Inspiron 910

    commit 0a1896b upstream.
    
    BugLink: https://launchpad.net/bugs/792712
    
    The original reporter states that sound from the internal speakers is
    inaudible until using the model=auto quirk. This symptom is due to an
    existing quirk mask for 0x102802b* that uses the model=dell quirk. To
    limit the possible regressions, leave the existing quirk mask but add
    a higher priority specific mask for the reporter's PCI SSID.
    
    Reported-and-tested-by: rodni hipp
    Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    crimsun committed with gregkh Jun 6, 2011
  15. USB: xhci - fix interval calculation for FS isoc endpoints

    commit cd3c18b upstream.
    
    Full-speed isoc endpoints specify interval in exponent based form in
    frames, not microframes, so we need to adjust accordingly.
    
    NEC xHCI host controllers will return an error code of 0x11 if a full
    speed isochronous endpoint is added with the Interval field set to
    something less than 3 (2^3 = 8 microframes, or one frame).  It is
    impossible for a full speed device to have an interval smaller than one
    frame.
    
    This was always an issue in the xHCI driver, but commit
    dfa49c4 "USB: xhci - fix math in
    xhci_get_endpoint_interval()" removed the clamping of the minimum value
    in the Interval field, which revealed this bug.
    
    This needs to be backported to stable kernels back to 2.6.31.
    
    Reported-by: Matt Evans <matt@ozlabs.org>
    Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Dmitry Torokhov committed with gregkh May 31, 2011
  16. USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driver

    commit a26d31c upstream.
    
    E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2.
    
    Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    sledz committed with gregkh Jun 7, 2011
  17. USB: core: Tolerate protocol stall during hub and port status read

    commit 3824c1d upstream.
    
    Protocol stall should not be fatal while reading port or hub status as it is
    transient state.  Currently hub EP0 STALL during port status read results in
    failed device enumeration.  This has been observed with ST-Ericsson (formerly
    Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard.
    
    Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    lpechacek committed with gregkh May 20, 2011
  18. x86/amd-iommu: Fix boot crash with hidden PCI devices

    commit 2601887 upstream.
    
    Some PCIe cards ship with a PCI-PCIe bridge which is not
    visible as a PCI device in Linux. But the device-id of the
    bridge is present in the IOMMU tables which causes a boot
    crash in the IOMMU driver.
    This patch fixes by removing these cards from the IOMMU
    handling. This is a pure -stable fix, a real fix to handle
    this situation appriatly will follow for the next merge
    window.
    
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Joerg Roedel committed with gregkh Jun 6, 2011
  19. x86/amd-iommu: Fix 3 possible endless loops

    commit 0de66d5 upstream.
    
    The driver contains several loops counting on an u16 value
    where the exit-condition is checked against variables that
    can have values up to 0xffff. In this case the loops will
    never exit. This patch fixed 3 such loops.
    
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Joerg Roedel committed with gregkh Jun 6, 2011
  20. x86/amd-iommu: Use only per-device dma_ops

    commit 27c2127 upstream.
    
    Unfortunatly there are systems where the AMD IOMMU does not
    cover all devices. This breaks with the current driver as it
    initializes the global dma_ops variable. This patch limits
    the AMD IOMMU to the devices listed in the IVRS table fixing
    DMA for devices not covered by the IOMMU.
    
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Joerg Roedel committed with gregkh May 30, 2011
  21. xen: off by one errors in multicalls.c

    commit f124c6a upstream.
    
    b->args[] has MC_ARGS elements, so the comparison here should be
    ">=" instead of ">".  Otherwise we read past the end of the array
    one space.
    
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    error27 committed with gregkh Jun 3, 2011
  22. fat: Fix corrupt inode flags when remove ATTR_SYS flag

    commit 1adffba upstream.
    
    We are clearly missing '~' in fat_ioctl_set_attributes().
    
    Reported-by: Dmitry Dmitriev <dimondmm@yandex.ru>
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    OGAWAHirofumi committed with gregkh May 31, 2011
  23. drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu

    commit 62fff81 upstream.
    
    On my x86_64 system with >4GB of ram and swiotlb instead of
    a hardware iommu (because I have a VIA chipset), the call
    to pci_set_dma_mask (see below) with 40bits returns an error.
    
    But it seems that the radeon driver is designed to have
    need_dma32 = true exactly if pci_set_dma_mask is called
    with 32 bits and false if it is called with 40 bits.
    
    I have read somewhere that the default are 32 bits. So if the
    call fails I suppose that need_dma32 should be set to true.
    
    And indeed the patch fixes the problem I have had before
    and which I had described here:
    http://choon.net/forum/read.php?21,106131,115940
    
    Acked-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Daniel Haid committed with gregkh Jun 8, 2011
  24. drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007

    commit 6a574b5 upstream.
    
    I found this while figuring out why gnome-shell would not run on my
    Asus EeeBox PC EB1007. As a standalone "pc" this device cleary does not have
    an internal panel, yet it claims it does. Add a quirk to fix this.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jwrdegoede committed with gregkh Jun 4, 2011
  25. lockdep: Fix lock_is_held() on recursion

    commit f2513cd upstream.
    
    The main lock_is_held() user is lockdep_assert_held(), avoid false
    assertions in lockdep_off() sections by unconditionally reporting the
    lock is taken.
    
    [ the reason this is important is a lockdep_assert_held() in ttwu()
      which triggers a warning under lockdep_off() as in printk() which
      can trigger another wakeup and lock up due to spinlock
      recursion, as reported and heroically debugged by Arne Jansen ]
    
    Reported-and-tested-by: Arne Jansen <lists@die-jansens.de>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1307398759.2497.966.camel@laptop
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Peter Zijlstra committed with gregkh Jun 6, 2011
  26. nl80211: fix check for valid SSID size in scan operations

    commit 208c72f upstream.
    
    In both trigger_scan and sched_scan operations, we were checking for
    the SSID length before assigning the value correctly.  Since the
    memory was just kzalloc'ed, the check was always failing and SSID with
    over 32 characters were allowed to go through.
    
    This was causing a buffer overflow when copying the actual SSID to the
    proper place.
    
    This bug has been there since 2.6.29-rc4.
    
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Luciano Coelho committed with gregkh May 18, 2011
  27. PCI: Set PCIE maxpayload for card during hotplug insertion

    commit e522a71 upstream.
    
    The following patch sets the MaxPayload setting to match the parent
    reading when inserting a PCIE card into a hotplug slot.  On our system,
    the upstream bridge is set to 256, but when inserting a card, the card
    setting defaults to 128.  As soon as I/O is performed to the card it
    starts receiving errors since the payload size is too small.
    
    Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
    Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jharg committed with gregkh May 9, 2011
  28. mm: fix ENOSPC returned by handle_mm_fault()

    commit e0dcd8a upstream.
    
    Al Viro observes that in the hugetlb case, handle_mm_fault() may return
    a value of the kind ENOSPC when its caller is expecting a value of the
    kind VM_FAULT_SIGBUS: fix alloc_huge_page()'s failure returns.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Hugh Dickins committed with gregkh Jun 6, 2011
  29. ath9k: set 40 Mhz rate only if hw is configured in ht40

    commit 41e2b05 upstream.
    
    Whenever there is a channel width change from 40 Mhz to 20 Mhz,
    the hardware is reconfigured to ht20. Meantime before doing
    the rate control updation, the packets are being transmitted are
    selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH.
    
    While transmitting ht40 rate packets in ht20 mode is causing
    baseband panic with AR9003 based chips.
    
    ==== BB update: BB status=0x02001109 ====
    ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2
    src=0 **
    ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 **
    ath: ** BB mode: BB_gen_controls=0x000033c0 **
    ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% **
    ath: ==== BB update: done ====
    
    Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Rajkumar Manoharan committed with gregkh May 20, 2011
  30. Fix oops caused by queue refcounting failure

    commit e73e079 upstream.
    
    In certain circumstances, we can get an oops from a torn down device.
    Most notably this is from CD roms trying to call scsi_ioctl.  The root
    cause of the problem is the fact that after scsi_remove_device() has
    been called, the queue is fully torn down.  This is actually wrong
    since the queue can be used until the sdev release function is called.
    Therefore, we add an extra reference to the queue which is released in
    sdev->release, so the queue always exists.
    
    Reported-by: Parag Warudkar <parag.lkml@gmail.com>
    Signed-off-by: James Bottomley <jbottomley@parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    James Bottomley committed with gregkh May 25, 2011
  31. block: export blk_{get,put}_queue()

    commit d86e0e8 upstream.
    
    We need them in SCSI to fix a bug, but currently they are not
    exported to modules. Export them.
    
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jens Axboe committed with gregkh May 27, 2011
  32. nbd: limit module parameters to a sane value

    commit 3b27108 upstream.
    
    The 'max_part' parameter controls the number of maximum partition
    a nbd device can have. However if a user specifies very large
    value it would exceed the limitation of device minor number and
    can cause a kernel oops (or, at least, produce invalid device
    nodes in some cases).
    
    In addition, specifying large 'nbds_max' value causes same
    problem for the same reason.
    
    On my desktop, following command results to the kernel bug:
    
    $ sudo modprobe nbd max_part=100000
     kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
     invalid opcode: 0000 [#1] SMP
     last sysfs file: /sys/devices/virtual/block/nbd4/range
     CPU 1
     Modules linked in: nbd(+) bridge stp llc kvm_intel kvm asus_atk0110 sg sr_mod cdrom
    
     Pid: 2522, comm: modprobe Tainted: G        W   2.6.39-leonard+ #159 System manufacturer System Product Name/P5G41TD-M PRO
     RIP: 0010:[<ffffffff8115aa08>]  [<ffffffff8115aa08>] internal_create_group+0x2f/0x166
     RSP: 0018:ffff8801009f1de8  EFLAGS: 00010246
     RAX: 00000000ffffffef RBX: ffff880103920478 RCX: 00000000000a7bd3
     RDX: ffffffff81a2dbe0 RSI: 0000000000000000 RDI: ffff880103920478
     RBP: ffff8801009f1e38 R08: ffff880103920468 R09: ffff880103920478
     R10: ffff8801009f1de8 R11: ffff88011eccbb68 R12: ffffffff81a2dbe0
     R13: ffff880103920468 R14: 0000000000000000 R15: ffff880103920400
     FS:  00007f3c49de9700(0000) GS:ffff88011f800000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
     CR2: 00007f3b7fe7c000 CR3: 00000000cd58d000 CR4: 00000000000406e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
     Process modprobe (pid: 2522, threadinfo ffff8801009f0000, task ffff8801009a93a0)
     Stack:
      ffff8801009f1e58 ffffffff812e8f6e ffff8801009f1e58 ffffffff812e7a80
      ffff880000000010 ffff880103920400 ffff8801002fd0c0 ffff880103920468
      0000000000000011 ffff880103920400 ffff8801009f1e48 ffffffff8115ab6a
     Call Trace:
      [<ffffffff812e8f6e>] ? device_add+0x4f1/0x5e4
      [<ffffffff812e7a80>] ? dev_set_name+0x41/0x43
      [<ffffffff8115ab6a>] sysfs_create_group+0x13/0x15
      [<ffffffff810b857e>] blk_trace_init_sysfs+0x14/0x16
      [<ffffffff811ee58b>] blk_register_queue+0x4c/0xfd
      [<ffffffff811f3bdf>] add_disk+0xe4/0x29c
      [<ffffffffa007e2ab>] nbd_init+0x2ab/0x30d [nbd]
      [<ffffffffa007e000>] ? 0xffffffffa007dfff
      [<ffffffff8100020f>] do_one_initcall+0x7f/0x13e
      [<ffffffff8107ab0a>] sys_init_module+0xa1/0x1e3
      [<ffffffff814f3542>] system_call_fastpath+0x16/0x1b
     Code: 41 57 41 56 41 55 41 54 53 48 83 ec 28 0f 1f 44 00 00 48 89 fb 41 89 f6 49 89 d4 48 85 ff 74 0b 85 f6 75 0b 48 83
      7f 30 00 75 14 <0f> 0b eb fe b9 ea ff ff ff 48 83 7f 30 00 0f 84 09 01 00 00 49
     RIP  [<ffffffff8115aa08>] internal_create_group+0x2f/0x166
      RSP <ffff8801009f1de8>
     ---[ end trace 753285ffbf72c57c ]---
    
    Signed-off-by: Namhyung Kim <namhyung@gmail.com>
    Cc: Laurent Vivier <Laurent.Vivier@bull.net>
    Cc: Paul Clements <Paul.Clements@steeleye.com>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    namhyung committed with gregkh May 28, 2011
  33. UBIFS: fix memory leak on error path

    commit 812eb25 upstream.
    
    UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write
    failure because it forgets to free the 'struct ubifs_dent_node *dent' object.
    Although the object is small, the alignment can make it large - e.g., 2KiB
    if the min. I/O unit is 2KiB.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Artem Bityutskiy committed with gregkh May 31, 2011
  34. UBIFS: fix shrinker object count reports

    commit cf610bf upstream.
    
    Sometimes VM asks the shrinker to return amount of objects it can shrink,
    and we return the ubifs_clean_zn_cnt in that case. However, it is possible
    that this counter is negative for a short period of time, due to the way
    UBIFS TNC code updates it. And I can observe the following warnings sometimes:
    
    shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-8541616642706119788
    
    This patch makes sure UBIFS never returns negative count of objects.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Artem Bityutskiy committed with gregkh May 31, 2011
  35. fix duplicate removal on error path in scsi_sysfs_add_sdev

    commit ee37e09 upstream.
    
    This patch (as1335) fixes a bug in scsi_sysfs_add_sdev().  Its callers
    always remove the device if anything goes wrong, so it should never
    remove the device.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Cc: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Alan Stern committed with gregkh Feb 12, 2010