Permalink
Switch branches/tags
Commits on Jun 28, 2011
  1. apply raw snapshot patch v1.0.14-rc1 over next3 clone

    amir73il committed Nov 26, 2010
    the raw snapshot patch contains ifdef annotations which can be used to extract
    the snapshot patch series from any point in the branch.
    the extracted patch series can be applied on top of next3 clone
    (tag v2.6.38.8-next3 for example).
  2. clone next3 from ext3 in kernel 2.6.38.8

    amir73il committed Jun 28, 2011
    prepare for rebasing next3-dev branch to stable kernel 2.6.38.8.
Commits on Jun 16, 2011
  1. reimplement tind block pre-allocation in snapshot_create

    amir73il committed Jun 9, 2011
    since we cannot allocate direct blocks in snapshot files
    using next3_getblk() anymore, we allocate the DIND branches
    at offset 0 and move it to the TIND branch we want to pre-allocate.
Commits on Jun 15, 2011
  1. resolve 32bit overflow in next_block_to_path

    amir73il committed Jun 9, 2011
    Snapshot image addresses should need to cover a 16TB filesystem
    (2^32-1 blocks).
    
    Snapshot image logical address 0 was the first doubly indirect
    mapped block at offset 1036 in the snapshot inode.
    This caused a 32bit overflow when calling next3_block_to_path for
    the last blocks in a 16TB snapshot file (2^32+1035).
    
    We change the code to always use logical addresses 0..2^32-1
    when accessing snapshot files and only deal with the 1036 offset
    inside next3_block_to_path, where the overflow can be noticed and handled
    properly.
    
    next3_snapblk_t has been depraced and next3_lblk_t (_u32) is used instead.
    SNAPSHOT_BLOCK() and SNAPSHOT_IBLOCK() macros now don't change the
    offset, only cast from next3_lblk_t to next3_fsblk_t and back.
Commits on Jun 3, 2011
  1. Linux 2.6.38.8

    gregkh committed Jun 3, 2011
  2. AppArmor: fix oops in apparmor_setprocattr

    Kees Cook committed with gregkh May 31, 2011
    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. ext4: Use schedule_timeout_interruptible() for waiting in lazyinit th…

    Lukas Czerner committed with gregkh May 20, 2011
    …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. xen mmu: fix a race window causing leave_mm BUG()

    ktian1 committed with gregkh May 12, 2011
    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. PCI: Add quirk for setting valid class for TI816X Endpoint

    Hemant Pedanekar committed with gregkh Apr 5, 2011
    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. NFSv4.1: Fix the handling of NFS4ERR_SEQ_MISORDERED errors

    Trond Myklebust committed with gregkh May 26, 2011
    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. NFSv4: Handle expired stateids when the lease is still valid

    Trond Myklebust committed with gregkh May 26, 2011
    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. SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback...

    Trond Myklebust committed with gregkh Mar 19, 2011
    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. drm/radeon/kms: add wait idle ioctl for eg->cayman

    Dave Airlie committed with gregkh May 19, 2011
    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. drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush wh…

    Alex Deucher committed with gregkh May 19, 2011
    …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. drm/i915: fix user irq miss in BSD ring on g4x

    Boqun Feng committed with gregkh May 16, 2011
    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. brd: handle on-demand devices correctly

    namhyung committed with gregkh May 26, 2011
    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. brd: limit 'max_part' module param to DISK_MAX_PARTS

    namhyung committed with gregkh May 26, 2011
    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. atm: expose ATM device index in sysfs

    dcbw committed with gregkh May 27, 2011
    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. tmpfs: fix race between truncate and writepage

    Hugh Dickins committed with gregkh May 28, 2011
    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. ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dca…

    wildea01 committed with gregkh May 26, 2011
    …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. dm table: reject devices without request fns

    mbroz committed with gregkh May 29, 2011
    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. idle governor: Avoid lock acquisition to read pm_qos before entering …

    pdxChen committed with gregkh Feb 11, 2011
    …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. cpuidle: menu: fixed wrapping timers at 4.294 seconds

    Tero Kristo committed with gregkh Feb 24, 2011
    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. i8k: Avoid lahf in 64-bit code

    tettamanti committed with gregkh May 25, 2011
    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. kbuild: Fix GNU make v3.80 compatibility

    cernekee committed with gregkh May 10, 2011
    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. UBIFS: fix a rare memory leak in ro to rw remounting path

    Artem Bityutskiy committed with gregkh May 6, 2011
    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. eCryptfs: Allow 2 scatterlist entries for encrypted filenames

    Tyler Hicks committed with gregkh May 17, 2011
    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. p54usb: add zoom 4410 usbid

    chunkeey committed with gregkh May 13, 2011
    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. sh: fixup fpu.o compile order

    morimoto committed with gregkh Apr 15, 2011
    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. sh: clkfwk: fixup clk_rate_table_build parameter in div6 clock

    morimoto committed with gregkh Apr 14, 2011
    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>