Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jun 3, 2011
  1. @gregkh

    Linux 2.6.38.8

    gregkh authored
  2. @gregkh

    AppArmor: fix oops in apparmor_setprocattr

    Kees Cook authored gregkh committed
    commit a5b2c5b upstream.
    
    When invalid parameters are passed to apparmor_setprocattr a NULL deref
    oops occurs when it tries to record an audit message. This is because
    it is passing NULL for the profile parameter for aa_audit. But aa_audit
    now requires that the profile passed is not NULL.
    
    Fix this by passing the current profile on the task that is trying to
    setprocattr.
    
    Signed-off-by: Kees Cook <kees@ubuntu.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: James Morris <jmorris@namei.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    ext4: Use schedule_timeout_interruptible() for waiting in lazyinit th…

    Lukas Czerner authored gregkh committed
    …read
    
    commit 4ed5c03 upstream.
    
    In order to make lazyinit eat approx. 10% of io bandwidth at max, we
    are sleeping between zeroing each single inode table. For that purpose
    we are using timer which wakes up thread when it expires. It is set
    via add_timer() and this may cause troubles in the case that thread
    has been woken up earlier and in next iteration we call add_timer() on
    still running timer hence hitting BUG_ON in add_timer(). We could fix
    that by using mod_timer() instead however we can use
    schedule_timeout_interruptible() for waiting and hence simplifying
    things a lot.
    
    This commit exchange the old "waiting mechanism" with simple
    schedule_timeout_interruptible(), setting the time to sleep. Hence we
    do not longer need li_wait_daemon waiting queue and others, so get rid
    of it.
    
    Addresses-Red-Hat-Bugzilla: #699708
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @ktian1 @gregkh

    xen mmu: fix a race window causing leave_mm BUG()

    ktian1 authored gregkh committed
    commit 7899891 upstream.
    
    There's a race window in xen_drop_mm_ref, where remote cpu may exit
    dirty bitmap between the check on this cpu and the point where remote
    cpu handles drop request. So in drop_other_mm_ref we need check
    whether TLB state is still lazy before calling into leave_mm. This
    bug is rarely observed in earlier kernel, but exaggerated by the
    commit 831d52b
    ("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm")
    which clears bitmap after changing the TLB state. the call trace is as below:
    
    ---------------------------------
    kernel BUG at arch/x86/mm/tlb.c:61!
    invalid opcode: 0000 [#1] SMP
    last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
    CPU 1
    Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
    Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285
    RIP: e030:[<ffffffff8103a3cb>]  [<ffffffff8103a3cb>] leave_mm+0x15/0x46
    RSP: e02b:ffff88002805be48  EFLAGS: 00010046
    RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88015f8e2da0
    RDX: ffff88002805be78 RSI: 0000000000000000 RDI: 0000000000000001
    RBP: ffff88002805be48 R08: ffff88009d662000 R09: dead000000200200
    R10: dead000000100100 R11: ffffffff814472b2 R12: ffff88009bfc1880
    R13: ffff880028063020 R14: 00000000000004f6 R15: 0000000000000000
    FS:  00007f62362d66e0(0000) GS:ffff880028058000(0000) knlGS:0000000000000000
    CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000003aabc11909 CR3: 000000009b8ca000 CR4: 0000000000002660
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 00
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process khelper (pid: 25581, threadinfo ffff88007691e000, task ffff88009b92db40)
    Stack:
     ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88
    <0> ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78
    <0> ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108
    Call Trace:
     <IRQ>
     [<ffffffff8100e4ae>] drop_other_mm_ref+0x2a/0x53
     [<ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc
     [<ffffffff81010108>] xen_call_function_single_interrupt+0x13/0x28
     [<ffffffff810a936a>] handle_IRQ_event+0x66/0x120
     [<ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e
     [<ffffffff8128c1c0>] __xen_evtchn_do_upcall+0x1ab/0x27d
     [<ffffffff8128dd11>] xen_evtchn_do_upcall+0x33/0x46
     [<ffffffff81013efe>] xen_do_hyper visor_callback+0x1e/0x30
     <EOI>
     [<ffffffff814472b2>] ? _spin_unlock_irqrestore+0x15/0x17
     [<ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
     [<ffffffff81113f71>] ? flush_old_exec+0x3ac/0x500
     [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
     [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
     [<ffffffff8115115d>] ? load_elf_binary+0x398/0x17ef
     [<ffffffff81042fcf>] ? need_resched+0x23/0x2d
     [<ffffffff811f4648>] ? process_measurement+0xc0/0xd7
     [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
     [<ffffffff81113094>] ? search_binary_handler+0xc8/0x255
     [<ffffffff81114362>] ? do_execve+0x1c3/0x29e
     [<ffffffff8101155d>] ? sys_execve+0x43/0x5d
     [<ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
     [<ffffffff81013e28>] ? kernel_execve+0x68/0xd0
     [<ffffffff 8106fc45>] ? __call_usermodehelper+0x0/0x6f
     [<ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
     [<ffffffff8106fb64>] ? ____call_usermodehelper+0x113/0x11e
     [<ffffffff81013daa>] ? child_rip+0xa/0x20
     [<ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
     [<ffffffff81012f91>] ? int_ret_from_sys_call+0x7/0x1b
     [<ffffffff8101371d>] ? retint_restore_args+0x5/0x6
     [<ffffffff81013da0>] ? child_rip+0x0/0x20
    Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8
    RIP  [<ffffffff8103a3cb>] leave_mm+0x15/0x46
     RSP <ffff88002805be48>
    ---[ end trace ce9cee6832a9c503 ]---
    
    Tested-by: Maoxiaoyun<tinnycloud@hotmail.com>
    Signed-off-by: Kevin Tian <kevin.tian@intel.com>
    [v1: Fleshed out the git description a bit]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    PCI: Add quirk for setting valid class for TI816X Endpoint

    Hemant Pedanekar authored gregkh committed
    commit 63c4408 upstream.
    
    TI816X (common name for DM816x/C6A816x/AM389x family) devices configured
    to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus
    code to skip allocating BARs to these devices resulting into following
    type of error when trying to enable them:
    
    "Device 0000:01:00.0 not available because of resource collisions"
    
    The device cannot be operated because of the above issue.
    
    This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based)
    'early' fixup quirk to replace class code with
    PCI_CLASS_MULTIMEDIA_VIDEO as class.
    
    Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    NFSv4.1: Fix the handling of NFS4ERR_SEQ_MISORDERED errors

    Trond Myklebust authored gregkh committed
    commit 444f72f upstream.
    
    Currently, the call to nfs4_schedule_session_recovery() will actually just
    result in a test of the lease when what we really want is to force a
    session reset.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    NFSv4: Handle expired stateids when the lease is still valid

    Trond Myklebust authored gregkh committed
    commit 0ced63d upstream.
    
    Currently, if the server returns NFS4ERR_EXPIRED in reply to a READ or
    WRITE, but the RENEW test determines that the lease is still active, we
    fail to recover and end up looping forever in a READ/WRITE + RENEW death
    spiral.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback...

    Trond Myklebust authored gregkh committed
    commit fe19a96 upstream.
    
    The TCP connection state code depends on the state_change() callback
    being called when the SYN_SENT state is set. However the networking layer
    doesn't actually call us back in that case.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    drm/radeon/kms: add wait idle ioctl for eg->cayman

    Dave Airlie authored gregkh committed
    commit 97bfd0a upstream.
    
    None of the latest GPUs had this hooked up, this is necessary for
    correct operation in a lot of cases, however we should test this on a few
    GPUs in these families as we've had problems in this area before.
    
    Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush wh…

    Alex Deucher authored gregkh committed
    …en asked
    
    commit f25a5c6 upstream.
    
    This needs to be explicitly set on btc.  It's set by default
    on evergreen/fusion, so it fine to just unconditionally enable it for
    all chips.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    drm/i915: fix user irq miss in BSD ring on g4x

    Boqun Feng authored gregkh committed
    commit 5bfa106 upstream.
    
    On g4x, user interrupt in BSD ring is missed.
    This is because though g4x and ironlake share the same bsd_ring,
    their interrupt control interfaces have _two_ differences.
    
    1.different irq enable/disable functions:
    On g4x are i915_enable_irq and i915_disable_irq.
    On ironlake are ironlake_enable_irq and ironlake_disable_irq.
    2.different irq flag:
    On g4x user interrupt flag in BSD ring on is I915_BSD_USER_INTERRUPT.
    On ironlake is GT_BSD_USER_INTERRUPT
    
    Old bsd_ring_get/put_irq call ring_get_irq and ring_get_irq.
    ring_get_irq and ring_put_irq only call ironlake_enable/disable_irq.
    So comes the irq miss on g4x.
    
    To fix this, as other rings' code do, conditionally call different
    functions(i915_enable/disable_irq and ironlake_enable/disable_irq)
    and use different interrupt flags in bsd_ring_get/put_irq.
    
    Signed-off-by: Boqun Feng <boqun.feng@intel.com>
    Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @namhyung @gregkh

    brd: handle on-demand devices correctly

    namhyung authored gregkh committed
    commit af46566 upstream.
    
    When finding or allocating a ram disk device, brd_probe() did not take
    partition numbers into account so that it can result to a different
    device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4
    for simplicity) :
    
    $ sudo modprobe brd max_part=15
    $ ls -l /dev/ram*
    brw-rw---- 1 root disk 1,  0 2011-05-25 15:41 /dev/ram0
    brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
    brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
    brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
    $ sudo mknod /dev/ram4 b 1 64
    $ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256
    256+0 records in
    256+0 records out
    1048576 bytes (1.0 MB) copied, 0.00215578 s, 486 MB/s
    namhyung@leonhard:linux$ ls -l /dev/ram*
    brw-rw---- 1 root disk 1,    0 2011-05-25 15:41 /dev/ram0
    brw-rw---- 1 root disk 1,   16 2011-05-25 15:41 /dev/ram1
    brw-rw---- 1 root disk 1,   32 2011-05-25 15:41 /dev/ram2
    brw-rw---- 1 root disk 1,   48 2011-05-25 15:41 /dev/ram3
    brw-r--r-- 1 root root 1,   64 2011-05-25 15:45 /dev/ram4
    brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64
    
    After this patch, /dev/ram4 - instead of /dev/ram64 - was
    accessed correctly.
    
    In addition, 'range' passed to blk_register_region() should
    include all range of dev_t that RAMDISK_MAJOR can address.
    It does not need to be limited by partition numbers unless
    'rd_nr' param was specified.
    
    Signed-off-by: Namhyung Kim <namhyung@gmail.com>
    Cc: Laurent Vivier <Laurent.Vivier@bull.net>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @namhyung @gregkh

    brd: limit 'max_part' module param to DISK_MAX_PARTS

    namhyung authored gregkh committed
    commit 315980c upstream.
    
    The 'max_part' parameter controls the number of maximum partition
    a brd 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 panic (or, at least, produce invalid device
    nodes in some cases).
    
    On my desktop system, following command kills the kernel. On qemu,
    it triggers similar oops but the kernel was alive:
    
    $ sudo modprobe brd max_part=100000
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
     IP: [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
     PGD 7af1067 PUD 7b19067 PMD 0
     Oops: 0000 [#1] SMP
     last sysfs file:
     CPU 0
     Modules linked in: brd(+)
    
     Pid: 44, comm: insmod Tainted: G        W   2.6.39-qemu+ #158 Bochs Bochs
     RIP: 0010:[<ffffffff81110a9a>]  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
     RSP: 0018:ffff880007b15d78  EFLAGS: 00000286
     RAX: ffff880007b05478 RBX: ffff880007a52760 RCX: ffff880007b15dc8
     RDX: ffff880007a4f900 RSI: ffff880007b15e48 RDI: ffff880007a52760
     RBP: ffff880007b15da8 R08: 0000000000000002 R09: 0000000000000000
     R10: ffff880007b15e48 R11: ffff880007b05478 R12: 0000000000000000
     R13: ffff880007b05478 R14: 0000000000400920 R15: 0000000000000063
     FS:  0000000002160880(0063) GS:ffff880007c00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000058 CR3: 0000000007b1c000 CR4: 00000000000006b0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
     Process insmod (pid: 44, threadinfo ffff880007b14000, task ffff880007acb980)
     Stack:
      ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe
      ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a
      0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000
     Call Trace:
      [<ffffffff81143c0a>] kobject_add_internal+0xdf/0x1a0
      [<ffffffff81143da1>] kobject_add_varg+0x41/0x50
      [<ffffffff81143e6b>] kobject_add+0x64/0x66
      [<ffffffff8113bbe7>] blk_register_queue+0x5f/0xb8
      [<ffffffff81140f72>] add_disk+0xdf/0x289
      [<ffffffffa00040df>] brd_init+0xdf/0x1aa [brd]
      [<ffffffffa0004000>] ? 0xffffffffa0003fff
      [<ffffffffa0004000>] ? 0xffffffffa0003fff
      [<ffffffff8100020a>] do_one_initcall+0x7a/0x12e
      [<ffffffff8108516c>] sys_init_module+0x9c/0x1dc
      [<ffffffff812ff4bb>] system_call_fastpath+0x16/0x1b
     Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30
      8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89
     RIP  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
      RSP <ffff880007b15d78>
     CR2: 0000000000000058
     ---[ end trace aebb1175ce1f6739 ]---
    
    Signed-off-by: Namhyung Kim <namhyung@gmail.com>
    Cc: Laurent Vivier <Laurent.Vivier@bull.net>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @dcbw @gregkh

    atm: expose ATM device index in sysfs

    dcbw authored gregkh committed
    commit e7a46b4 upstream.
    
    It's currently exposed only through /proc which, besides requiring
    screen-scraping, doesn't allow userspace to distinguish between two
    identical ATM adapters with different ATM indexes.  The ATM device index
    is required when using PPPoATM on a system with multiple ATM adapters.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
    Tested-by: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    tmpfs: fix race between truncate and writepage

    Hugh Dickins authored gregkh committed
    commit 826267c upstream.
    
    While running fsx on tmpfs with a memhog then swapoff, swapoff was hanging
    (interruptibly), repeatedly failing to locate the owner of a 0xff entry in
    the swap_map.
    
    Although shmem_writepage() does abandon when it sees incoming page index
    is beyond eof, there was still a window in which shmem_truncate_range()
    could come in between writepage's dropping lock and updating swap_map,
    find the half-completed swap_map entry, and in trying to free it,
    leave it in a state that swap_shmem_alloc() could not correct.
    
    Arguably a bug in __swap_duplicate()'s and swap_entry_free()'s handling
    of the different cases, but easiest to fix by moving swap_shmem_alloc()
    under cover of the lock.
    
    More interesting than the bug: it's been there since 2.6.33, why could
    I not see it with earlier kernels?  The mmotm of two weeks ago seems to
    have some magic for generating races, this is just one of three I found.
    
    With yesterday's git I first saw this in mainline, bisected in search of
    that magic, but the easy reproducibility evaporated.  Oh well, fix the bug.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @wildea01 @gregkh

    ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dca…

    wildea01 authored gregkh committed
    …che_area
    
    commit a248b13 upstream.
    
    The v6 and v7 implementations of flush_kern_dcache_area do not align
    the passed MVA to the size of a cacheline in the data cache. If a
    misaligned address is used, only a subset of the requested area will
    be flushed. This has been observed to cause failures in SMP boot where
    the secondary_data initialised by the primary CPU is not cacheline
    aligned, causing the secondary CPUs to read incorrect values for their
    pgd and stack pointers.
    
    This patch ensures that the base address is cacheline aligned before
    flushing the d-cache.
    
    Acked-by: Catalin Marinas <catalin.marinas@arm.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>
  17. @gregkh

    dm table: reject devices without request fns

    Milan Broz authored gregkh committed
    commit f4808ca upstream.
    
    This patch adds a check that a block device has a request function
    defined before it is used.  Otherwise, misconfiguration can cause an oops.
    
    Because we are allowing devices with zero size e.g. an offline multipath
    device as in commit 2cd54d9
    ("dm: allow offline devices") there needs to be an additional check
    to ensure devices are initialised.  Some block devices, like a loop
    device without a backing file, exist but have no request function.
    
    Reproducer is trivial: dm-mirror on unbound loop device
    (no backing file on loop devices)
    
    dmsetup create x --table "0 8 mirror core 2 8 sync 2 /dev/loop0 0 /dev/loop1 0"
    
    and mirror resync will immediatelly cause OOps.
    
    BUG: unable to handle kernel NULL pointer dereference at   (null)
     ? generic_make_request+0x2bd/0x590
     ? kmem_cache_alloc+0xad/0x190
     submit_bio+0x53/0xe0
     ? bio_add_page+0x3b/0x50
     dispatch_io+0x1ca/0x210 [dm_mod]
     ? read_callback+0x0/0xd0 [dm_mirror]
     dm_io+0xbb/0x290 [dm_mod]
     do_mirror+0x1e0/0x748 [dm_mirror]
    
    Signed-off-by: Milan Broz <mbroz@redhat.com>
    Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
    Acked-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    idle governor: Avoid lock acquisition to read pm_qos before entering …

    Tim Chen authored gregkh committed
    …idle
    
    commit 333c5ae upstream.
    
    Thanks to the reviews and comments by Rafael, James, Mark and Andi.
    Here's version 2 of the patch incorporating your comments and also some
    update to my previous patch comments.
    
    I noticed that before entering idle state, the menu idle governor will
    look up the current pm_qos target value according to the list of qos
    requests received.  This look up currently needs the acquisition of a
    lock to access the list of qos requests to find the qos target value,
    slowing down the entrance into idle state due to contention by multiple
    cpus to access this list.  The contention is severe when there are a lot
    of cpus waking and going into idle.  For example, for a simple workload
    that has 32 pair of processes ping ponging messages to each other, where
    64 cpu cores are active in test system, I see the following profile with
    37.82% of cpu cycles spent in contention of pm_qos_lock:
    
    -     37.82%          swapper  [kernel.kallsyms]          [k]
    _raw_spin_lock_irqsave
       - _raw_spin_lock_irqsave
          - 95.65% pm_qos_request
               menu_select
               cpuidle_idle_call
             - cpu_idle
                  99.98% start_secondary
    
    A better approach will be to cache the updated pm_qos target value so
    reading it does not require lock acquisition as in the patch below.
    With this patch the contention for pm_qos_lock is removed and I saw a
    2.2X increase in throughput for my message passing workload.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Acked-by: Andi Kleen <ak@linux.intel.com>
    Acked-by: James Bottomley <James.Bottomley@suse.de>
    Acked-by: mark gross <markgross@thegnar.org>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    cpuidle: menu: fixed wrapping timers at 4.294 seconds

    Tero Kristo authored gregkh committed
    commit 7467571 upstream.
    
    Cpuidle menu governor is using u32 as a temporary datatype for storing
    nanosecond values which wrap around at 4.294 seconds. This causes errors
    in predicted sleep times resulting in higher than should be C state
    selection and increased power consumption. This also breaks cpuidle
    state residency statistics.
    
    Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @tettamanti @gregkh

    i8k: Avoid lahf in 64-bit code

    tettamanti authored gregkh committed
    commit bc1f419 upstream.
    
    i8k uses lahf to read the flag register in 64-bit code; early x86-64
    CPUs, however, lack this instruction and we get an invalid opcode
    exception at runtime.
    Use pushf to load the flag register into the stack instead.
    
    Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
    Reported-by: Jeff Rickman <jrickman@myamigos.us>
    Tested-by: Jeff Rickman <jrickman@myamigos.us>
    Tested-by: Harry G McGavran Jr <w5pny@arrl.net>
    Cc: Massimo Dal Zotto <dz@debian.org>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @cernekee @gregkh

    kbuild: Fix GNU make v3.80 compatibility

    cernekee authored gregkh committed
    commit 43f67c9 upstream.
    
    According to Documentation/Changes, the kernel should be buildable with
    GNU make 3.80+.  Commit 88d7be0 (kbuild:
    Use a single clean rule for kernel and external modules) introduced the
    "$(or" construct, which requires make 3.81.  This causes "make clean" to
    malfunction when it is used with external modules.
    
    Replace "$(or" with an equivalent "$(if" expression, to restore backward
    compatibility.
    
    Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    UBIFS: fix a rare memory leak in ro to rw remounting path

    Artem Bityutskiy authored gregkh committed
    commit eaeee24 upstream.
    
    When re-mounting from R/O mode to R/W mode and the LEB count in the superblock
    is not up-to date, because for the underlying UBI volume became larger, we
    re-write the superblock. We allocate RAM for these purposes, but never free it.
    So this is a memory leak, although very rare one.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    eCryptfs: Allow 2 scatterlist entries for encrypted filenames

    Tyler Hicks authored gregkh committed
    commit 8d08dab upstream.
    
    The buffers allocated while encrypting and decrypting long filenames can
    sometimes straddle two pages. In this situation, virt_to_scatterlist()
    will return -ENOMEM, causing the operation to fail and the user will get
    scary error messages in their logs:
    
    kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting
    to convert filename memory to scatterlist; expected rc = 1; got rc =
    [-12]. block_aligned_filename_size = [272]
    kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70
    packet; rc = [-12]
    kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to
    encrypt filename; rc = [-12]
    kernel: ecryptfs_lookup: Error attempting to encrypt and encode
    filename; rc = [-12]
    
    The solution is to allow up to 2 scatterlist entries to be used.
    
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @chunkeey @gregkh

    p54usb: add zoom 4410 usbid

    chunkeey authored gregkh committed
    commit 9368a9a upstream.
    
    Reported-by: Mark Davis <marked86@gmail.com>
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @morimoto @gregkh

    sh: fixup fpu.o compile order

    morimoto authored gregkh committed
    commit a375b15 upstream.
    
    arch_ptrace() was modified to reference init_fpu() to fix up xstate
    initialization, which overlooked the fact that there are configurations
    that don't enable any of hard FPU support or emulation, resulting in
    build errors on DSP parts.
    
    Given that init_fpu() simply sets up the xstate slab cache and is
    side-stepped entirely for the DSP case, we can simply always build in the
    helper and fix up the references.
    
    Reported-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Paul Mundt <lethal@linux-sh.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @morimoto @gregkh

    sh: clkfwk: fixup clk_rate_table_build parameter in div6 clock

    morimoto authored gregkh committed
    commit 52c10ad upstream.
    
    div6 clock should not use arch_flags for clk_rate_table_build,
    because SH_CLK_DIV6_EXT doesn't care .arch_flags.
    clk->freq_table[] will be all CPUFREQ_ENTRY_INVALID without this patch.
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Paul Mundt <lethal@linux-sh.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @jrn @gregkh

    cx88: hold device lock during sub-driver initialization

    jrn authored gregkh committed
    commit 1d6213a upstream.
    
    cx8802_blackbird_probe makes a device node for the mpeg sub-device
    before it has been added to dev->drvlist.  If the device is opened
    during that time, the open succeeds but request_acquire cannot be
    called, so the reference count remains zero.  Later, when the device
    is closed, the reference count becomes negative --- uh oh.
    
    Close the race by holding core->lock during probe and not releasing
    until the device is in drvlist and initialization finished.
    Previously the BKL prevented this race.
    
    Reported-by: Andreas Huber <hobrom@gmx.at>
    Tested-by: Andi Huber <hobrom@gmx.at>
    Tested-by: Marlon de Boer <marlon@hyves.nl>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @jrn @gregkh

    cx88: fix locking of sub-driver operations

    jrn authored gregkh committed
    commit 1fe70e9 upstream.
    
    The BKL conversion of this driver seems to have gone wrong.
    Loading the cx88-blackbird driver deadlocks.
    
    The cause: mpeg_ops::open in the cx2388x blackbird driver acquires the
    device lock and calls the sub-driver's request_acquire, which tries to
    acquire the lock again.  Fix it by clarifying the semantics of
    request_acquire, request_release, advise_acquire, and advise_release:
    now all will rely on the caller to acquire the device lock.
    
    Based on work by Ben Hutchings <ben@decadent.org.uk>.
    
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=31962
    
    Reported-by: Andi Huber <hobrom@gmx.at>
    Tested-by: Andi Huber <hobrom@gmx.at>
    Tested-by: Marlon de Boer <marlon@hyves.nl>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @jrn @gregkh

    cx88: protect per-device driver list with device lock

    jrn authored gregkh committed
    commit 8a317a8 upstream.
    
    The BKL conversion of this driver seems to have gone wrong.  Various
    uses of the sub-device and driver lists appear to be subject to race
    conditions.
    
    In particular, some functions access drvlist without a relevant lock
    held, which will race against removal of drivers.  Let's start with
    that --- clean up by consistently protecting dev->drvlist with
    dev->core->lock, noting driver functions that require the device lock
    to be held or not to be held.
    
    After this patch, there are still some races --- e.g.,
    cx8802_blackbird_remove can run between the time the blackbird driver
    is acquired and the time it is used in mpeg_release, and there's a
    similar race in cx88_dvb_bus_ctrl.  Later patches will address the
    remaining known races and the deadlock noticed by Andi.  This patch
    just makes the semantics clearer in preparation for those later
    changes.
    
    Based on work by Ben Hutchings <ben@decadent.org.uk>.
    
    Tested-by: Andi Huber <hobrom@gmx.at>
    Tested-by: Marlon de Boer <marlon@hyves.nl>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    USB: remove remaining usages of hcd->state from usbcore and fix regre…

    Alan Stern authored gregkh committed
    …ssion
    
    commit 69fff59 upstream.
    
    This patch (as1467) removes the last usages of hcd->state from
    usbcore.  We no longer check to see if an interrupt handler finds that
    a controller has died; instead we rely on host controller drivers to
    make an explicit call to usb_hc_died().
    
    This fixes a regression introduced by commit
    9b37596 (USB: move usbcore away from
    hcd->state).  It used to be that when a controller shared an IRQ with
    another device and an interrupt arrived while hcd->state was set to
    HC_STATE_HALT, the interrupt handler would be skipped.  The commit
    removed that test; as a result the current code doesn't skip calling
    the handler and ends up believing the controller has died, even though
    it's only temporarily stopped.  The solution is to ignore HC_STATE_HALT
    following the handler's return.
    
    As a consequence of this change, several of the host controller
    drivers need to be modified.  They can no longer implicitly rely on
    usbcore realizing that a controller has died because of hcd->state.
    The patch adds calls to usb_hc_died() in the appropriate places.
    
    The patch also changes a few of the interrupt handlers.  They don't
    expect to be called when hcd->state is equal to HC_STATE_HALT, even if
    the controller is still alive.  Early returns were added to avoid any
    confusion.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
    CC: Rodolfo Giometti <giometti@linux.it>
    CC: Olav Kongas <ok@artecdesign.ee>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @gregkh

    OHCI: fix regression caused by nVidia shutdown workaround

    Alan Stern authored gregkh committed
    commit 2b7aaf5 upstream.
    
    This patch (as1463) fixes a regression caused by commit
    3df7169 (OHCI: work around for nVidia
    shutdown problem).
    
    The original problem encountered by people using NVIDIA chipsets was
    that USB devices were not turning off when the system shut down.  For
    example, the LED on an optical mouse would remain on, draining a
    laptop's battery.  The problem was caused by a bug in the chipset; an
    OHCI controller in the Reset state would continue to drive a bus reset
    signal even after system shutdown.  The workaround was to put the
    controllers into the Suspend state instead.
    
    It turns out that later NVIDIA chipsets do not suffer from this bug.
    Instead some have the opposite bug: If a system is shut down while an
    OHCI controller is in the Suspend state, USB devices remain powered!
    On other systems, shutting down with a Suspended controller causes the
    system to reboot immediately.  Thus, working around the original bug
    on some machines exposes other bugs on other machines.
    
    The best solution seems to be to limit the workaround to OHCI
    controllers with a low-numbered PCI product ID.  I don't know exactly
    at what point NVIDIA changed their chipsets; the value used here is a
    guess.  So far it was worked out okay for all the people who have
    tested it.
    
    This fixes Bugzilla #35032.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
    Tested-by: Yury Siamashka <yurand2@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @gregkh

    USB: option: add support for Huawei E353 device

    Marcin Gałczyński authored gregkh committed
    commit 610ba42 upstream.
    
    I am sharing patch to the devices/usb/serial/option.c. This allows
    operation of Huawei E353 broadband modem using the “option” driver. The
    patch simply adds new constant with proper product ID and an entry to
    usb_device_id. I worked on the 2.6.38.6 sources. Tested on Dell inspiron
    1764 (i3 core cpu) and brand new Huawei E353 modem, Fedora 15 beta.
    
    Looking at the type of change, i doubt it has potential to introduce
    problems in other parts of kernel or the driver itself.
    
    Signed-off-by: Marcin Galczynski <marcin@galczynski.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @gregkh

    xhci: Fix memory leak bug when dropping endpoints

    Sarah Sharp authored gregkh committed
    commit 834cb0f upstream.
    
    When the USB core wants to change to an alternate interface setting that
    doesn't include an active endpoint, or de-configuring the device, the xHCI
    driver needs to issue a Configure Endpoint command to tell the host to
    drop some endpoints from the schedule.  After the command completes, the
    xHCI driver needs to free rings for any endpoints that were dropped.
    
    Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
    for dropped endpoints.  The rings would be freed if the endpoint's
    information was simply changed (and a new ring was installed), but dropped
    endpoints never had their rings freed.  This caused errors when the ring
    segment DMA pool was freed when the xHCI driver was unloaded:
    
    [ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy
    [ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy
    [ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy
    [ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
    [ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
    [ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
    [ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
    [ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
    [ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
    [ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled
    
    Fix this issue and free endpoint rings when their endpoints are
    successfully dropped.
    
    This patch should be backported to kernels as old as 2.6.31.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @gregkh

    xhci: Fix memory leak in ring cache deallocation.

    Sarah Sharp authored gregkh committed
    commit 30f89ca upstream.
    
    When an endpoint ring is freed, it is either cached in a per-device ring
    cache, or simply freed if the ring cache is full.  If the ring was added
    to the cache, then virt_dev->num_rings_cached is incremented.  The cache
    is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
    When the device is freed (when the slot was disabled),
    xhci_free_virt_device() is called, it would free the cached rings in
    array indexes 0 to virt_dev->num_rings_cached.
    
    Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
    would put the first entry into the ring cache in array index 1, instead of
    array index 0.  This was caused by the second assignment to rings_cached:
    
    	rings_cached = virt_dev->num_rings_cached;
    	if (rings_cached < XHCI_MAX_RINGS_CACHED) {
    		virt_dev->num_rings_cached++;
    		rings_cached = virt_dev->num_rings_cached;
    		virt_dev->ring_cache[rings_cached] =
    			virt_dev->eps[ep_index].ring;
    
    This meant that when the device was freed, cached rings with indexes 0 to
    N would be freed, and the last cached ring in index N+1 would not be
    freed.  When the driver was unloaded, this caused interesting messages
    like:
    
    xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy
    
    This should be queued to stable kernels back to 2.6.33.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @gregkh

    xhci: Fix full speed bInterval encoding.

    Sarah Sharp authored gregkh committed
    commit b513d44 upstream.
    
    Dmitry's patch
    
    dfa49c4 USB: xhci - fix math in xhci_get_endpoint_interval()
    
    introduced a bug.  The USB 2.0 spec says that full speed isochronous endpoints'
    bInterval must be decoded as an exponent to a power of two (e.g. interval =
    2^(bInterval - 1)).  Full speed interrupt endpoints, on the other hand, don't
    use exponents, and the interval in frames is encoded straight into bInterval.
    
    Dmitry's patch was supposed to fix up the full speed isochronous to parse
    bInterval as an exponent, but instead it changed the *interrupt* endpoint
    bInterval decoding.  The isochronous endpoint encoding was the same.
    
    This caused full speed devices with interrupt endpoints (including mice, hubs,
    and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
    
    [  100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
    [  100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
    ...
    [  100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
    [  100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
    
    When the interrupt endpoint was added and a Configure Endpoint command was
    issued to the host, the host controller would return a very odd error message
    (0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
    Probably the host controller was getting very confused with the bad encoding.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: Dmitry Torokhov <dtor@vmware.com>
    Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
    Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.