Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
branch: master
Commits on Jul 25, 2011
  1. @RandyT

    Merge remote-tracking branch 'upstream/master'

    RandyT authored
    Conflicts:
    	sound/soc/codecs/Makefile
Commits on Jul 24, 2011
  1. @RandyT

    ARM: tegra: power: Program CPU power control register

    RandyT authored
    author	Scott Williams <scwilliams@nvidia.com>
    Fri, 1 Apr 2011 02:28:43 +0000 (19:28 -0700)
    committer	Dan Willemsen <dwillemsen@nvidia.com>
    Tue, 26 Apr 2011 22:55:01 +0000 (15:55 -0700)
    commit	d806c62a68816ea0e10d67099c0a3c508d7e3048
    tree	d4ff902833bdbab8bf50e2d12bf830cbbab51c2c	tree | snapshot
    parent	255640cba406a57110b24890a421954d090a773b	commit | diff
    ARM: tegra: power: Program CPU power control register
    
    Bug 755621
    
    Original-Change-Id: I7263e9f6e72b9eefc6e775ef646fcfde5290a129
    Reviewed-on: http://git-master/r/25043
    Reviewed-by: Scott Williams <scwilliams@nvidia.com>
    Tested-by: Scott Williams <scwilliams@nvidia.com>
    Change-Id: I5ae5fe008ec548c65bba1049dcfeee5454abcb93
  2. @RandyT

    ARM: tegra: power: save and restore perfmon context

    RandyT authored
    author	Peter De Schrijver <pdeschrijver@nvidia.com>
    Wed, 11 May 2011 12:28:18 +0000 (15:28 +0300)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Fri, 15 Jul 2011 23:50:03 +0000 (16:50 -0700)
    commit	844983ef04e9521595451829757fdcdc020273b2
    tree	ae9577ce804e4d31332871b75f97e23b00fc2336	tree | snapshot
    parent	8494a39c23c38945171b153546c6d7db05fb78b6	commit | diff
    ARM: tegra: power: save and restore perfmon context
    
    Change-Id: Ibc863b2af70371810305df195a5f4e37cd4f01f5
    Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
    Reviewed-on: http://git-master/r/31159
    Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
    Tested-by: Varun Colbert <vcolbert@nvidia.com>
  3. @RandyT

    arm: tegra: Redesign Tegra CPU reset handling

    RandyT authored
    author	Scott Williams <scwilliams@nvidia.com>
    Wed, 2 Feb 2011 18:32:42 +0000 (10:32 -0800)
    committer	Dan Willemsen <dwillemsen@nvidia.com>
    Tue, 26 Apr 2011 22:51:40 +0000 (15:51 -0700)
    commit	7df947103b10608106d2b10fbc951af68926438e
    tree	0d9e914ae54859f4ebb590a26b91d74adcadbf64	tree | snapshot
    parent	4c609cbf4d1f0cf1a3f78c72695e3168b6088a4a	commit | diff
    arm: tegra: Redesign Tegra CPU reset handling
    
    - Add a single unified handler for all CPU resets.
    - Don't write boot confirmation notification to the reset vector.
    - Write the EVP CPU reset vector only once per cold/warm boot session.
    - Don't allow Tegra3 LP2 until all CPUs have booted.
    - Don't restart online secondary CPUs that are also in LP2 state
      when restarting CPU0 for Tegra3.
    - Prevent the compiler from rearranging order-sensitive register
      writes in boot_secondary().
    - Fix incorrect return status in tegra_powergate_is_powered().
    - In LP2 entry code, if a WFI request fails, retry a limited number
      of times.
    - Eliminate duplicate macro definitions.
    - Improve commentary in assembly functions.
    
    Bug 786290
    Bug 790458
    
    Original-Change-Id: I7582112938aa80303d1b8b1d1948d278ca662043
    Reviewed-on: http://git-master/r/18091
    Tested-by: Scott Williams <scwilliams@nvidia.com>
    Reviewed-by: Narendra Damahe <ndamahe@nvidia.com>
    Tested-by: Jin Qian <jqian@nvidia.com>
    Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
    Tested-by: Aleksandr Frid <afrid@nvidia.com>
    Reviewed-by: Scott Williams <scwilliams@nvidia.com>
    Change-Id: I56a686e2e9fc00e61e97eec4fbf5a49944ffa77c
  4. @RandyT

    ARM: tegra: power: Lp2 fixes for slave cpus.

    RandyT authored
    author	vdumpa <vdumpa@nvidia.com>
    Tue, 3 May 2011 18:17:29 +0000 (11:17 -0700)
    committer	Niket Sirsi <nsirsi@nvidia.com>
    Tue, 24 May 2011 00:20:16 +0000 (17:20 -0700)
    commit	5e628f151a5b09147c235bbc201ba6aa3802bf12
    tree	fd034fa3dbf202e8f0a2e9e3a4c03c290dfd2271	tree | snapshot
    parent	0885c8037152e4b11d669c845ddf09ba49e5c8b6	commit | diff
    ARM: tegra: power: Lp2 fixes for slave cpus.
    
    Bug 804085
    
    Change-Id: I4b5eec018b324f0ee20b24a86e7e47490840f659
    Reviewed-on: http://git-master/r/30241
    Reviewed-by: Niket Sirsi <nsirsi@nvidia.com>
    Tested-by: Niket Sirsi <nsirsi@nvidia.com>
  5. @RandyT
Commits on Jul 23, 2011
  1. @RandyT

    ARM: remove unnecessary dcache_clean_area

    RandyT authored
    author	Heechul Yun <hyun@nvidia.com>
    Wed, 6 Jul 2011 02:03:55 +0000 (19:03 -0700)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Fri, 15 Jul 2011 23:01:45 +0000 (16:01 -0700)
    commit	6eeccbf7aee3ceae0d711df5df53f20f1195b1c7
    tree	7916c00fec44f6dcab51931b4b3616b120947a24	tree | snapshot
    parent	4ae8208660f838a7e31bdc1691026dada2920126	commit | diff
    ARM: remove unnecessary dcache_clean_area
    
    Cortex-A9 has PIPT D-cache which do not require clean the cache
    on creating page table.
    
    Change-Id: I42d528be83ea8def96045c7e575c7b3ed95f5980
    Reviewed-on: http://git-master/r/40505
    Reviewed-by: Heechul Yun <hyun@nvidia.com>
    Tested-by: Heechul Yun <hyun@nvidia.com>
    Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
    Reviewed-by: Scott Williams <scwilliams@nvidia.com>
  2. @RandyT

    ARM: remove unnecesarry L2 cache flush

    RandyT authored
    author	Heechul Yun <hyun@nvidia.com>
    Tue, 12 Jul 2011 01:12:38 +0000 (18:12 -0700)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Fri, 15 Jul 2011 23:01:35 +0000 (16:01 -0700)
    commit	4ae8208660f838a7e31bdc1691026dada2920126
    tree	359bc13022da14a6a1b72b82039072caf819d8c2	tree | snapshot
    parent	6b3d1337150aaba81b2509847d4b83b74bcc59b1	commit | diff
    ARM: remove unnecesarry L2 cache flush
    
    The memory barrier, mb(), flush L2 cache which is unnecessary
    for bit operations because D cache is coherent for all CPUs
    This patch improves scalability of the system.
    
    Change-Id: I3bec7ec767849091b6da720869241f3a16a7b5cb
    Reviewed-on: http://git-master/r/40504
    Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
    Tested-by: Heechul Yun <hyun@nvidia.com>
    Reviewed-by: Heechul Yun <hyun@nvidia.com>
    Reviewed-by: Scott Williams <scwilliams@nvidia.com>
  3. @RandyT

    ARM: mm: remove unnecessary cache flush on v6 copypage

    RandyT authored
    author	Heechul Yun <hyun@nvidia.com>
    Tue, 5 Jul 2011 16:39:25 +0000 (09:39 -0700)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Fri, 15 Jul 2011 23:01:25 +0000 (16:01 -0700)
    commit	6b3d1337150aaba81b2509847d4b83b74bcc59b1
    tree	51d9dbd866b573218f1047a68869323efed78742	tree | snapshot
    parent	a711c16c086049e980c2d4969019938050a1a889	commit | diff
    ARM: mm: remove unnecessary cache flush on v6 copypage
    
    Originally introduced to maintain coherency between icache and dcache
    in v6 nonaliasing mode. This is now handled by __sync_icache_dcache since
    c0177800, therefore unnecessary in this function.
    
    Change-Id: I3d78cedbf1e5816ecd49b0f0304ac2fb7972c5d9
    Reviewed-on: http://git-master/r/40242
    Tested-by: Heechul Yun <hyun@nvidia.com>
    Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
    Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
    Reviewed-by: Heechul Yun <hyun@nvidia.com>
  4. @RandyT

    arm: mm: Remove unnecessary cache flush on page table modification

    RandyT authored
    author	Heechul Yun <hyun@nvidia.com>
    Thu, 30 Jun 2011 22:40:43 +0000 (15:40 -0700)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Fri, 15 Jul 2011 23:00:26 +0000 (16:00 -0700)
    commit	a711c16c086049e980c2d4969019938050a1a889
    tree	ee449f698494dabdbae2ed0cd79e142c08f66558	tree | snapshot
    parent	6259e05c3c5ac671a65bb3bf86153be0e0312b21	commit | diff
    arm: mm: Remove unnecessary cache flush on page table modification
    
    Since MMU of Cortex-A9 read from L1-D not from memory, there's no
    need to flush the cache line of the modified page table entry.
    
    Change-Id: Ie5e6a027f633ed6060b8d2a9fdcd6a5399736d55
    Reviewed-on: http://git-master/r/39697
    Reviewed-by: Heechul Yun <hyun@nvidia.com>
    Tested-by: Heechul Yun <hyun@nvidia.com>
    Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
    Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
  5. @RandyT

    video: tegra: dc: Reduce usage count of nvmap client

    RandyT authored
    author	Vandana Salve <vsalve@nvidia.com>
    Fri, 8 Jul 2011 08:02:48 +0000 (13:02 +0530)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Fri, 15 Jul 2011 17:41:15 +0000 (10:41 -0700)
    commit	a291c3b17bd980748edd409e40bc6b632a7b3968
    tree	dec5764f21d5f6442ade4e5d463125ee54633a8e	tree | snapshot
    parent	c91c8e46ac80ab6a51ac094d8167939b8d51d8f4	commit | diff
    video: tegra: dc: Reduce usage count of nvmap client
    
    Carveout memory leak occured in video playback on abnormal termination as the
    tegra overlay driver didn't had the implementation to reduce the usage count of
    nvmap client on device closure.
    
    Hence on abnormal termination of mediaserver, the carveout memory remained
    allocated causing memory leak.
    
    The usage count of nvmap client for overlay driver is incremented on
    ioctl TEGRA_OVERLAY_IOCTL_SET_NVMAP_FD.It should be decremented on
    device closure.
    
    Added the code to decrement the uage count of nvmap client on release, so that
    the client and the carveout memory is free'd whenever the count reaches zero
    on successful as well as abnormal termination of mediaserver process.
    
    Similar implementation is done by NvHost channel driver,
    The NvHost drivers takes care of nvmap client usage count.i.e. decrement the
    uasge count of nvmap client which is incremented by
    NVHOST_IOCTL_CHANNEL_SET_NVMAP_FD ioctl.
    
    Bug 845676
    
    Reviewed-on: http://git-master/r/40157
    (cherry picked from commit c10173d70affb7117284b57fb0870c90823a5880)
    
    Change-Id: I4de52d89b70a1f5ed401f807e76a6160f65d9917
    Reviewed-on: http://git-master/r/40840
    Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
    Tested-by: Bharat Nihalani <bnihalani@nvidia.com>
  6. @RandyT

    ARM: tegra2: mc: Fix the issue of counters not being reset

    RandyT authored
    author	licheng <licheng@nvidia.com>
    Fri, 8 Jul 2011 18:17:11 +0000 (13:17 -0500)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Thu, 14 Jul 2011 19:28:39 +0000 (12:28 -0700)
    commit	36a6a0192319f0067ee8685fe56cfba5aba06ad8
    tree	0e3c866cb3c6190de1a02c9de5c23393c2ae9c82	tree | snapshot
    parent	e96163ffb55116716dfef05dffba637f315d4557	commit | diff
    
    ARM: tegra2: mc: Fix the issue of counters not being reset
    
    EMC state control register is not programmed correctly as the value
    is not reset after previous write is done.
    
    Bug 829087
    
    Reviewed-on: http://git-master/r/40230
    (cherry picked from commit 51a190b49a347968c22c1ed8187568a7ed1fb1f1)
    
    Change-Id: Ic2c8d33ad241100939eb1d8fa026a1d5849c0fd8
    Reviewed-on: http://git-master/r/40687
    Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
    Tested-by: Bharat Nihalani <bnihalani@nvidia.com>
    Reviewed-by: Scott Williams <scwilliams@nvidia.com>
  7. @RandyT

    tegra: clocks: Remove shared clocks from sku_limits

    RandyT authored
    author	mchourasia <mchourasia@nvidia.com>
    Wed, 22 Jun 2011 07:26:15 +0000 (12:26 +0530)
    committer	Varun Colbert <vcolbert@nvidia.com>
    Wed, 13 Jul 2011 23:45:41 +0000 (16:45 -0700)
    commit	50edca71f31cd194a7734298dd9314cd6b8c2a79
    tree	45e2ab7e5c1fed3780d803ec129070c4713c92c2	tree | snapshot
    parent	a169b1a92dc1ed4c824569e9dc70267cb1e2eb52	commit | diff
    
    tegra: clocks: Remove shared clocks from sku_limits
    
    "avp.sclk" and "bsea.sclk" are shared clocks and should
    be removed from sku_limits table as shared clocks are
    registered later and not available at the time of putting
    rate limits.
    
    Change-Id: Idc85d37a06e764e03f08e31582dbd16c77ae4b16
    Reviewed-on: http://git-master/r/38271
    Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
    Tested-by: Varun Colbert <vcolbert@nvidia.com>
Commits on Jul 20, 2011
  1. @pershoot

    defconfig: regen

    pershoot authored
  2. @pershoot

    vfp: switch to mfpu=vfpv3-d16

    pershoot authored
  3. @RandyT

    Merge remote-tracking branch 'upstream/master'

    RandyT authored
    Conflicts:
    	.gitignore
    	arch/arm/configs/pershoot_samsung_p4_defconfig
    	arch/arm/configs/pershoot_samsung_p4wifi_defconfig
    	arch/arm/configs/tegra_harmony_gnu_linux_defconfig.orig
    	drivers/cpufreq/cpufreq_ondemand.c
  4. @supercurio @pershoot

    Voodoo sound: driver v10

    supercurio authored pershoot committed
    Improvement:
    
    - HW EQ support: smooth activation/deactivation and gain changes
    
    Bugfixes:
    
    - HP volume smoothing loop on low levels with negative digital offsets
    - wm8994_write logging on Nexus S
    
    New supported devices:
    
    - Galaxy Tab 7" Gingerbread Kernels support (based on M180S)
    - Galaxy Tab 10.1 - beta
  5. @supercurio @pershoot

    Voodoo sound: driver v9 early port to Galaxy Tab 10.1

    supercurio authored pershoot committed
    - features miss testing
    - needs a new anti-jitter strategy
    - ..but hey, it does some nice job already :)
  6. @pershoot

    mm/migrate.c: fix compilation error

    Michal Nazarewicz authored pershoot committed
    GCC complained about update_mmu_cache() not being defined in migrate.c.
    Including <asm/tlbflush.h> seems to solve the problem.
    
    Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  7. @pershoot

    memcg: more mem_cgroup_uncharge() batching

    Hugh Dickins authored pershoot committed
    It seems odd that truncate_inode_pages_range(), called not only when
    truncating but also when evicting inodes, has mem_cgroup_uncharge_start
    and _end() batching in its second loop to clear up a few leftovers, but
    not in its first loop that does almost all the work: add them there too.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
    Acked-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  8. @pershoot

    mm: vmscan: correctly check if reclaimer should schedule during shrin…

    Minchan Kim authored pershoot committed
    …k_slab
    
    commit f06590bd718ed950c98828e30ef93204028f3210 upstream.
    
    It has been reported on some laptops that kswapd is consuming large
    amounts of CPU and not being scheduled when SLUB is enabled during large
    amounts of file copying.  It is expected that this is due to kswapd
    missing every cond_resched() point because;
    
    shrink_page_list() calls cond_resched() if inactive pages were isolated
            which in turn may not happen if all_unreclaimable is set in
            shrink_zones(). If for whatver reason, all_unreclaimable is
            set on all zones, we can miss calling cond_resched().
    
    balance_pgdat() only calls cond_resched if the zones are not
            balanced. For a high-order allocation that is balanced, it
            checks order-0 again. During that window, order-0 might have
            become unbalanced so it loops again for order-0 and returns
            that it was reclaiming for order-0 to kswapd(). It can then
            find that a caller has rewoken kswapd for a high-order and
            re-enters balance_pgdat() without ever calling cond_resched().
    
    shrink_slab only calls cond_resched() if we are reclaiming slab
    	pages. If there are a large number of direct reclaimers, the
    	shrinker_rwsem can be contended and prevent kswapd calling
    	cond_resched().
    
    This patch modifies the shrink_slab() case.  If the semaphore is
    contended, the caller will still check cond_resched().  After each
    successful call into a shrinker, the check for cond_resched() remains in
    case one shrinker is particularly slow.
    
    [mgorman@suse.de: preserve call to cond_resched after each call into shrinker]
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
    Tested-by: Colin King <colin.king@canonical.com>
    Cc: Raghavendra D Prabhu <raghu.prabhu13@gmail.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Chris Mason <chris.mason@oracle.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Rik van Riel <riel@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@suse.de>
  9. @pershoot

    mm: use alloc_bootmem_node_nopanic() on really needed path

    Yinghai Lu authored pershoot committed
    commit 8f389a99b652aab5b42297280bd94d95933ad12f upstream.
    
    Stefan found nobootmem does not work on his system that has only 8M of
    RAM.  This causes an early panic:
    
      BIOS-provided physical RAM map:
       BIOS-88: 0000000000000000 - 000000000009f000 (usable)
       BIOS-88: 0000000000100000 - 0000000000840000 (usable)
      bootconsole [earlyser0] enabled
      Notice: NX (Execute Disable) protection missing in CPU or disabled in BIOS!
      DMI not present or invalid.
      last_pfn = 0x840 max_arch_pfn = 0x100000
      init_memory_mapping: 0000000000000000-0000000000840000
      8MB LOWMEM available.
        mapped low ram: 0 - 00840000
        low ram: 0 - 00840000
      Zone PFN ranges:
        DMA      0x00000001 -> 0x00001000
        Normal   empty
      Movable zone start PFN for each node
      early_node_map[2] active PFN ranges
          0: 0x00000001 -> 0x0000009f
          0: 0x00000100 -> 0x00000840
      BUG: Int 6: CR2 (null)
           EDI c034663c  ESI (null)  EBP c0329f38  ESP c0329ef4
           EBX c0346380  EDX 00000006  ECX ffffffff  EAX fffffff4
           err (null)  EIP c0353191   CS c0320060  flg 00010082
      Stack: (null) c030c533 000007cd (null) c030c533 00000001 (null) (null)
             00000003 0000083f 00000018 00000002 00000002 c0329f6c c03534d6 (null)
             (null) 00000100 00000840 (null) c0329f64 00000001 00001000 (null)
      Pid: 0, comm: swapper Not tainted 2.6.36 #5
      Call Trace:
       [<c02e3707>] ? 0xc02e3707
       [<c035e6e5>] 0xc035e6e5
       [<c0353191>] ? 0xc0353191
       [<c03534d6>] 0xc03534d6
       [<c034f1cd>] 0xc034f1cd
       [<c034a824>] 0xc034a824
       [<c03513cb>] ? 0xc03513cb
       [<c0349432>] 0xc0349432
       [<c0349066>] 0xc0349066
    
    It turns out that we should ignore the low limit of 16M.
    
    Use alloc_bootmem_node_nopanic() in this case.
    
    [akpm@linux-foundation.org: less mess]
    Signed-off-by: Yinghai LU <yinghai@kernel.org>
    Reported-by: Stefan Hellermann <stefan@the2masters.de>
    Tested-by: Stefan Hellermann <stefan@the2masters.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: "H. Peter Anvin" <hpa@linux.intel.com>
    Cc: Thomas Gleixner <tglx@linutronix.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@suse.de>
  10. @torvalds @pershoot

    vm: fix vm_pgoff wrap in stack expansion

    torvalds authored pershoot committed
    commit a626ca6a656450e9f4df91d0dda238fff23285f4 upstream.
    
    Commit 982134ba6261 ("mm: avoid wrapping vm_pgoff in mremap()") fixed
    the case of a expanding mapping causing vm_pgoff wrapping when you used
    mremap.  But there was another case where we expand mappings hiding in
    plain sight: the automatic stack expansion.
    
    This fixes that case too.
    
    This one also found by Robert Święcki, using his nasty system call
    fuzzer tool.  Good job.
    
    Reported-and-tested-by: Robert Święcki <robert@swiecki.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @torvalds @pershoot

    mm: avoid wrapping vm_pgoff in mremap()

    torvalds authored pershoot committed
    commit 982134ba62618c2d69fbbbd166d0a11ee3b7e3d8 upstream.
    
    The normal mmap paths all avoid creating a mapping where the pgoff
    inside the mapping could wrap around due to overflow.  However, an
    expanding mremap() can take such a non-wrapping mapping and make it
    bigger and cause a wrapping condition.
    
    Noticed by Robert Swiecki when running a system call fuzzer, where it
    caused a BUG_ON() due to terminally confusing the vma_prio_tree code.  A
    vma dumping patch by Hugh then pinpointed the crazy wrapped case.
    
    Reported-and-tested-by: Robert Swiecki <robert@swiecki.net>
    Acked-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @pershoot

    mm: <asm-generic/pgtable.h> must include <linux/mm_types.h>

    Ben Hutchings authored pershoot committed
    Commit e2cda3226481 ("thp: add pmd mangling generic functions") replaced
    some macros in <asm-generic/pgtable.h> with inline functions.
    
    If the functions are to be defined (not all architectures need them)
    then struct vm_area_struct must be defined first.  So include
    <linux/mm_types.h>.
    
    Fixes a build failure seen in Debian:
    
        CC [M]  drivers/media/dvb/mantis/mantis_pci.o
      In file included from arch/arm/include/asm/pgtable.h:460,
                       from drivers/media/dvb/mantis/mantis_pci.c:25:
      include/asm-generic/pgtable.h: In function 'ptep_test_and_clear_young':
      include/asm-generic/pgtable.h:29: error: dereferencing pointer to incomplete type
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  13. @pershoot

    mm: fix possible cause of a page_mapped BUG

    Hugh Dickins authored pershoot committed
    Robert Swiecki reported a BUG_ON(page_mapped) from a fuzzer, punching
    a hole with madvise(,, MADV_REMOVE).  That path is under mutex, and
    cannot be explained by lack of serialization in unmap_mapping_range().
    
    Reviewing the code, I found one place where vm_truncate_count handling
    should have been updated, when I switched at the last minute from one
    way of managing the restart_addr to another: mremap move changes the
    virtual addresses, so it ought to adjust the restart_addr.
    
    But rather than exporting the notion of restart_addr from memory.c, or
    converting to restart_pgoff throughout, simply reset vm_truncate_count
    to 0 to force a rescan if mremap move races with preempted truncation.
    
    We have no confirmation that this fixes Robert's BUG,
    but it is a fix that's worth making anyway.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  14. @pershoot

    mm: clear pages_scanned only if draining a pcp adds pages to the budd…

    David Rientjes authored pershoot committed
    …y allocator
    
    Commit 0e093d99763e ("writeback: do not sleep on the congestion queue if
    there are no congested BDIs or if significant congestion is not being
    encountered in the current zone") uncovered a livelock in the page
    allocator that resulted in tasks infinitely looping trying to find
    memory and kswapd running at 100% cpu.
    
    The issue occurs because drain_all_pages() is called immediately
    following direct reclaim when no memory is freed and try_to_free_pages()
    returns non-zero because all zones in the zonelist do not have their
    all_unreclaimable flag set.
    
    When draining the per-cpu pagesets back to the buddy allocator for each
    zone, the zone->pages_scanned counter is cleared to avoid erroneously
    setting zone->all_unreclaimable later.  The problem is that no pages may
    actually be drained and, thus, the unreclaimable logic never fails
    direct reclaim so the oom killer may be invoked.
    
    This apparently only manifested after wait_iff_congested() was
    introduced and the zone was full of anonymous memory that would not
    congest the backing store.  The page allocator would infinitely loop if
    there were no other tasks waiting to be scheduled and clear
    zone->pages_scanned because of drain_all_pages() as the result of this
    change before kswapd could scan enough pages to trigger the reclaim
    logic.  Additionally, with every loop of the page allocator and in the
    reclaim path, kswapd would be kicked and would end up running at 100%
    cpu.  In this scenario, current and kswapd are all running continuously
    with kswapd incrementing zone->pages_scanned and current clearing it.
    
    The problem is even more pronounced when current swaps some of its
    memory to swap cache and the reclaimable logic then considers all active
    anonymous memory in the all_unreclaimable logic, which requires a much
    higher zone->pages_scanned value for try_to_free_pages() to return zero
    that is never attainable in this scenario.
    
    Before wait_iff_congested(), the page allocator would incur an
    unconditional timeout and allow kswapd to elevate zone->pages_scanned to
    a level that the oom killer would be called the next time it loops.
    
    The fix is to only attempt to drain pcp pages if there is actually a
    quantity to be drained.  The unconditional clearing of
    zone->pages_scanned in free_pcppages_bulk() need not be changed since
    other callers already ensure that draining will occur.  This patch
    ensures that free_pcppages_bulk() will actually free memory before
    calling into it from drain_all_pages() so zone->pages_scanned is only
    cleared if appropriate.
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  15. @jankara @pershoot

    mm: fix truncate_setsize() comment

    jankara authored pershoot committed
    Contrary to what the comment says, truncate_setsize() should be called
    *before* filesystem truncated blocks.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  16. @pershoot

    mm: set correct numa_zonelist_order string when configured on the ker…

    Volodymyr G. Lukiianyk authored pershoot committed
    …nel command line
    
    When numa_zonelist_order parameter is set to "node" or "zone" on the
    command line it's still showing as "default" in sysctl.  That's because
    early_param parsing function changes only user_zonelist_order variable.
    Fix this by copying user-provided string to numa_zonelist_order if it was
    successfully parsed.
    
    Signed-off-by: Volodymyr G Lukiianyk <volodymyrgl@gmail.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  17. @pershoot

    mm: remove likely() from grab_cache_page_write_begin()

    Steven Rostedt authored pershoot committed
    Running the annotated branch profiler on a box doing average work
    (firefox, evolution, xchat, distcc farm), the likely() used in
    grab_cache_page_write_begin() was incorrect most of the time:
    
     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
     1924262 71332401  97 grab_cache_page_write_begin    filemap.c           2206
    
    Adding a trace_printk() and running the function tracer limited to
    just this function I can see:
    
            gconfd-2-2696  [000]  4467.268935: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=7
            gconfd-2-2696  [000]  4467.268946: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268947: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=8
            gconfd-2-2696  [000]  4467.268959: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268960: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=9
            gconfd-2-2696  [000]  4467.268972: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268973: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=10
            gconfd-2-2696  [000]  4467.268991: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268992: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=11
            gconfd-2-2696  [000]  4467.269005: grab_cache_page_write_begin <-ext3_write_begin
    
    Which shows that a lot of calls from ext3_write_begin will result in the
    page returned by "find_lock_page" will be NULL.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  18. @pershoot

    mm: remove unlikely() from page_mapping()

    Steven Rostedt authored pershoot committed
    page_mapping() has a unlikely that the mapping has PAGE_MAPPING_ANON set.
    But running the annotated branch profiler on a normal desktop system doing
    vairous tasks (xchat, evolution, firefox, distcc), it is not really that
    unlikely that the mapping here will have the PAGE_MAPPING_ANON flag set:
    
     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659
    
    The page_mapping() is a static inline, which is why it shows up multiple
    times.
    
    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  With this much of
    an error, it's best to simply remove the unlikely and have the compiler
    and branch prediction figure this out.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  19. @pershoot

    mm: remove likely() from mapping_unevictable()

    Steven Rostedt authored pershoot committed
    The mapping_unevictable() has a likely() around the mapping parameter.
    This mapping parameter comes from page_mapping() which has an unlikely()
    that the page will be set as PAGE_MAPPING_ANON, and if so, it will return
    NULL.  One would think that this unlikely() means that the mapping
    returned by page_mapping() would not be NULL, but where page_mapping() is
    used just above mapping_unevictable(), that unlikely() is incorrect most
    of the time.  This means that the "likely(mapping)" in
    mapping_unevictable() is incorrect most of the time.
    
    Running the annotated branch profiler on my main box which runs firefox,
    evolution, xchat and is part of my distcc farm, I had this:
    
     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    12872836 1269443893  98 mapping_unevictable            pagemap.h            51
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659
    
    The page_mapping() is a static inline, which is why it shows up multiple
    times.  The mapping_unevictable() is also a static inline but seems to be
    used only once in my setup.
    
    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  Perhaps this is
    enough to remove the unlikely from page_mapping() as well.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  20. @rikvanriel @pershoot

    mm: clear PageError bit in msync & fsync

    rikvanriel authored pershoot committed
    Temporary IO failures, eg.  due to loss of both multipath paths, can
    permanently leave the PageError bit set on a page, resulting in msync or
    fsync returning -EIO over and over again, even if IO is now getting to the
    disk correctly.
    
    We already clear the AS_ENOSPC and AS_IO bits in mapping->flags in the
    filemap_fdatawait_range function.  Also clearing the PageError bit on the
    page allows subsequent msync or fsync calls on this file to return without
    an error, if the subsequent IO succeeds.
    
    Unfortunately data written out in the msync or fsync call that returned
    -EIO can still get lost, because the page dirty bit appears to not get
    restored on IO error.  However, the alternative could be potentially all
    of memory filling up with uncleanable dirty pages, hanging the system, so
    there is no nice choice here...
    
    Signed-off-by: Rik van Riel <riel@redhat.com>
    Acked-by: Valerie Aurora <vaurora@redhat.com>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  21. @pershoot

    mm: unify module_alloc code for vmalloc

    David Rientjes authored pershoot committed
    Four architectures (arm, mips, sparc, x86) use __vmalloc_area() for
    module_init().  Much of the code is duplicated and can be generalized in a
    globally accessible function, __vmalloc_node_range().
    
    __vmalloc_node() now calls into __vmalloc_node_range() with a range of
    [VMALLOC_START, VMALLOC_END) for functionally equivalent behavior.
    
    Each architecture may then use __vmalloc_node_range() directly to remove
    the duplication of code.
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  22. @pershoot

    mm: remove gfp mask from pcpu_get_vm_areas

    David Rientjes authored pershoot committed
    pcpu_get_vm_areas() only uses GFP_KERNEL allocations, so remove the gfp_t
    formal and use the mask internally.
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Something went wrong with that request. Please try again.