Linux 3.0.41

commit a422ca75bd264cd26bafeb6305655245d2ea7c6b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Aug 15 12:05:01 2012 -0700

    Linux 3.0.41

commit 931d5990ed8186a1dc627b34c7d3b28dd89011d7
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Aug 3 12:49:14 2012 +0200

    rt61pci: fix NULL pointer dereference in config_lna_gain

    commit deee0214def5d8a32b8112f11d9c2b1696e9c0cb upstream.

    We can not pass NULL libconf->conf->channel to rt61pci_config() as it
    is dereferenced unconditionally in rt61pci_config_lna_gain() subroutine.

    Resolves:
    https://bugzilla.kernel.org/show_bug.cgi?id=44361

    Reported-and-tested-by: <dolohow@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab7029e676b83e54e639101e5ba96a07d7968cd5
Author: Chris Bagwell <chris@cnpbagwell.com>
Date:   Tue Jun 12 00:25:48 2012 -0700

    Input: wacom - Bamboo One 1024 pressure fix

    commit 6dc463511d4a690f01a9248df3b384db717e0b1c upstream.

    Bamboo One's with ID of 0x6a and 0x6b were added with correct
    indication of 1024 pressure levels but the Graphire packet routine
    was only looking at 9 bits.  Increased to 10 bits.

    This bug caused these devices to roll over to zero pressure at half
    way mark.

    The other devices using this routine only support 256 or 512 range
    and look to fix unused bits at zero.

    Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
    Reported-by: Tushant Mirchandani <tushantin@gmail.com>
    Reviewed-by: Ping Cheng <pingc@wacom.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a4cebe94b76a0182a8ebb97b665ff84e7427482
Author: Tushar Dave <tushar.n.dave@intel.com>
Date:   Tue Jul 31 02:02:43 2012 +0000

    e1000e: NIC goes up and immediately goes down

    commit b7ec70be01a87f2c85df3ae11046e74f9b67e323 upstream.

    Found that commit d478eb44 was a bad commit.
    If the link partner is transmitting codeword (even if NULL codeword),
    then the RXCW.C bit will be set so check for RXCW.CW is unnecessary.
    Ref: RH BZ 840642

    Reported-by: Fabio Futigami <ffutigam@redhat.com>
    Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
    CC: Marcelo Ricardo Leitner <mleitner@redhat.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f5a5866aa4dccf42b2fa1cdecf372025a3e86cc
Author: Liang Li <liang.li@windriver.com>
Date:   Thu Aug 2 18:55:41 2012 -0400

    cfg80211: fix interface combinations check for ADHOC(IBSS)

    partial of commit 8e8b41f9d8c8e63fc92f899ace8da91a490ac573 upstream.

    As part of commit 463454b5dbd8 ("cfg80211: fix interface
    combinations check"), this extra check was introduced:

           if ((all_iftypes & used_iftypes) != used_iftypes)
                   goto cont;

    However, most wireless NIC drivers did not advertise ADHOC in
    wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
    when we bring up a ADHOC wlan with commands similar to:

     # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up

    In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
    combinations"), the change below fixes the issue:

           if (total == 1)
                   return 0;

    But it also introduces other dependencies for stable. For example,
    a full cherry pick of 8e8b41f9d8c8e would introduce additional
    regressions unless we also start cherry picking driver specific
    fixes like the following:

      9b4760e  ath5k: add possible wiphy interface combinations
      1ae2fc2  mac80211_hwsim: advertise interface combinations
      20c8e8d  ath9k: add possible wiphy interface combinations

    And the purpose of the 'if (total == 1)' is to cover the specific
    use case (IBSS, adhoc) that was mentioned above. So we just pick
    the specific part out from 8e8b41f9d8c8e here.

    Doing so gives stable kernels a way to fix the change introduced
    by 463454b5dbd8, without having to make cherry picks specific to
    various NIC drivers.

    Signed-off-by: Liang Li <liang.li@windriver.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b27c59d2c23d5f326a74e02a799cc4d00246165a
Author: Daniel Drake <dsd@laptop.org>
Date:   Thu Aug 2 18:41:48 2012 +0100

    cfg80211: process pending events when unregistering net device

    commit 1f6fc43e621167492ed4b7f3b4269c584c3d6ccc upstream.

    libertas currently calls cfg80211_disconnected() when it is being
    brought down. This causes an event to be allocated, but since the
    wdev is already removed from the rdev by the time that the event
    processing work executes, the event is never processed or freed.
    http://article.gmane.org/gmane.linux.kernel.wireless.general/95666

    Fix this leak, and other possible situations, by processing the event
    queue when a device is being unregistered. Thanks to Johannes Berg for
    the suggestion.

    Signed-off-by: Daniel Drake <dsd@laptop.org>
    Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f75ebd871f7f0a613fdb4e1231fbd540916872c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Aug 5 14:58:37 2012 +0000

    ARM: pxa: remove irq_to_gpio from ezx-pcap driver

    commit 59ee93a528b94ef4e81a08db252b0326feff171f upstream.

    The irq_to_gpio function was removed from the pxa platform
    in linux-3.2, and this driver has been broken since.

    There is actually no in-tree user of this driver that adds
    this platform device, but the driver can and does get enabled
    on some platforms.

    Without this patch, building ezx_defconfig results in:

    drivers/mfd/ezx-pcap.c: In function 'pcap_isr_work':
    drivers/mfd/ezx-pcap.c:205:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
    Cc: Samuel Ortiz <sameo@linux.intel.com>
    Cc: Daniel Ribeiro <drwyrm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c75f1f090ef88416c6e299b6cb07edcabe11575b
Author: Marek Vasut <marex@denx.de>
Date:   Fri Aug 3 20:54:48 2012 +0200

    ARM: mxs: Remove MMAP_MIN_ADDR setting from mxs_defconfig

    commit 3bed491c8d28329e34f8a31e3fe64d03f3a350f1 upstream.

    The CONFIG_DEFAULT_MMAP_MIN_ADDR was set to 65536 in mxs_defconfig,
    this caused severe breakage of userland applications since the upper
    limit for ARM is 32768. By default CONFIG_DEFAULT_MMAP_MIN_ADDR is
    set to 4096 and can also be changed via /proc/sys/vm/mmap_min_addr
    if needed.

    Quoting Russell King [1]:

    "4096 is also fine for ARM too. There's not much point in having
    defconfigs change it - that would just be pure noise in the config
    files."

    the CONFIG_DEFAULT_MMAP_MIN_ADDR can be removed from the defconfig
    altogether.

    This problem was introduced by commit cde7c41 (ARM: configs: add
    defconfig for mach-mxs).

    [1] http://marc.info/?l=linux-arm-kernel&m=134401593807820&w=2

    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Wolfgang Denk <wd@denx.de>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c9682c5269e3c63ef9009ad20ea4e150370b7e0
Author: Mel Gorman <mgorman@suse.de>
Date:   Tue Jul 31 16:46:20 2012 -0700

    mm: hugetlbfs: close race during teardown of hugetlbfs shared page tables

    commit d833352a4338dc31295ed832a30c9ccff5c7a183 upstream.

    If a process creates a large hugetlbfs mapping that is eligible for page
    table sharing and forks heavily with children some of whom fault and
    others which destroy the mapping then it is possible for page tables to
    get corrupted.  Some teardowns of the mapping encounter a "bad pmd" and
    output a message to the kernel log.  The final teardown will trigger a
    BUG_ON in mm/filemap.c.

    This was reproduced in 3.4 but is known to have existed for a long time
    and goes back at least as far as 2.6.37.  It was probably was introduced
    in 2.6.20 by [39dde65c: shared page table for hugetlb page].  The messages
    look like this;

    [  ..........] Lots of bad pmd messages followed by this
    [  127.164256] mm/memory.c:391: bad pmd ffff880412e04fe8(80000003de4000e7).
    [  127.164257] mm/memory.c:391: bad pmd ffff880412e04ff0(80000003de6000e7).
    [  127.164258] mm/memory.c:391: bad pmd ffff880412e04ff8(80000003de0000e7).
    [  127.186778] ------------[ cut here ]------------
    [  127.186781] kernel BUG at mm/filemap.c:134!
    [  127.186782] invalid opcode: 0000 [#1] SMP
    [  127.186783] CPU 7
    [  127.186784] Modules linked in: af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf ext3 jbd dm_mod coretemp crc32c_intel usb_storage ghash_clmulni_intel aesni_intel i2c_i801 r8169 mii uas sr_mod cdrom sg iTCO_wdt iTCO_vendor_support shpchp serio_raw cryptd aes_x86_64 e1000e pci_hotplug dcdbas aes_generic container microcode ext4 mbcache jbd2 crc16 sd_mod crc_t10dif i915 drm_kms_helper drm i2c_algo_bit ehci_hcd ahci libahci usbcore rtc_cmos usb_common button i2c_core intel_agp video intel_gtt fan processor thermal thermal_sys hwmon ata_generic pata_atiixp libata scsi_mod
    [  127.186801]
    [  127.186802] Pid: 9017, comm: hugetlbfs-test Not tainted 3.4.0-autobuild #53 Dell Inc. OptiPlex 990/06D7TR
    [  127.186804] RIP: 0010:[<ffffffff810ed6ce>]  [<ffffffff810ed6ce>] __delete_from_page_cache+0x15e/0x160
    [  127.186809] RSP: 0000:ffff8804144b5c08  EFLAGS: 00010002
    [  127.186810] RAX: 0000000000000001 RBX: ffffea000a5c9000 RCX: 00000000ffffffc0
    [  127.186811] RDX: 0000000000000000 RSI: 0000000000000009 RDI: ffff88042dfdad00
    [  127.186812] RBP: ffff8804144b5c18 R08: 0000000000000009 R09: 0000000000000003
    [  127.186813] R10: 0000000000000000 R11: 000000000000002d R12: ffff880412ff83d8
    [  127.186814] R13: ffff880412ff83d8 R14: 0000000000000000 R15: ffff880412ff83d8
    [  127.186815] FS:  00007fe18ed2c700(0000) GS:ffff88042dce0000(0000) knlGS:0000000000000000
    [  127.186816] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [  127.186817] CR2: 00007fe340000503 CR3: 0000000417a14000 CR4: 00000000000407e0
    [  127.186818] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  127.186819] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  127.186820] Process hugetlbfs-test (pid: 9017, threadinfo ffff8804144b4000, task ffff880417f803c0)
    [  127.186821] Stack:
    [  127.186822]  ffffea000a5c9000 0000000000000000 ffff8804144b5c48 ffffffff810ed83b
    [  127.186824]  ffff8804144b5c48 000000000000138a 0000000000001387 ffff8804144b5c98
    [  127.186825]  ffff8804144b5d48 ffffffff811bc925 ffff8804144b5cb8 0000000000000000
    [  127.186827] Call Trace:
    [  127.186829]  [<ffffffff810ed83b>] delete_from_page_cache+0x3b/0x80
    [  127.186832]  [<ffffffff811bc925>] truncate_hugepages+0x115/0x220
    [  127.186834]  [<ffffffff811bca43>] hugetlbfs_evict_inode+0x13/0x30
    [  127.186837]  [<ffffffff811655c7>] evict+0xa7/0x1b0
    [  127.186839]  [<ffffffff811657a3>] iput_final+0xd3/0x1f0
    [  127.186840]  [<ffffffff811658f9>] iput+0x39/0x50
    [  127.186842]  [<ffffffff81162708>] d_kill+0xf8/0x130
    [  127.186843]  [<ffffffff81162812>] dput+0xd2/0x1a0
    [  127.186845]  [<ffffffff8114e2d0>] __fput+0x170/0x230
    [  127.186848]  [<ffffffff81236e0e>] ? rb_erase+0xce/0x150
    [  127.186849]  [<ffffffff8114e3ad>] fput+0x1d/0x30
    [  127.186851]  [<ffffffff81117db7>] remove_vma+0x37/0x80
    [  127.186853]  [<ffffffff81119182>] do_munmap+0x2d2/0x360
    [  127.186855]  [<ffffffff811cc639>] sys_shmdt+0xc9/0x170
    [  127.186857]  [<ffffffff81410a39>] system_call_fastpath+0x16/0x1b
    [  127.186858] Code: 0f 1f 44 00 00 48 8b 43 08 48 8b 00 48 8b 40 28 8b b0 40 03 00 00 85 f6 0f 88 df fe ff ff 48 89 df e8 e7 cb 05 00 e9 d2 fe ff ff <0f> 0b 55 83 e2 fd 48 89 e5 48 83 ec 30 48 89 5d d8 4c 89 65 e0
    [  127.186868] RIP  [<ffffffff810ed6ce>] __delete_from_page_cache+0x15e/0x160
    [  127.186870]  RSP <ffff8804144b5c08>
    [  127.186871] ---[ end trace 7cbac5d1db69f426 ]---

    The bug is a race and not always easy to reproduce.  To reproduce it I was
    doing the following on a single socket I7-based machine with 16G of RAM.

    $ hugeadm --pool-pages-max DEFAULT:13G
    $ echo $((18*1048576*1024)) > /proc/sys/kernel/shmmax
    $ echo $((18*1048576*1024)) > /proc/sys/kernel/shmall
    $ for i in `seq 1 9000`; do ./hugetlbfs-test; done

    On my particular machine, it usually triggers within 10 minutes but
    enabling debug options can change the timing such that it never hits.
    Once the bug is triggered, the machine is in trouble and needs to be
    rebooted.  The machine will respond but processes accessing proc like "ps
    aux" will hang due to the BUG_ON.  shutdown will also hang and needs a
    hard reset or a sysrq-b.

    The basic problem is a race between page table sharing and teardown.  For
    the most part page table sharing depends on i_mmap_mutex.  In some cases,
    it is also taking the mm->page_table_lock for the PTE updates but with
    shared page tables, it is the i_mmap_mutex that is more important.

    Unfortunately it appears to be also insufficient. Consider the following
    situation

    Process A					Process B
    ---------					---------
    hugetlb_fault					shmdt
      						LockWrite(mmap_sem)
        						  do_munmap
    						    unmap_region
    						      unmap_vmas
    						        unmap_single_vma
    						          unmap_hugepage_range
          						            Lock(i_mmap_mutex)
    							    Lock(mm->page_table_lock)
    							    huge_pmd_unshare/unmap tables <--- (1)
    							    Unlock(mm->page_table_lock)
          						            Unlock(i_mmap_mutex)
      huge_pte_alloc				      ...
        Lock(i_mmap_mutex)				      ...
        vma_prio_walk, find svma, spte		      ...
        Lock(mm->page_table_lock)			      ...
        share spte					      ...
        Unlock(mm->page_table_lock)			      ...
        Unlock(i_mmap_mutex)			      ...
      hugetlb_no_page									  <--- (2)
    						      free_pgtables
    						        unlink_file_vma
    							hugetlb_free_pgd_range
    						    remove_vma_list

    In this scenario, it is possible for Process A to share page tables with
    Process B that is trying to tear them down.  The i_mmap_mutex on its own
    does not prevent Process A walking Process B's page tables.  At (1) above,
    the page tables are not shared yet so it unmaps the PMDs.  Process A sets
    up page table sharing and at (2) faults a new entry.  Process B then trips
    up on it in free_pgtables.

    This patch fixes the problem by adding a new function
    __unmap_hugepage_range_final that is only called when the VMA is about to
    be destroyed.  This function clears VM_MAYSHARE during
    unmap_hugepage_range() under the i_mmap_mutex.  This makes the VMA
    ineligible for sharing and avoids the race.  Superficially this looks like
    it would then be vunerable to truncate and madvise issues but hugetlbfs
    has its own truncate handlers so does not use unmap_mapping_range() and
    does not support madvise(DONTNEED).

    This should be treated as a -stable candidate if it is merged.

    Test program is as follows. The test case was mostly written by Michal
    Hocko with a few minor changes to reproduce this bug.

    ==== CUT HERE ====

    static size_t huge_page_size = (2UL << 20);
    static size_t nr_huge_page_A = 512;
    static size_t nr_huge_page_B = 5632;

    unsigned int get_random(unsigned int max)
    {
    	struct timeval tv;

    	gettimeofday(&tv, NULL);
    	srandom(tv.tv_usec);
    	return random() % max;
    }

    static void play(void *addr, size_t size)
    {
    	unsigned char *start = addr,
    		      *end = start + size,
    		      *a;
    	start += get_random(size/2);

    	/* we could itterate on huge pages but let's give it more time. */
    	for (a = start; a < end; a += 4096)
    		*a = 0;
    }

    int main(int argc, char **argv)
    {
    	key_t key = IPC_PRIVATE;
    	size_t sizeA = nr_huge_page_A * huge_page_size;
    	size_t sizeB = nr_huge_page_B * huge_page_size;
    	int shmidA, shmidB;
    	void *addrA = NULL, *addrB = NULL;
    	int nr_children = 300, n = 0;

    	if ((shmidA = shmget(key, sizeA, IPC_CREAT|SHM_HUGETLB|0660)) == -1) {
    		perror("shmget:");
    		return 1;
    	}

    	if ((addrA = shmat(shmidA, addrA, SHM_R|SHM_W)) == (void *)-1UL) {
    		perror("shmat");
    		return 1;
    	}
    	if ((shmidB = shmget(key, sizeB, IPC_CREAT|SHM_HUGETLB|0660)) == -1) {
    		perror("shmget:");
    		return 1;
    	}

    	if ((addrB = shmat(shmidB, addrB, SHM_R|SHM_W)) == (void *)-1UL) {
    		perror("shmat");
    		return 1;
    	}

    fork_child:
    	switch(fork()) {
    		case 0:
    			switch (n%3) {
    			case 0:
    				play(addrA, sizeA);
    				break;
    			case 1:
    				play(addrB, sizeB);
    				break;
    			case 2:
    				break;
    			}
    			break;
    		case -1:
    			perror("fork:");
    			break;
    		default:
    			if (++n < nr_children)
    				goto fork_child;
    			play(addrA, sizeA);
    			break;
    	}
    	shmdt(addrA);
    	shmdt(addrB);
    	do {
    		wait(NULL);
    	} while (--n > 0);
    	shmctl(shmidA, IPC_RMID, NULL);
    	shmctl(shmidB, IPC_RMID, NULL);
    	return 0;
    }

    [akpm@linux-foundation.org: name the declaration's args, fix CONFIG_HUGETLBFS=n build]
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb014c405d5e6d92fd9617bdfc29b29ad2bf6588
Author: Borislav Petkov <borislav.petkov@amd.com>
Date:   Thu Jun 21 14:07:16 2012 +0200

    x86, microcode: Sanitize per-cpu microcode reloading interface

    commit c9fc3f778a6a215ace14ee556067c73982b6d40f upstream.

    Microcode reloading in a per-core manner is a very bad idea for both
    major x86 vendors. And the thing is, we have such interface with which
    we can end up with different microcode versions applied on different
    cores of an otherwise homogeneous wrt (family,model,stepping) system.

    So turn off the possibility of doing that per core and allow it only
    system-wide.

    This is a minimal fix which we'd like to see in stable too thus the
    more-or-less arbitrary decision to allow system-wide reloading only on
    the BSP:

    $ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload
    ...

    and disable the interface on the other cores:

    $ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload
    -bash: echo: write error: Invalid argument

    Also, allowing the reload only from one CPU (the BSP in
    that case) doesn't allow the reload procedure to degenerate
    into an O(n^2) deal when triggering reloads from all
    /sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
    simultaneously.

    A more generic fix will follow.

    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1340280437-7718-2-git-send-email-bp@amd64.org
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d426c78930e6e01373e3007df81161855f5b6ec1
Author: Shuah Khan <shuahkhan@gmail.com>
Date:   Sun May 6 11:11:04 2012 -0600

    x86, microcode: microcode_core.c simple_strtoul cleanup

    commit e826abd523913f63eb03b59746ffb16153c53dc4 upstream.

    Change reload_for_cpu() in kernel/microcode_core.c to call kstrtoul()
    instead of calling obsoleted simple_strtoul().

    Signed-off-by: Shuah Khan <shuahkhan@gmail.com>
    Reviewed-by: Borislav Petkov <bp@alien8.de>
    Link: http://lkml.kernel.org/r/1336324264.2897.9.camel@lorien2
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f6082404e1d17ea7a9745c141dd91dba2102c57
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Fri Jul 27 22:26:08 2012 -0400

    random: mix in architectural randomness in extract_buf()

    commit d2e7c96af1e54b507ae2a6a7dd2baf588417a7e5 upstream.

    Mix in any architectural randomness in extract_buf() instead of
    xfer_secondary_buf().  This allows us to mix in more architectural
    randomness, and it also makes xfer_secondary_buf() faster, moving a
    tiny bit of additional CPU overhead to process which is extracting the
    randomness.

    [ Commit description modified by tytso to remove an extended
      advertisement for the RDRAND instruction. ]

    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: DJ Johnston <dj.johnston@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f4cb6f72c4e95cac32316b2be4a0b344513910a
Author: Tony Luck <tony.luck@intel.com>
Date:   Fri Jul 20 13:15:20 2012 -0700

    dmi: Feed DMI table to /dev/random driver

    commit d114a33387472555188f142ed8e98acdb8181c6d upstream.

    Send the entire DMI (SMBIOS) table to the /dev/random driver to
    help seed its pools.

    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbbdd2bb89716814a5336105d8b3e6fd64ff0886
Author: Tony Luck <tony.luck@intel.com>
Date:   Mon Jul 23 09:47:57 2012 -0700

    random: Add comment to random_initialize()

    commit cbc96b7594b5691d61eba2db8b2ea723645be9ca upstream.

    Many platforms have per-machine instance data (serial numbers,
    asset tags, etc.) squirreled away in areas that are accessed
    during early system bringup. Mixing this data into the random
    pools has a very high value in providing better random data,
    so we should allow (and even encourage) architecture code to
    call add_device_randomness() from the setup_arch() paths.

    However, this limits our options for internal structure of
    the random driver since random_initialize() is not called
    until long after setup_arch().

    Add a big fat comment to rand_initialize() spelling out
    this requirement.

    Suggested-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6b847a93be87fc9974d8232984668a5a59754df
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Jul 14 20:27:52 2012 -0400

    random: remove rand_initialize_irq()

    commit c5857ccf293968348e5eb4ebedc68074de3dcda6 upstream.

    With the new interrupt sampling system, we are no longer using the
    timer_rand_state structure in the irq descriptor, so we can stop
    initializing it now.

    [ Merged in fixes from Sedat to find some last missing references to
      rand_initialize_irq() ]

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f99ef862a7235bb06e963bd99e3c4287f5b8f6fd
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Thu Jul 5 20:23:21 2012 +0000

    mfd: wm831x: Feed the device UUID into device_add_randomness()

    commit 27130f0cc3ab97560384da437e4621fc4e94f21c upstream.

    wm831x devices contain a unique ID value. Feed this into the newly added
    device_add_randomness() to add some per device seed data to the pool.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fcadd93622a8e130d98dd214aa75a17fc9b0ffc
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Thu Jul 5 20:19:17 2012 +0000

    rtc: wm831x: Feed the write counter into device_add_randomness()

    commit 9dccf55f4cb011a7552a8a2749a580662f5ed8ed upstream.

    The tamper evident features of the RTC include the "write counter" which
    is a pseudo-random number regenerated whenever we set the RTC. Since this
    value is unpredictable it should provide some useful seeding to the random
    number generator.

    Only do this on boot since the goal is to seed the pool rather than add
    useful entropy.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0789520922496716eff4381e0ef724e66ead63e5
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Jul 4 11:32:48 2012 -0400

    MAINTAINERS: Theodore Ts'o is taking over the random driver

    commit 330e0a01d54c2b8606c56816f99af6ebc58ec92c upstream.

    Matt Mackall stepped down as the /dev/random driver maintainer last
    year, so Theodore Ts'o is taking back the /dev/random driver.

    Cc: Matt Mackall <mpm@selenic.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1edbd889fa5c0343d817ae6fe44ab95870a096b4
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Jul 4 16:19:30 2012 -0400

    random: add tracepoints for easier debugging and verification

    commit 00ce1db1a634746040ace24c09a4e3a7949a3145 upstream.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efe6c422db90b8303bfaf7fc2131bb2824a06c39
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Jul 5 10:35:23 2012 -0400

    random: add new get_random_bytes_arch() function

    commit c2557a303ab6712bb6e09447df828c557c710ac9 upstream.

    Create a new function, get_random_bytes_arch() which will use the
    architecture-specific hardware random number generator if it is
    present.  Change get_random_bytes() to not use the HW RNG, even if it
    is avaiable.

    The reason for this is that the hw random number generator is fast (if
    it is present), but it requires that we trust the hardware
    manufacturer to have not put in a back door.  (For example, an
    increasing counter encrypted by an AES key known to the NSA.)

    It's unlikely that Intel (for example) was paid off by the US
    Government to do this, but it's impossible for them to prove otherwise
      --- especially since Bull Mountain is documented to use AES as a
    whitener.  Hence, the output of an evil, trojan-horse version of
    RDRAND is statistically indistinguishable from an RDRAND implemented
    to the specifications claimed by Intel.  Short of using a tunnelling
    electronic microscope to reverse engineer an Ivy Bridge chip and
    disassembling and analyzing the CPU microcode, there's no way for us
    to tell for sure.

    Since users of get_random_bytes() in the Linux kernel need to be able
    to support hardware systems where the HW RNG is not present, most
    time-sensitive users of this interface have already created their own
    cryptographic RNG interface which uses get_random_bytes() as a seed.
    So it's much better to use the HW RNG to improve the existing random
    number generator, by mixing in any entropy returned by the HW RNG into
    /dev/random's entropy pool, but to always _use_ /dev/random's entropy
    pool.

    This way we get almost of the benefits of the HW RNG without any
    potential liabilities.  The only benefits we forgo is the
    speed/performance enhancements --- and generic kernel code can't
    depend on depend on get_random_bytes() having the speed of a HW RNG
    anyway.

    For those places that really want access to the arch-specific HW RNG,
    if it is available, we provide get_random_bytes_arch().

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2b6f1202d6f948bfe8d280dec83da1fef05a05c
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Jul 5 10:21:01 2012 -0400

    random: use the arch-specific rng in xfer_secondary_pool

    commit e6d4947b12e8ad947add1032dd754803c6004824 upstream.

    If the CPU supports a hardware random number generator, use it in
    xfer_secondary_pool(), where it will significantly improve things and
    where we can afford it.

    Also, remove the use of the arch-specific rng in
    add_timer_randomness(), since the call is significantly slower than
    get_cycles(), and we're much better off using it in
    xfer_secondary_pool() anyway.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 118f98c7de67622c27ef9c968958b6de8483357f
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Jul 4 21:23:25 2012 -0400

    net: feed /dev/random with the MAC address when registering a device

    commit 7bf2357524408b97fec58344caf7397f8140c3fd upstream.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: David Miller <davem@davemloft.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52d1114f461ad4d33d8bc38987b5991161712e96
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Jul 4 11:22:20 2012 -0400

    usb: feed USB device information to the /dev/random driver

    commit b04b3156a20d395a7faa8eed98698d1e17a36000 upstream.

    Send the USB device's serial, product, and manufacturer strings to the
    /dev/random driver to help seed its pools.

    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: Greg KH <greg@kroah.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e035335b0578f6a058aecaf817b462ec9773c24
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jul 4 11:16:01 2012 -0400

    random: create add_device_randomness() interface

    commit a2080a67abe9e314f9e9c2cc3a4a176e8a8f8793 upstream.

    Add a new interface, add_device_randomness() for adding data to the
    random pool that is likely to differ between two devices (or possibly
    even per boot).  This would be things like MAC addresses or serial
    numbers, or the read-out of the RTC. This does *not* add any actual
    entropy to the pool, but it initializes the pool to different values
    for devices that might otherwise be identical and have very little
    entropy available to them (particularly common in the embedded world).

    [ Modified by tytso to mix in a timestamp, since there may be some
      variability caused by the time needed to detect/configure the hardware
      in question. ]

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebb6006e3be88bb15328887dec4a8c3b7c0138b6
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Jul 4 10:38:30 2012 -0400

    random: use lockless techniques in the interrupt path

    commit 902c098a3663de3fa18639efbb71b6080f0bcd3c upstream.

    The real-time Linux folks don't like add_interrupt_randomness() taking
    a spinlock since it is called in the low-level interrupt routine.
    This also allows us to reduce the overhead in the fast path, for the
    random driver, which is the interrupt collection path.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa88dea2270f685349ab7b92169600452fe73b62
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Jul 2 07:52:16 2012 -0400

    random: make 'add_interrupt_randomness()' do something sane

    commit 775f4b297b780601e61787b766f306ed3e1d23eb upstream.

    We've been moving away from add_interrupt_randomness() for various
    reasons: it's too expensive to do on every interrupt, and flooding the
    CPU with interrupts could theoretically cause bogus floods of entropy
    from a somewhat externally controllable source.

    This solves both problems by limiting the actual randomness addition
    to just once a second or after 64 interrupts, whicever comes first.
    During that time, the interrupt cycle data is buffered up in a per-cpu
    pool.  Also, we make sure the the nonblocking pool used by urandom is
    initialized before we start feeding the normal input pool.  This
    assures that /dev/urandom is returning unpredictable data as soon as
    possible.

    (Based on an original patch by Linus, but significantly modified by
    tytso.)

    Tested-by: Eric Wustrow <ewust@umich.edu>
    Reported-by: Eric Wustrow <ewust@umich.edu>
    Reported-by: Nadia Heninger <nadiah@cs.ucsd.edu>
    Reported-by: Zakir Durumeric <zakir@umich.edu>
    Reported-by: J. Alex Halderman <jhalderm@umich.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5a1367c1bc150e70e8db9bb6f2892e8e31648c7
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Thu Apr 12 12:49:12 2012 -0700

    drivers/char/random.c: fix boot id uniqueness race

    commit 44e4360fa3384850d65dd36fb4e6e5f2f112709b upstream.

    /proc/sys/kernel/random/boot_id can be read concurrently by userspace
    processes.  If two (or more) user-space processes concurrently read
    boot_id when sysctl_bootid is not yet assigned, a race can occur making
    boot_id differ between the reads.  Because the whole point of the boot id
    is to be unique across a kernel execution, fix this by protecting this
    operation with a spinlock.

    Given that this operation is not frequently used, hitting the spinlock
    on each call should not be an issue.

    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Matt Mackall <mpm@selenic.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5914eb0c34cf8b2d777c3dca852b2595dec908c
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Mon Jan 16 11:23:29 2012 -0800

    random: Adjust the number of loops when initializing

    commit 2dac8e54f988ab58525505d7ef982493374433c3 upstream.

    When we are initializing using arch_get_random_long() we only need to
    loop enough times to touch all the bytes in the buffer; using
    poolwords for that does twice the number of operations necessary on a
    64-bit machine, since in the random number generator code "word" means
    32 bits.

    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d191959fa812fadb86b52f16aa09a49fe6db98dd
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Dec 22 16:28:01 2011 -0500

    random: Use arch-specific RNG to initialize the entropy store

    commit 3e88bdff1c65145f7ba297ccec69c774afe4c785 upstream.

    If there is an architecture-specific random number generator (such as
    RDRAND for Intel architectures), use it to initialize /dev/random's
    entropy stores.  Even in the worst case, if RDRAND is something like
    AES(NSA_KEY, counter++), it won't hurt, and it will definitely help
    against any other adversaries.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.edu
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be0052b8995dfa8d43a94badd54254e8cfc59471
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Dec 22 11:36:22 2011 -0800

    random: Use arch_get_random_int instead of cycle counter if avail

    commit cf833d0b9937874b50ef2867c4e8badfd64948ce upstream.

    We still don't use rdrand in /dev/random, which just seems stupid. We
    accept the *cycle*counter* as a random input, but we don't accept
    rdrand? That's just broken.

    Sure, people can do things in user space (write to /dev/random, use
    rdrand in addition to /dev/random themselves etc etc), but that
    *still* seems to be a particularly stupid reason for saying "we
    shouldn't bother to try to do better in /dev/random".

    And even if somebody really doesn't trust rdrand as a source of random
    bytes, it seems singularly stupid to trust the cycle counter *more*.

    So I'd suggest the attached patch. I'm not going to even bother
    arguing that we should add more bits to the entropy estimate, because
    that's not the point - I don't care if /dev/random fills up slowly or
    not, I think it's just stupid to not use the bits we can get from
    rdrand and mix them into the strong randomness pool.

    Link: http://lkml.kernel.org/r/CA%2B55aFwn59N1=m651QAyTy-1gO1noGbK18zwKDwvwqnravA84A@mail.gmail.com
    Acked-by: "David S. Miller" <davem@davemloft.net>
    Acked-by: "Theodore Ts'o" <tytso@mit.edu>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21a465d5868b83e17a1c2434864fbb95b6414481
Author: Luck, Tony <tony.luck@intel.com>
Date:   Wed Nov 16 10:50:56 2011 -0800

    fix typo/thinko in get_random_bytes()

    commit bd29e568a4cb6465f6e5ec7c1c1f3ae7d99cbec1 upstream.

    If there is an architecture-specific random number generator we use it
    to acquire randomness one "long" at a time.  We should put these random
    words into consecutive words in the result buffer - not just overwrite
    the first word again and again.

    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6133313b3bcbd0473feac85c8a8d7ef704ff2279
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Sun Jul 31 13:54:50 2011 -0700

    random: Add support for architectural random hooks

    commit 63d77173266c1791f1553e9e8ccea65dc87c4485 upstream.

    Add support for architecture-specific hooks into the kernel-directed
    random number generator interfaces.  This patchset does not use the
    architecture random number generator interfaces for the
    userspace-directed interfaces (/dev/random and /dev/urandom), thus
    eliminating the need to distinguish between them based on a pool
    pointer.

    Changes in version 3:
    - Moved the hooks from extract_entropy() to get_random_bytes().
    - Changes the hooks to inlines.

    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b1cad628030b9bbdaaa4bb8ff73cabaab6e82c9
Author: Alan Cox <alan@linux.intel.com>
Date:   Wed Jul 25 16:28:19 2012 +0100

    x86, nops: Missing break resulting in incorrect selection on Intel

    commit d6250a3f12edb3a86db9598ffeca3de8b4a219e9 upstream.

    The Intel case falls through into the generic case which then changes
    the values.  For cases like the P6 it doesn't do the right thing so
    this seems to be a screwup.

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Link: http://lkml.kernel.org/n/tip-lww2uirad4skzjlmrm0vru8o@git.kernel.org
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61e0a9e79d85258d254c5bfb7832c40ba2c46ed4
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Aug 1 21:03:21 2012 +0200

    mac80211: cancel mesh path timer

    commit dd4c9260e7f23f2e951cbfb2726e468c6d30306c upstream.

    The mesh path timer needs to be canceled when
    leaving the mesh as otherwise it could fire
    after the interface has been removed already.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bda26e33846b53e2c70a2ccff13e3f5b69ab067
Author: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Date:   Tue Jul 31 16:45:52 2012 -0700

    mm: mmu_notifier: fix freed page still mapped in secondary MMU

    commit 3ad3d901bbcfb15a5e4690e55350db0899095a68 upstream.

    mmu_notifier_release() is called when the process is exiting.  It will
    delete all the mmu notifiers.  But at this time the page belonging to the
    process is still present in page tables and is present on the LRU list, so
    this race will happen:

          CPU 0                 CPU 1
    mmu_notifier_release:    try_to_unmap:
       hlist_del_init_rcu(&mn->hlist);
                                ptep_clear_flush_notify:
                                      mmu nofifler not found
                                free page  !!!!!!
                                /*
                                 * At the point, the page has been
                                 * freed, but it is still mapped in
                                 * the secondary MMU.
                                 */

      mn->ops->release(mn, mm);

    Then the box is not stable and sometimes we can get this bug:

    [  738.075923] BUG: Bad page state in process migrate-perf  pfn:03bec
    [  738.075931] page:ffffea00000efb00 count:0 mapcount:0 mapping:          (null) index:0x8076
    [  738.075936] page flags: 0x20000000000014(referenced|dirty)

    The same issue is present in mmu_notifier_unregister().

    We can call ->release before deleting the notifier to ensure the page has
    been unmapped from the secondary MMU before it is freed.

    Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
    Cc: Avi Kivity <avi@redhat.com>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9d316de7dc18de5df147597e3c38365ee1bfd6c
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jul 23 14:18:13 2012 +0100

    ARM: 7479/1: mm: avoid NULL dereference when flushing gate_vma with VIVT caches

    commit b74253f78400f9a4b42da84bb1de7540b88ce7c4 upstream.

    The vivt_flush_cache_{range,page} functions check that the mm_struct
    of the VMA being flushed has been active on the current CPU before
    performing the cache maintenance.

    The gate_vma has a NULL mm_struct pointer and, as such, will cause a
    kernel fault if we try to flush it with the above operations. This
    happens during ELF core dumps, which include the gate_vma as it may be
    useful for debugging purposes.

    This patch adds checks to the VIVT cache flushing functions so that VMAs
    with a NULL mm_struct are flushed unconditionally (the vectors page may
    be dirty if we use it to store the current TLS pointer).

    Reported-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
    Tested-by: Uros Bizjak <ubizjak@gmail.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@linuxfoundation.org>

commit 0b41a531bee76feefaa22878b035d8c71edcb87e
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jul 20 18:24:55 2012 +0100

    ARM: 7478/1: errata: extend workaround for erratum #720789

    commit 5a783cbc48367cfc7b65afc75430953dfe60098f upstream.

    Commit cdf357f1 ("ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS
    operations can broadcast a faulty ASID") replaced by-ASID TLB flushing
    operations with all-ASID variants to workaround A9 erratum #720789.

    This patch extends the workaround to include the tlb_range operations,
    which were overlooked by the original patch.

    Tested-by: Steve Capper <steve.capper@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@linuxfoundation.org>

commit cad33da5ceedac56481dd3168e42580e9bec6343
Author: Joonsoo Kim <js1304@gmail.com>
Date:   Mon Jul 30 14:39:04 2012 -0700

    mm: fix wrong argument of migrate_huge_pages() in soft_offline_huge_page()

    commit dc32f63453f56d07a1073a697dcd843dd3098c09 upstream.

    Commit a6bc32b89922 ("mm: compaction: introduce sync-light migration for
    use by compaction") changed the declaration of migrate_pages() and
    migrate_huge_pages().

    But it missed changing the argument of migrate_huge_pages() in
    soft_offline_huge_page().  In this case, we should call
    migrate_huge_pages() with MIGRATE_SYNC.

    Additionally, there is a mismatch between type the of argument and the
    function declaration for migrate_pages().

    Signed-off-by: Joonsoo Kim <js1304@gmail.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83c0c5e47281e4fb3eedf56fa8cf8b895aede0e0
Author: Greg Pearson <greg.pearson@hp.com>
Date:   Mon Jul 30 14:39:05 2012 -0700

    pcdp: use early_ioremap/early_iounmap to access pcdp table

    commit 6c4088ac3a4d82779903433bcd5f048c58fb1aca upstream.

    efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP
    EFI system table and setup an early console for printk output.  The
    routine uses ioremap/iounmap to setup access to the HCDP/PCDP table
    information.

    The call to ioremap is happening early in the boot process which leads
    to a panic on x86_64 systems:

        panic+0x01ca
        do_exit+0x043c
        oops_end+0x00a7
        no_context+0x0119
        __bad_area_nosemaphore+0x0138
        bad_area_nosemaphore+0x000e
        do_page_fault+0x0321
        page_fault+0x0020
        reserve_memtype+0x02a1
        __ioremap_caller+0x0123
        ioremap_nocache+0x0012
        efi_setup_pcdp_console+0x002b
        setup_arch+0x03a9
        start_kernel+0x00d4
        x86_64_start_reservations+0x012c
        x86_64_start_kernel+0x00fe

    This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console()
    with calls to early_ioremap/early_iounmap which can be called during
    early boot.

    This patch was tested on an x86_64 prototype system which uses the
    HCDP/PCDP table for early console setup.

    Signed-off-by: Greg Pearson <greg.pearson@hp.com>
    Acked-by: Khalid Aziz <khalid.aziz@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85e937dcf1cc31e7f649c200ac3c3def01b54766
Author: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Date:   Mon Jul 30 14:42:07 2012 -0700

    nilfs2: fix deadlock issue between chcp and thaw ioctls

    commit 572d8b3945a31bee7c40d21556803e4807fd9141 upstream.

    An fs-thaw ioctl causes deadlock with a chcp or mkcp -s command:

     chcp            D ffff88013870f3d0     0  1325   1324 0x00000004
     ...
     Call Trace:
       nilfs_transaction_begin+0x11c/0x1a0 [nilfs2]
       wake_up_bit+0x20/0x20
       copy_from_user+0x18/0x30 [nilfs2]
       nilfs_ioctl_change_cpmode+0x7d/0xcf [nilfs2]
       nilfs_ioctl+0x252/0x61a [nilfs2]
       do_page_fault+0x311/0x34c
       get_unmapped_area+0x132/0x14e
       do_vfs_ioctl+0x44b/0x490
       __set_task_blocked+0x5a/0x61
       vm_mmap_pgoff+0x76/0x87
       __set_current_blocked+0x30/0x4a
       sys_ioctl+0x4b/0x6f
       system_call_fastpath+0x16/0x1b
     thaw            D ffff88013870d890     0  1352   1351 0x00000004
     ...
     Call Trace:
       rwsem_down_failed_common+0xdb/0x10f
       call_rwsem_down_write_failed+0x13/0x20
       down_write+0x25/0x27
       thaw_super+0x13/0x9e
       do_vfs_ioctl+0x1f5/0x490
       vm_mmap_pgoff+0x76/0x87
       sys_ioctl+0x4b/0x6f
       filp_close+0x64/0x6c
       system_call_fastpath+0x16/0x1b

    where the thaw ioctl deadlocked at thaw_super() when called while chcp was
    waiting at nilfs_transaction_begin() called from
    nilfs_ioctl_change_cpmode().  This deadlock is 100% reproducible.

    This is because nilfs_ioctl_change_cpmode() first locks sb->s_umount in
    read mode and then waits for unfreezing in nilfs_transaction_begin(),
    whereas thaw_super() locks sb->s_umount in write mode.  The locking of
    sb->s_umount here was intended to make snapshot mounts and the downgrade
    of snapshots to checkpoints exclusive.

    This fixes the deadlock issue by replacing the sb->s_umount usage in
    nilfs_ioctl_change_cpmode() with a dedicated mutex which protects snapshot
    mounts.

    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Cc: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d90c97ba987ab9f1c0a1e11697269814386243b9
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Fri Jul 20 15:57:48 2012 +0400

    SUNRPC: return negative value in case rpcbind client creation error

    commit caea33da898e4e14f0ba58173e3b7689981d2c0b upstream.

    Without this patch kernel will panic on LockD start, because lockd_up() checks
    lockd_up_net() result for negative value.
    From my pow it's better to return negative value from rpcbind routines instead
    of replacing all such checks like in lockd_up().

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bf75ed61c9715435661971acd4e181c26f2af20
Author: Tony Luck <tony.luck@intel.com>
Date:   Thu Jul 26 10:55:26 2012 -0700

    Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

    commit a119365586b0130dfea06457f584953e0ff6481d upstream.

    The following build error occured during a ia64 build with
    swap-over-NFS patches applied.

    net/core/sock.c:274:36: error: initializer element is not constant
    net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
    net/core/sock.c:274:36: error: initializer element is not constant

    This is identical to a parisc build error. Fengguang Wu, Mel Gorman
    and James Bottomley did all the legwork to track the root cause of
    the problem. This fix and entire commit log is shamelessly copied
    from them with one extra detail to change a dubious runtime use of
    ATOMIC_INIT() to atomic_set() in drivers/char/mspec.c

    Dave Anglin says:
    > Here is the line in sock.i:
    >
    > struct static_key memalloc_socks = ((struct static_key) { .enabled =
    > ((atomic_t) { (0) }) });

    The above line contains two compound literals.  It also uses a designated
    initializer to initialize the field enabled.  A compound literal is not a
    constant expression.

    The location of the above statement isn't fully clear, but if a compound
    literal occurs outside the body of a function, the initializer list must
    consist of constant expressions.

    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22268214261ad64783cbad1d9c1df227302e5ed1
Author: Kevin Winchester <kjwinchester@gmail.com>
Date:   Tue Aug 14 21:26:54 2012 -0300

    x86: Simplify code by removing a !SMP #ifdefs from 'struct cpuinfo_x86'

    commit 141168c36cdee3ff23d9c7700b0edc47cb65479f and
    commit 3f806e50981825fa56a7f1938f24c0680816be45 upstream.

    Several fields in struct cpuinfo_x86 were not defined for the
    !SMP case, likely to save space.  However, those fields still
    have some meaning for UP, and keeping them allows some #ifdef
    removal from other files.  The additional size of the UP kernel
    from this change is not significant enough to worry about
    keeping up the distinction:

    	   text    data     bss     dec     hex filename
    	4737168	 506459	 972040	6215667	 5ed7f3	vmlinux.o.before
    	4737444	 506459	 972040	6215943	 5ed907	vmlinux.o.after

    for a difference of 276 bytes for an example UP config.

    If someone wants those 276 bytes back badly then it should
    be implemented in a cleaner way.

    Signed-off-by: Kevin Winchester <kjwinchester@gmail.com>
    Cc: Steffen Persvold <sp@numascale.com>
    Link: http://lkml.kernel.org/r/1324428742-12498-1-git-send-email-kjwinchester@gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>