Skip to content
Commits on Aug 15, 2012
  1. @gregkh

    Linux 3.0.41

    gregkh committed Aug 15, 2012
  2. @sgruszka @gregkh

    rt61pci: fix NULL pointer dereference in config_lna_gain

    sgruszka committed with gregkh Aug 3, 2012
    commit deee021 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>
  3. @cbagwell @gregkh

    Input: wacom - Bamboo One 1024 pressure fix

    cbagwell committed with gregkh Jun 12, 2012
    commit 6dc4635 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>
  4. @gregkh

    e1000e: NIC goes up and immediately goes down

    Tushar Dave committed with gregkh Jul 31, 2012
    commit b7ec70b upstream.
    
    Found that commit d478eb4 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>
  5. @gregkh

    cfg80211: fix interface combinations check for ADHOC(IBSS)

    Liang Li committed with gregkh Aug 2, 2012
    partial of commit 8e8b41f upstream.
    
    As part of commit 463454b ("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 8e8b41f ("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 8e8b41f 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 8e8b41f here.
    
    Doing so gives stable kernels a way to fix the change introduced
    by 463454b, 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>
  6. @gregkh

    cfg80211: process pending events when unregistering net device

    Daniel Drake committed with gregkh Aug 2, 2012
    commit 1f6fc43 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>
  7. @arndb @gregkh

    ARM: pxa: remove irq_to_gpio from ezx-pcap driver

    arndb committed with gregkh Aug 5, 2012
    commit 59ee93a 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>
  8. @gregkh

    ARM: mxs: Remove MMAP_MIN_ADDR setting from mxs_defconfig

    Marek Vasut committed with gregkh Aug 3, 2012
    commit 3bed491 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>
  9. @gregkh

    mm: hugetlbfs: close race during teardown of hugetlbfs shared page ta…

    Mel Gorman committed with gregkh Jul 31, 2012
    …bles
    
    commit d833352 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 [39dde65: 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>
  10. @gregkh

    x86, microcode: Sanitize per-cpu microcode reloading interface

    Borislav Petkov committed with gregkh Jun 21, 2012
    commit c9fc3f7 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>
  11. @shuahkh @gregkh

    x86, microcode: microcode_core.c simple_strtoul cleanup

    shuahkh committed with gregkh May 6, 2012
    commit e826abd 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>
  12. @gregkh

    random: mix in architectural randomness in extract_buf()

    H. Peter Anvin committed with gregkh Jul 27, 2012
    commit d2e7c96 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>
  13. @gregkh

    dmi: Feed DMI table to /dev/random driver

    Tony Luck committed with gregkh Jul 20, 2012
    commit d114a33 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>
  14. @gregkh

    random: Add comment to random_initialize()

    Tony Luck committed with gregkh Jul 23, 2012
    commit cbc96b7 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>
  15. @tytso @gregkh

    random: remove rand_initialize_irq()

    tytso committed with gregkh Jul 14, 2012
    commit c5857cc 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>
  16. @broonie @gregkh

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

    broonie committed with gregkh Jul 5, 2012
    commit 27130f0 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>
  17. @broonie @gregkh

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

    broonie committed with gregkh Jul 5, 2012
    commit 9dccf55 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>
  18. @tytso @gregkh

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

    tytso committed with gregkh Jul 4, 2012
    commit 330e0a0 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>
  19. @tytso @gregkh

    random: add tracepoints for easier debugging and verification

    tytso committed with gregkh Jul 4, 2012
    commit 00ce1db upstream.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. @tytso @gregkh

    random: add new get_random_bytes_arch() function

    tytso committed with gregkh Jul 5, 2012
    commit c2557a3 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>
  21. @tytso @gregkh

    random: use the arch-specific rng in xfer_secondary_pool

    tytso committed with gregkh Jul 5, 2012
    commit e6d4947 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>
  22. @tytso @gregkh

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

    tytso committed with gregkh Jul 4, 2012
    commit 7bf2357 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>
  23. @tytso @gregkh

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

    tytso committed with gregkh Jul 4, 2012
    commit b04b315 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>
  24. @torvalds @gregkh

    random: create add_device_randomness() interface

    torvalds committed with gregkh Jul 4, 2012
    commit a2080a6 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>
  25. @tytso @gregkh

    random: use lockless techniques in the interrupt path

    tytso committed with gregkh Jul 4, 2012
    commit 902c098 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>
  26. @tytso @gregkh

    random: make 'add_interrupt_randomness()' do something sane

    tytso committed with gregkh Jul 2, 2012
    commit 775f4b2 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>
  27. @compudj @gregkh

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

    compudj committed with gregkh Apr 12, 2012
    commit 44e4360 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>
  28. @gregkh

    random: Adjust the number of loops when initializing

    H. Peter Anvin committed with gregkh Jan 16, 2012
    commit 2dac8e5 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>
  29. @tytso @gregkh

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

    tytso committed with gregkh Dec 22, 2011
    commit 3e88bdf 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>
  30. @torvalds @gregkh

    random: Use arch_get_random_int instead of cycle counter if avail

    torvalds committed with gregkh Dec 22, 2011
    commit cf833d0 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>
  31. @gregkh

    fix typo/thinko in get_random_bytes()

    Luck, Tony committed with gregkh Nov 16, 2011
    commit bd29e56 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>
  32. @gregkh

    random: Add support for architectural random hooks

    H. Peter Anvin committed with gregkh Jul 31, 2011
    commit 63d7717 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>
  33. @gregkh

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

    Alan Cox committed with gregkh Jul 25, 2012
    commit d6250a3 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>
  34. @jmberg @gregkh

    mac80211: cancel mesh path timer

    jmberg committed with gregkh Aug 1, 2012
    commit dd4c926 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>
  35. @gregkh

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

    Xiao Guangrong committed with gregkh Jul 31, 2012
    commit 3ad3d90 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>
Something went wrong with that request. Please try again.