Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Jun 23, 2011
  1. @gregkh

    Linux 2.6.32.42

    gregkh authored
  2. @gregkh

    Revert "iwlagn: Support new 5000 microcode."

    gregkh authored
    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>
  3. @gregkh

    time: Compensate for rounding on odd-frequency clocksources

    Kasper Pedersen authored gregkh committed
    commit a386b5a upstream.
    
    When the clocksource is not a multiple of HZ, the clock will be off.  For
    acpi_pm, HZ=1000 the error is 127.111 ppm:
    
    The rounding of cycle_interval ends up generating a false error term in
    ntp_error accumulation since xtime_interval is not exactly 1/HZ.  So, we
    subtract out the error caused by the rounding.
    
    This has been visible since 2.6.32-rc2
    	commit a092ff0
    	time: Implement logarithmic time accumulation
    That commit raised NTP_INTERVAL_FREQ and exposed the rounding error.
    
    testing tool: http://n1.taur.dk/permanent/testpmt.c
    Also tested with ntpd and a frequency counter.
    
    Signed-off-by: Kasper Pedersen <kkp2010@kasperkp.dk>
    Acked-by: john stultz <johnstul@us.ibm.com>
    Cc: John Kacur <jkacur@redhat.com>
    Cc: Clark Williams <williams@redhat.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Will Tisdale <willtisdale@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    xen: Use IRQF_FORCE_RESUME

    Thomas Gleixner authored gregkh committed
    commit 676dc3c upstream.
    
    Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra
    walk through the interrupt descriptors.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    genirq: Add IRQF_FORCE_RESUME

    Thomas Gleixner authored gregkh committed
    commit dc5f219 upstream.
    
    Xen needs to reenable interrupts which are marked IRQF_NO_SUSPEND in the
    resume path. Add a flag to force the reenabling in the resume code.
    
    Tested-and-acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    xen: events: do not unmask event channels on resume

    Ian Campbell authored gregkh committed
    commit 6903591 upstream.
    
    The IRQ core code will take care of disabling and reenabling
    interrupts over suspend resume automatically, therefore we do not need
    to do this in the Xen event channel code.
    
    The only exception is those event channels marked IRQF_NO_SUSPEND
    which the IRQ core ignores. We must unmask these ourselves, taking
    care to obey the current IRQ_DISABLED status. Failure check for
    IRQ_DISABLED leads to enabling polled only event channels, such as
    that associated with the pv spinlocks, which must never be enabled:
    
    [   21.970432] ------------[ cut here ]------------
    [   21.970432] kernel BUG at arch/x86/xen/spinlock.c:343!
    [   21.970432] invalid opcode: 0000 [#1] SMP
    [   21.970432] last sysfs file: /sys/devices/virtual/net/lo/operstate
    [   21.970432] Modules linked in:
    [   21.970432]
    [   21.970432] Pid: 0, comm: swapper Not tainted (2.6.32.24-x86_32p-xen-01034-g787c727 #34)
    [   21.970432] EIP: 0061:[<c102e209>] EFLAGS: 00010046 CPU: 3
    [   21.970432] EIP is at dummy_handler+0x3/0x7
    [   21.970432] EAX: 0000021c EBX: dfc16880 ECX: 0000001a EDX: 00000000
    [   21.970432] ESI: dfc02c00 EDI: 00000001 EBP: dfc47e10 ESP: dfc47e10
    [   21.970432]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
    [   21.970432] Process swapper (pid: 0, ti=dfc46000 task=dfc39440 task.ti=dfc46000)
    [   21.970432] Stack:
    [   21.970432]  dfc47e30 c10a39f0 0000021c 00000000 00000000 dfc16880 0000021c 00000001
    [   21.970432] <0> dfc47e40 c10a4f08 0000021c 00000000 dfc47e78 c12240a7 c1839284 c1839284
    [   21.970432] <0> 00000200 00000000 00000000 f5720000 c1f3d028 c1f3d02c 00000180 dfc47e90
    [   21.970432] Call Trace:
    [   21.970432]  [<c10a39f0>] ? handle_IRQ_event+0x5f/0x122
    [   21.970432]  [<c10a4f08>] ? handle_percpu_irq+0x2f/0x55
    [   21.970432]  [<c12240a7>] ? __xen_evtchn_do_upcall+0xdb/0x15f
    [   21.970432]  [<c122481e>] ? xen_evtchn_do_upcall+0x20/0x30
    [   21.970432]  [<c1030d47>] ? xen_do_upcall+0x7/0xc
    [   21.970432]  [<c102007b>] ? apic_reg_read+0xd3/0x22d
    [   21.970432]  [<c1002227>] ? hypercall_page+0x227/0x1005
    [   21.970432]  [<c102d30b>] ? xen_force_evtchn_callback+0xf/0x14
    [   21.970432]  [<c102da7c>] ? check_events+0x8/0xc
    [   21.970432]  [<c102da3b>] ? xen_irq_enable_direct_end+0x0/0x1
    [   21.970432]  [<c105e485>] ? finish_task_switch+0x62/0xba
    [   21.970432]  [<c14e3f84>] ? schedule+0x808/0x89d
    [   21.970432]  [<c1084dc5>] ? hrtimer_start_expires+0x1a/0x22
    [   21.970432]  [<c1085154>] ? tick_nohz_restart_sched_tick+0x15a/0x162
    [   21.970432]  [<c102f43a>] ? cpu_idle+0x6d/0x6f
    [   21.970432]  [<c14db29e>] ? cpu_bringup_and_idle+0xd/0xf
    [   21.970432] Code: 5d 0f 95 c0 0f b6 c0 c3 55 66 83 78 02 00 89 e5 5d 0f 95 \
    c0 0f b6 c0 c3 55 b2 01 86 10 31 c0 84 d2 89 e5 0f 94 c0 5d c3 55 89 e5 <0f> 0b \
    eb fe 55 80 3d 4c ce 84 c1 00 89 e5 57 56 89 c6 53 74 15
    [   21.970432] EIP: [<c102e209>] dummy_handler+0x3/0x7 SS:ESP 0069:dfc47e10
    [   21.970432] ---[ end trace c0b71f7e12cf3011 ]---
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    netfilter: IPv6: fix DSCP mangle code

    Fernando Luis Vazquez Cao authored gregkh committed
    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>
  8. @gregkh

    netfilter: IPv6: initialize TOS field in REJECT target module

    Fernando Luis Vazquez Cao authored gregkh committed
    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>
  9. @minipli @gregkh

    exec: delay address limit change until point of no return

    minipli authored gregkh committed
    commit dac853a upstream.
    
    Unconditionally changing the address limit to USER_DS and not restoring
    it to its old value in the error path is wrong because it prevents us
    using kernel memory on repeated calls to this function.  This, in fact,
    breaks the fallback of hard coded paths to the init program from being
    ever successful if the first candidate fails to load.
    
    With this patch applied switching to USER_DS is delayed until the point
    of no return is reached which makes it possible to have a multi-arch
    rootfs with one arch specific init binary for each of the (hard coded)
    probed paths.
    
    Since the address limit is already set to USER_DS when start_thread()
    will be invoked, this redundancy can be safely removed.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: 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>
  10. @hnaz @gregkh

    xfs: properly account for reclaimed inodes

    hnaz authored gregkh committed
    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>
  11. @gregkh

    ACPI: use _HID when supplied by root-level devices

    Bjorn Helgaas authored gregkh committed
    commit b7b30de upstream.
    
    Previously, we assumed the only Device object immediately below the root
    was the \_SB Scope (which the ACPI CA treats as a Device), so we forced
    the HID of all such objects to ACPI_BUS_HID ("LNXSYBUS").
    
    However, there are DSDTs that supply root-level Device objects with _HIDs.
    This patch makes us pay attention to those _HIDs and only add the synthetic
    ACPI_BUS_HID for root-level objects that do not supply their own _HID.
    
    For example, this DSDT: https://bugzilla.kernel.org/show_bug.cgi?id=15605
    contains:
    
        Scope (_SB) {
    	...
        }
        Device (AMW0) {
    	Name (_HID, EisaId ("PNP0C14"))
    	...
        }
    
    and we should use "PNP0C14" for the AMW0 device, not "LNXSYBUS".
    
    Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
    Acked-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Yong Wang <yong.y.wang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Tested-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    pata_cm64x: fix boot crash on parisc

    James Bottomley authored gregkh committed
    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>
  13. @bzolnier @gregkh

    pata_cmd64x: remove unused definitions

    bzolnier authored gregkh committed
    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>
  14. @bzolnier @gregkh

    pata_cmd64x: cmd648_bmdma_stop() fix

    bzolnier authored gregkh committed
    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>
  15. @bzolnier @gregkh

    pata_cmd64x: fix PIO setup

    bzolnier authored gregkh committed
    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>
  16. @gregkh

    ata: use pci_dev->revision

    Sergei Shtylyov authored gregkh committed
    commit 89d3b36 upstream.
    
    Some places were using PCI_CLASS_REVISION instead of PCI_REVISION_ID, so
    they weren't converted by commit 44c1013
    (PCI: Change all drivers to use pci_device->revision).
    
    Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @namhyung @gregkh

    md/raid5: fix FUA request handling in ops_run_io()

    namhyung authored gregkh committed
    commit b062962 upstream.
    
    Commit e9c7469 ("md: implment REQ_FLUSH/FUA support")
    introduced R5_WantFUA flag and set rw to WRITE_FUA in that case.
    However remaining code still checks whether rw is exactly same
    as WRITE or not, so FUAed-write ends up with being treated as
    READ. Fix it.
    
    This bug has been present since 2.6.37 and the fix is suitable for any
    -stable kernel since then.  It is not clear why this has not caused
    more problems.
    
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Namhyung Kim <namhyung@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @namhyung @gregkh

    md/raid5: fix raid5_set_bi_hw_segments

    namhyung authored gregkh committed
    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>
  19. @namhyung @gregkh

    md: check ->hot_remove_disk when removing disk

    namhyung authored gregkh committed
    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>
  20. @gregkh

    CPUFREQ: Remove cpufreq_stats sysfs entries on module unload.

    Dave Jones authored gregkh committed
    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>
  21. @gregkh

    oprofile, dcookies: Fix possible circular locking dependency

    Robert Richter authored gregkh committed
    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>
  22. @crimsun @gregkh

    ALSA: hda: Fix quirk for Dell Inspiron 910

    crimsun authored gregkh committed
    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>
  23. @gregkh

    USB: xhci - fix interval calculation for FS isoc endpoints

    Dmitry Torokhov authored gregkh committed
    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>
  24. @sledz @gregkh

    USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driver

    sledz authored gregkh committed
    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>
  25. @lpechacek @gregkh

    USB: core: Tolerate protocol stall during hub and port status read

    lpechacek authored gregkh committed
    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>
  26. @tobygray @gregkh

    USB: cdc-acm: Adding second ACM channel support for Nokia E7 and C7

    tobygray authored gregkh committed
    commit 4061fde upstream.
    
    This adds the Nokia E7 and C7 to the list of devices in cdc-acm, allowing
    the secondary ACM channel on the device to be exposed. Without this patch
    the ACM driver won't claim this secondary channel as it's marked as
    having a vendor-specific protocol.
    
    Signed-off-by: Toby Gray <toby.gray@realvnc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    x86/amd-iommu: Fix 3 possible endless loops

    Joerg Roedel authored gregkh committed
    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>
  28. @error27 @gregkh

    xen: off by one errors in multicalls.c

    error27 authored gregkh committed
    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>
  29. @OGAWAHirofumi @gregkh

    fat: Fix corrupt inode flags when remove ATTR_SYS flag

    OGAWAHirofumi authored gregkh committed
    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>
  30. @gregkh

    drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu

    Daniel Haid authored gregkh committed
    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>
  31. @jwrdegoede @gregkh

    drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007

    jwrdegoede authored gregkh committed
    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>
  32. @gregkh

    lockdep: Fix lock_is_held() on recursion

    Peter Zijlstra authored gregkh committed
    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>
  33. @gregkh

    nl80211: fix check for valid SSID size in scan operations

    Luciano Coelho authored gregkh committed
    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>
  34. @jharg @gregkh

    PCI: Set PCIE maxpayload for card during hotplug insertion

    jharg authored gregkh committed
    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>
  35. @gregkh

    mm: fix ENOSPC returned by handle_mm_fault()

    Hugh Dickins authored gregkh committed
    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>
Something went wrong with that request. Please try again.