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

    Linux 3.5.2

    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. @arndb @gregkh

    Input: eeti_ts: pass gpio value instead of IRQ

    arndb committed with gregkh Apr 30, 2012
    commit 4eef6cb upstream.
    
    The EETI touchscreen asserts its IRQ line as soon as it has data in its
    internal buffers. The line is automatically deasserted once all data has
    been read via I2C. Hence, the driver has to monitor the GPIO line and
    cannot simply rely on the interrupt handler reception.
    
    In the current implementation of the driver, irq_to_gpio() is used to
    determine the GPIO number from the i2c_client's IRQ value.
    
    As irq_to_gpio() is not available on all platforms, this patch changes
    this and makes the driver ignore the passed in IRQ. Instead, a GPIO is
    added to the platform_data struct and gpio_to_irq is used to derive the
    IRQ from that GPIO. If this fails, bail out. The driver is only able to
    work in environments where the touchscreen GPIO can be mapped to an
    IRQ.
    
    Without this patch, building raumfeld_defconfig results in:
    
    drivers/input/touchscreen/eeti_ts.c: In function 'eeti_ts_irq_active':
    drivers/input/touchscreen/eeti_ts.c:65:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Sven Neumann <s.neumann@raumfeld.com>
    Cc: linux-input@vger.kernel.org
    Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. @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>
  6. @jmberg @gregkh

    iwlwifi: disable greenfield transmissions as a workaround

    jmberg committed with gregkh Aug 5, 2012
    commit 50e2a30 upstream.
    
    There's a bug that causes the rate scaling to get stuck
    when it has to use single-stream rates with a peer that
    can do GF and SGI; the two are incompatible so we can't
    use them together, but that causes the algorithm to not
    work at all, it always rejects updates.
    
    Disable greenfield for now to prevent that problem.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Tested-by: Cesar Eduardo Barros <cesarb@cesarb.net>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. @kees @gregkh

    Yama: higher restrictions should block PTRACE_TRACEME

    kees committed with gregkh Aug 9, 2012
    commit 9d8dad7 upstream.
    
    The higher ptrace restriction levels should be blocking even
    PTRACE_TRACEME requests. The comments in the LSM documentation are
    misleading about when the checks happen (the parent does not go through
    security_ptrace_access_check() on a PTRACE_TRACEME call).
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. @gregkh

    tun: don't zeroize sock->file on detach

    Stanislav Kinsbursky committed with gregkh Aug 9, 2012
    commit 66d1b92 upstream.
    
    This is a fix for bug, introduced in 3.4 kernel by commit
    1ab5ecb ("tun: don't hold network
    namespace by tun sockets"), which, among other things, replaced simple
    sock_put() by sk_release_kernel(). Below is sequence, which leads to
    oops for non-persistent devices:
    
    tun_chr_close()
    tun_detach()				<== tun->socket.file = NULL
    tun_free_netdev()
    sk_release_sock()
    sock_release(sock->file == NULL)
    iput(SOCK_INODE(sock))			<== dereference on NULL pointer
    
    This patch just removes zeroing of socket's file from __tun_detach().
    sock_release() will do this.
    
    Reported-by: Ruan Zhijie <ruanzhijie@hotmail.com>
    Tested-by: Ruan Zhijie <ruanzhijie@hotmail.com>
    Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. @jeffmahoney @gregkh

    printk: Fix calculation of length used to discard records

    jeffmahoney committed with gregkh Aug 10, 2012
    commit e375647 upstream.
    
    While tracking down a weird buffer overflow issue in a program that
    looked to be sane, I started double checking the length returned by
    syslog(SYSLOG_ACTION_READ_ALL, ...) to make sure it wasn't overflowing
    the buffer.
    
    Sure enough, it was.  I saw this in strace:
    
      11339 syslog(SYSLOG_ACTION_READ_ALL, "<5>[244017.708129] REISERFS (dev"..., 8192) = 8279
    
    It turns out that the loops that calculate how much space the entries
    will take when they're copied don't include the newlines and prefixes
    that will be included in the final output since prev flags is passed as
    zero.
    
    This patch properly accounts for it and fixes the overflow.
    
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. @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>
  11. @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>
  12. @gregkh

    ARM: dts: imx53-ard: add regulators for lan9220

    Shawn Guo committed with gregkh Aug 2, 2012
    commit 1eec0c5 upstream.
    
    Since commit c7e963f (net/smsc911x: Add regulator support), the lan9220
    device tree probe fails on imx53-ard board, because the commit makes
    VDD33A and VDDVARIO supplies mandatory for the driver.
    
    Add a fixed dummy 3V3 supplying lan9220 to fix the regression.
    
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. @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>
  14. @gregkh

    ARM: imx: enable emi_slow_gate clock for imx5

    Shawn Guo committed with gregkh Aug 2, 2012
    commit 68b0562 upstream.
    
    The imx5 common clock migration causes a regression with smsc911x
    driver on imx53-ard board, where a smsc lan9220 controller gets
    connected on imx53 with EIM interface.  EIM needs clock emi_slow_gate
    to be functional.  In the new imx5 clock driver, there is no use count
    incremented for the clock by enabling it, so the framework closes the
    clock at late init time and makes EIM stop working then.
    
    Enable emi_slow_gate in clock driver initialization to fix the
    regression.
    
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. @gregkh

    ARM: clk-imx31: Fix the keypad clock name

    Fabio Estevam committed with gregkh Jul 26, 2012
    commit 8cc7a2b upstream.
    
    Fix the keypad clock name, in order to fix the following error:
    
    imx-keypad imx-keypad: failed to get keypad clock
    imx-keypad: probe of imx-keypad failed with error -2
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. @rolandd @gregkh

    target: Check number of unmap descriptors against our limit

    rolandd committed with gregkh Jul 16, 2012
    commit 7409a66 upstream.
    
    Fail UNMAP commands that have more than our reported limit on unmap
    descriptors.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. @rolandd @gregkh

    target: Fix possible integer underflow in UNMAP emulation

    rolandd committed with gregkh Jul 16, 2012
    commit b7fc7f3 upstream.
    
    It's possible for an initiator to send us an UNMAP command with a
    descriptor that is less than 8 bytes; in that case it's really bad for
    us to set an unsigned int to that value, subtract 8 from it, and then
    use that as a limit for our loop (since the value will wrap around to
    a huge positive value).
    
    Fix this by making size be signed and only looping if size >= 16 (ie
    if we have at least a full descriptor available).
    
    Also remove offset as an obfuscated name for the constant 8.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. @rolandd @gregkh

    target: Fix reading of data length fields for UNMAP commands

    rolandd committed with gregkh Jul 16, 2012
    commit 1a5fa45 upstream.
    
    The UNMAP DATA LENGTH and UNMAP BLOCK DESCRIPTOR DATA LENGTH fields
    are in the unmap descriptor (the payload transferred to our data out
    buffer), not in the CDB itself.  Read them from the correct place in
    target_emulated_unmap.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. @rolandd @gregkh

    target: Add range checking to UNMAP emulation

    rolandd committed with gregkh Jul 16, 2012
    commit 2594e29 upstream.
    
    When processing an UNMAP command, we need to make sure that the number
    of blocks we're asked to UNMAP does not exceed our reported maximum
    number of blocks per UNMAP, and that the range of blocks we're
    unmapping doesn't go past the end of the device.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. @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>
  21. @cyruslien @gregkh

    HID: add ASUS AIO keyboard model AK1D

    cyruslien committed with gregkh Jul 23, 2012
    commit 2d8767b upstream.
    
    Add Asus All-In-One PC keyboard model AK1D.
    
    BugLink: https://bugs.launchpad.net/bugs/1027789
    
    Signed-off-by: Cyrus Lien <cyrus.lien@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. @gregkh

    HID: add support for Cypress barcode scanner 04B4:ED81

    Lionel Vaux committed with gregkh Jul 22, 2012
    commit 76c9d8f upstream.
    
    Add yet another device to the list of Cypress barcode scanners
    needing the CP_RDESC_SWAPPED_MIN_MAX quirk.
    
    Signed-off-by: Lionel Vaux (iouri) <lionel.vaux@free.fr>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  23. @gregkh

    HID: multitouch: add support for Novatek touchscreen

    Austin Hendrix committed with gregkh Jun 4, 2012
    commit 4db703e upstream.
    
    Add support for a Novatek touchscreen panel as a generic HID multitouch
    panel.
    
    Signed-off-by: Austin Hendrix <ahendrix@willowgarage.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  24. @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>
  25. @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>
  26. @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>
  27. @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>
  28. @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>
  29. @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>
  30. @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>
  31. @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>
  32. @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>
  33. @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>
  34. @tytso @gregkh

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

    tytso committed with gregkh Jul 4, 2012
    commit 7bf2357 upstream.
    
    Cc: David Miller <davem@davemloft.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  35. @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>
Something went wrong with that request. Please try again.