<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.kernel.mm">
    <title>gmane.linux.kernel.mm</title>
    <link>http://blog.gmane.org/gmane.linux.kernel.mm</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/79056"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/79053"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/79045"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78953"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78950"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78928"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78911"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78891"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78877"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78876"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78875"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78874"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78873"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78872"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78865"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78860"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78837"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78819"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78812"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.mm/78782"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/79056">
    <title>mm: hung task after fuzzing</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/79056</link>
    <description>&lt;pre&gt;Hi all,

I stumbled on the following when fuzzing with trinity inside a KVM guest, using latest linux-next kernel:

[ 3367.906805] INFO: task numad/2:24 blocked for more than 120 seconds.
[ 3367.910318] "echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 3367.914853] numad/2         D 0000000000000001  5928    24      2 0x00000000
[ 3367.918638]  ffff8800294fdc58 0000000000000046 ffff8800294fdc08 ffffffff81152212
[ 3367.923198]  ffff8800294fc000 ffff8800294fc010 ffff8800294fdfd8 ffff8800294fc000
[ 3367.933897]  ffff8800294fc010 ffff8800294fdfd8 ffff88000c878000 ffff880029500000
[ 3367.942510] Call Trace:
[ 3367.944815]  [&amp;lt;ffffffff81152212&amp;gt;] ? __lock_release+0x1c2/0x1e0
[ 3367.948480]  [&amp;lt;ffffffff832476c5&amp;gt;] schedule+0x55/0x60
[ 3367.951647]  [&amp;lt;ffffffff832484c5&amp;gt;] rwsem_down_failed_common+0xf5/0x130
[ 3367.955499]  [&amp;lt;ffffffff8114b7be&amp;gt;] ? put_lock_stats+0xe/0x40
[ 3367.959585]  [&amp;lt;ffffffff8114e565&amp;gt;] ? __lock_contended+0x1f5/0x230
[ 3367.964727]  [&amp;lt;ffffffff83248535&amp;gt;] rwsem_down_read_failed+0&lt;/pre&gt;</description>
    <dc:creator>Sasha Levin</dc:creator>
    <dc:date>2012-05-26T19:34:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/79053">
    <title>[PATCH] mm/numa: Fix kernel crash caused by offline node</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/79053</link>
    <description>&lt;pre&gt;I tried to boot the updated kernel (3.4.0+) on IBM power machine.
Unfortunately, I got kernel crash as follows. Then I traced it
down until I found sched/core.c::sched_init_numa tried to allocate
memory from the possible nodes. That doesn't make sense since the
possible nodes might never come in for ever.

Linux version 3.4.0+ (shangw&amp;lt; at &amp;gt;shangw) (gcc version 4.4.5 (crosstool-NG 1.13.0) ) #154 SMP Sat May 26 15:33:20 CST 2012
:
Unable to handle kernel paging request for data at address 0x00001388
Faulting instruction address: 0xc00000000017d44c
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA PowerNV
Modules linked in:
NIP: c00000000017d44c LR: c00000000017d448 CTR: 000000002f805eb0
REGS: c0000007f22836d0 TRAP: 0300   Not tainted  (3.4.0+)
MSR: 9000000000009032 &amp;lt;SF,HV,EE,ME,IR,DR,RI&amp;gt;  CR: 28004082  XER: 00000000
SOFTE: 1
CFAR: c000000000005100
DAR: 0000000000001388, DSISR: 40000000
TASK = c0000007f21c0000[1] 'swapper/0' THREAD: c0000007f2280000 CPU: 0
GPR00: c00000000017d448 c0000007f2283950 c&lt;/pre&gt;</description>
    <dc:creator>Gavin Shan</dc:creator>
    <dc:date>2012-05-26T08:03:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/79045">
    <title>[PATCH 00/35] AutoNUMA alpha14</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/79045</link>
    <description>&lt;pre&gt;Hello everyone,

It's time for a new autonuma-alpha14 milestone.

Removed the [RFC] from Subject because 1) this is a release I'm quite
happy with (from the implementation side it allows the same kernel
image to boot optimally on NUMA and not-NUMA hardware and it avoids
altering the scheduler runtime most of the time) and 2) because of the
great benchmark results we got so far, showing this design so far has
been proved to perform best.

I believe (realistically speaking) nobody is going to change
applications to specify which thread is using which memory (for
threaded apps) with the only exception of QEMU and a few others.

For not threaded apps that fits in a NUMA node, there's no way a blind
home node can perform nearly as good as AutoNUMA: AutoNUMA monitor the
whole status of the memory of the running processes and it optimizes
the memory placement and CPU placement dynamically
accordingly. There's a small memory and CPU cost in collecting so much
information to be able to make smart decisions, but the b&lt;/pre&gt;</description>
    <dc:creator>Andrea Arcangeli</dc:creator>
    <dc:date>2012-05-25T17:02:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78953">
    <title>[PATCH 0/2 v4] Flexible proportions</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78953</link>
    <description>&lt;pre&gt;
  Hello,

  here is the next iteration of my flexible proportions code. I've addressed
all Peter's comments.
Changes since v3:
  * changed fprop_fraction_foo() to avoid using percpu_counter_sum()
  * changed __fprop_inc_percpu_max() to avoid 64-bit division (now maximum
    allowed fraction is expressed max_frac/FPROP_FRAC_BASE)
  * avoid drifting of period timer
  * handle better cases where period timer fires long after intended time by
    aging by really passed number of periods
Changes since v2:
  * use timer instead of workqueue for triggering period switch
  * arm timer only if aging didn't zero out all fractions, re-arm timer when
    new event arrives again
  * set period length to 3s

  Some introduction for first time readers:

  The idea of this patch set is to provide code for computing event proportions
where aging period is not dependent on the number of events happening (so
that aging works well both with fast storage and slow USB sticks in the same
system).

  The basic idea is that we comp&lt;/pre&gt;</description>
    <dc:creator>Jan Kara</dc:creator>
    <dc:date>2012-05-24T16:59:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78950">
    <title>the max size of block device on 32bit os,when using do_generic_file_read() proceed.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78950</link>
    <description>&lt;pre&gt;  Hi all:
I readed a raid5,which size 30T.OS is RHEL6 32bit.
    I reaed the raid5(as a whole,not parted) and found read address which not i wanted.
So I tested the newest kernel code,the problem is still.
I review the code, in function do_generic_file_read()

index = *ppos &amp;gt;&amp;gt; PAGE_CACHE_SHIFT;
index is u32.and *ppos is long long.
So when *ppos is larger than 0xFFFF FFFF *  PAGE_CACHE_SHIFT(16T Byte),then the index is error.

I wonder this .In 32bit os ,block devices size do not large then 16T,in other words, if block devices larger than 16T,must parted.

Thanks all.
 
--------------
majianpeng
2012-05-24

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo&amp;lt; at &amp;gt;kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: &amp;lt;a href=mailto:"dont&amp;lt; at &amp;gt;kvack.org"&amp;gt; email&amp;lt; at &amp;gt;kvack.org &amp;lt;/a&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>majianpeng</dc:creator>
    <dc:date>2012-05-24T13:38:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78928">
    <title>[PATCH RESEND] avoid swapping out with swappiness==0</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78928</link>
    <description>&lt;pre&gt;Hi Andrew,

This patch has been reviewed for couple of months.

This patch *only* improves the behavior when the kernel has
enough filebacked pages. It means that it does not change
the behavior when kernel has small number of filebacked pages.

Kosaki-san pointed out that the threshold which we use
to decide whether filebacked page is enough or not is not
appropriate(*).

(*) http://www.spinics.net/lists/linux-mm/msg32380.html

As I described in (**), I believe that threshold discussion
should be done in other thread because it affects not only
swappiness=0 case and the kernel behave the same way with
or without this patch below the threshold.

(**) http://www.spinics.net/lists/linux-mm/msg34317.html

The patch may not be perfect but, at least, we can improve
the kernel behavior in the enough filebacked memory case
with this patch. I believe it's better than nothing.

Do you have any comments about it?

NOTE: I updated the patch with Acked-by tags

---
Sometimes we'd like to avoid swapping out anonymous mem&lt;/pre&gt;</description>
    <dc:creator>Satoru Moriya</dc:creator>
    <dc:date>2012-05-23T20:41:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78911">
    <title>Common 00/22] Sl[auo]b: Common functionality V3</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78911</link>
    <description>&lt;pre&gt;V2-&amp;gt;V3:
- Incorporate more feedback from Joonsoo Kim and Glauber Costa
- And a couple more patches to deal with slab duping and move
  more code to slab_common.c

V1-&amp;gt;V2:
- Incorporate glommers feedback.
- Add 2 more patches dealing with common code in kmem_cache_destroy

This is a series of patches that extracts common functionality from
slab allocators into a common code base. The intend is to standardize
as much as possible of the allocator behavior while keeping the
distinctive features of each allocator which are mostly due to their
storage format and serialization approaches.

This patchset makes a beginning by extracting common functionality in
kmem_cache_create() and kmem_cache_destroy(). However, there are
numerous other areas where such work could be beneficial:

1. Extract the sysfs support from SLUB and make it common. That way
   all allocators have a common sysfs API and are handleable in the same
   way regardless of the allocator chose.

2. Extract the error reporting and checking from SLUB a&lt;/pre&gt;</description>
    <dc:creator>Christoph Lameter</dc:creator>
    <dc:date>2012-05-23T20:34:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78891">
    <title>[PATCH] tmpfs not interleaving properly</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78891</link>
    <description>&lt;pre&gt;
When tmpfs has the memory policy interleaved it always starts allocating at each file at node 0.
When there are many small files the lower nodes fill up disproportionately.
My proposed solution is to start a file at a randomly chosen node.

Cc: Christoph Lameter &amp;lt;cl&amp;lt; at &amp;gt;linux.com&amp;gt;
Cc: Nick Piggin &amp;lt;npiggin&amp;lt; at &amp;gt;gmail.com&amp;gt;
Cc: Hugh Dickins &amp;lt;hughd&amp;lt; at &amp;gt;google.com&amp;gt;
Cc: Lee Schermerhorn &amp;lt;lee.schermerhorn&amp;lt; at &amp;gt;hp.com&amp;gt;
Cc: stable&amp;lt; at &amp;gt;vger.kernel.org
Signed-off-by: Nathan T Zimmer &amp;lt;nzimmer&amp;lt; at &amp;gt;sgi.com&amp;gt;


diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h index 79ab255..38eda26 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -17,6 +17,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct shmem_inode_info {
 char*symlink;/* unswappable short symlink */
 };
 struct shared_policypolicy;/* NUMA memory alloc policy */
+intnode_offset;/* bias for interleaved nodes */
 struct list_headswaplist;/* chain of maybes on swap */
 struct list_headxattr_list;/* list of shmem_xattr */
 struct inodevfs_inode;
diff --git a/mm/shmem.c b/mm/s&lt;/pre&gt;</description>
    <dc:creator>Nathan Zimmer</dc:creator>
    <dc:date>2012-05-23T13:28:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78877">
    <title>[PATCH 2/2] vmevent: pass right attribute to vmevent_sample_attr()</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78877</link>
    <description>&lt;pre&gt;From: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Subject: [PATCH] vmevent: pass right attribute to vmevent_sample_attr()

Pass "config attribute" (&amp;amp;watch-&amp;gt;config-&amp;gt;attrs[i]) not "sample
attribute" (&amp;amp;watch-&amp;gt;sample_attrs[i]) to vmevent_sample_attr() to
allow use of the original attribute value in vmevent_attr_sample_fn().

Cc: Anton Vorontsov &amp;lt;anton.vorontsov&amp;lt; at &amp;gt;linaro.org&amp;gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Signed-off-by: Kyungmin Park &amp;lt;kyungmin.park&amp;lt; at &amp;gt;samsung.com&amp;gt;
---
Without this patch vmevent_attr_lowmem_pages() always returns 0.

 mm/vmevent.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Index: b/mm/vmevent.c
===================================================================
--- a/mm/vmevent.c2012-05-22 17:55:02.000000000 +0200
+++ b/mm/vmevent.c2012-05-22 18:10:40.075231798 +0200
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -31,6 +31,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
  */
 unsigned longnr_attrs;
 struct vmevent_attr*sample_attrs;
+struct vmevent_attr*config_attrs[VMEVENT_CONFIG_MAX_ATTRS];
 
 /* samplin&lt;/pre&gt;</description>
    <dc:creator>Bartlomiej Zolnierkiewicz</dc:creator>
    <dc:date>2012-05-23T07:28:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78876">
    <title>[PATCH] vmevent: add arm support</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78876</link>
    <description>&lt;pre&gt;From: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Subject: [PATCH] vmevent: add arm support

Tested on ARM EXYNOS4210 (Universal C210 board).

Cc: Anton Vorontsov &amp;lt;anton.vorontsov&amp;lt; at &amp;gt;linaro.org&amp;gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Signed-off-by: Kyungmin Park &amp;lt;kyungmin.park&amp;lt; at &amp;gt;samsung.com&amp;gt;
---
 arch/arm/include/asm/unistd.h        |    1 +
 arch/arm/kernel/calls.S              |    1 +
 tools/testing/vmevent/vmevent-test.c |    3 +++
 3 files changed, 5 insertions(+)

Index: b/arch/arm/include/asm/unistd.h
===================================================================
--- a/arch/arm/include/asm/unistd.h2012-05-22 15:17:15.590826904 +0200
+++ b/arch/arm/include/asm/unistd.h2012-05-22 15:17:43.990826872 +0200
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -404,6 +404,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #define __NR_setns(__NR_SYSCALL_BASE+375)
 #define __NR_process_vm_readv(__NR_SYSCALL_BASE+376)
 #define __NR_process_vm_writev(__NR_SYSCALL_BASE+377)
+#define __NR_vmevent_fd(__NR_SYSCALL_BASE+378)
 
 /*
  * The following SWIs are AR&lt;/pre&gt;</description>
    <dc:creator>Bartlomiej Zolnierkiewicz</dc:creator>
    <dc:date>2012-05-23T07:27:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78875">
    <title>[PATCH 1/2] vmevent: don't leak unitialized data to userspace</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78875</link>
    <description>&lt;pre&gt;From: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Subject: [PATCH] vmevent: don't leak unitialized data to userspace

Remember to initialize all attrs[nr] fields in vmevent_setup_watch().

Cc: Anton Vorontsov &amp;lt;anton.vorontsov&amp;lt; at &amp;gt;linaro.org&amp;gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Signed-off-by: Kyungmin Park &amp;lt;kyungmin.park&amp;lt; at &amp;gt;samsung.com&amp;gt;
---
 mm/vmevent.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: b/mm/vmevent.c
===================================================================
--- a/mm/vmevent.c2012-05-22 17:51:13.195231958 +0200
+++ b/mm/vmevent.c2012-05-22 17:51:40.991231956 +0200
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -350,7 +350,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 
 attrs = new;
 
-attrs[nr++].type = attr-&amp;gt;type;
+attrs[nr].type = attr-&amp;gt;type;
+attrs[nr].value = 0;
+attrs[nr].state = 0;
+nr++;
 }
 
 watch-&amp;gt;sample_attrs= attrs;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo&amp;lt; at &amp;gt;kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfai&lt;/pre&gt;</description>
    <dc:creator>Bartlomiej Zolnierkiewicz</dc:creator>
    <dc:date>2012-05-23T07:27:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78874">
    <title>[PATCH] cma: cached pageblock type fixup</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78874</link>
    <description>&lt;pre&gt;From: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Subject: [PATCH] cma: cached pageblock type fixup

CMA pages added to per-cpu pages lists in free_hot_cold_page()
have private field set to MIGRATE_CMA pageblock type .  If this
happes just before start_isolate_page_range() in alloc_contig_range()
changes pageblock type of the page to MIGRATE_ISOLATE it may result
in the cached pageblock type being stale in free_pcppages_bulk()
(which may be triggered by drain_all_pages() in alloc_contig_range()),
page being added to MIGRATE_CMA free list instead of MIGRATE_ISOLATE
one in __free_one_page() and (if the page is reused just before
test_pages_isolated() check) causing alloc_contig_range() failure.

Fix such situation by checking whether pageblock type of the page
changed to MIGRATE_ISOLATE for MIGRATE_CMA type pages in
free_pcppages_bulk() and if so fixup the pageblock type to
MIGRATE_ISOLATE (so the page will be added to MIGRATE_ISOLATE free
list in __free_one_page() and won't be used).

Similar situati&lt;/pre&gt;</description>
    <dc:creator>Bartlomiej Zolnierkiewicz</dc:creator>
    <dc:date>2012-05-23T07:22:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78873">
    <title>[PATCH] cma: retry on test_pages_isolated() failure</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78873</link>
    <description>&lt;pre&gt;From: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Subject: [PATCH] cma: retry on test_pages_isolated() failure

Retry (once) migration on test_pages_isolated() failure.

Cc: Michal Nazarewicz &amp;lt;mina86&amp;lt; at &amp;gt;mina86.com&amp;gt;
Cc: Marek Szyprowski &amp;lt;m.szyprowski&amp;lt; at &amp;gt;samsung.com&amp;gt;
Cc: Mel Gorman &amp;lt;mgorman&amp;lt; at &amp;gt;suse.de&amp;gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &amp;lt;b.zolnierkie&amp;lt; at &amp;gt;samsung.com&amp;gt;
Signed-off-by: Kyungmin Park &amp;lt;kyungmin.park&amp;lt; at &amp;gt;samsung.com&amp;gt;
---
 mm/page_alloc.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: b/mm/page_alloc.c
===================================================================
--- a/mm/page_alloc.c2012-05-15 12:40:54.199127705 +0200
+++ b/mm/page_alloc.c2012-05-15 12:41:25.335127686 +0200
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -5796,7 +5796,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 {
 struct zone *zone = page_zone(pfn_to_page(start));
 unsigned long outer_start, outer_end;
-int ret = 0, order;
+int ret = 0, order, retry = 0;
 
 /*
  * What we do here is we mark all pageblocks in range as
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -5826,7 +5826,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
        pfn_max_align_up(end), migrat&lt;/pre&gt;</description>
    <dc:creator>Bartlomiej Zolnierkiewicz</dc:creator>
    <dc:date>2012-05-23T07:23:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78872">
    <title>[PATCH] mm: fix NULL ptr deref when walking hugepages</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78872</link>
    <description>&lt;pre&gt;A missing vlidation of the value returned by find_vma() could cause a NULL ptr
dereference when walking the pagetable.

This is triggerable from usermode by a simple user by trying to read a
page info out of /proc/pid/pagemap which doesn't exist.

Introduced by commit 025c5b24 ("thp: optimize away unnecessary page table
locking").

Signed-off-by: Sasha Levin &amp;lt;levinsasha928&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 fs/proc/task_mmu.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 3e564f0..885830b 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -820,7 +820,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int pagemap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 
 /* find the first VMA at or above 'addr' */
 vma = find_vma(walk-&amp;gt;mm, addr);
-if (pmd_trans_huge_lock(pmd, vma) == 1) {
+if (vma &amp;amp;&amp;amp; pmd_trans_huge_lock(pmd, vma) == 1) {
 for (; addr != end; addr += PAGE_SIZE) {
 unsigned long offset;
 
&lt;/pre&gt;</description>
    <dc:creator>Sasha Levin</dc:creator>
    <dc:date>2012-05-23T07:20:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78865">
    <title>[PATCH 1/2 v2] zsmalloc: zsmalloc: use unsigned long instead of void *</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78865</link>
    <description>&lt;pre&gt;We should use unsigned long as handle instead of void * to avoid any
confusion. Without this, users may just treat zs_malloc return value as
a pointer and try to deference it.

This patch passed compile test(zram, zcache and ramster) and zram is
tested on qemu.

changelog
  * from v1
 - change zcache's zv_create return value
        - baesd on next-20120522

Cc: Seth Jennings &amp;lt;sjenning&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
Cc: Dan Magenheimer &amp;lt;dan.magenheimer&amp;lt; at &amp;gt;oracle.com&amp;gt;
Cc: Konrad Rzeszutek Wilk &amp;lt;konrad.wilk&amp;lt; at &amp;gt;oracle.com&amp;gt;
Cc: Nitin Gupta &amp;lt;ngupta&amp;lt; at &amp;gt;vflare.org&amp;gt;
Signed-off-by: Minchan Kim &amp;lt;minchan&amp;lt; at &amp;gt;kernel.org&amp;gt;
---
 drivers/staging/zcache/zcache-main.c     |   12 ++++++------
 drivers/staging/zram/zram_drv.c          |   16 ++++++++--------
 drivers/staging/zram/zram_drv.h          |    2 +-
 drivers/staging/zsmalloc/zsmalloc-main.c |   24 ++++++++++++------------
 drivers/staging/zsmalloc/zsmalloc.h      |    8 ++++----
 5 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/zcache/zcache-main.c b/drivers/&lt;/pre&gt;</description>
    <dc:creator>Minchan Kim</dc:creator>
    <dc:date>2012-05-23T01:43:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78860">
    <title>[PATCH v4] mm: Fix slab-&gt;page flags corruption.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78860</link>
    <description>&lt;pre&gt;v3-v4:
- Added comments.
- Removed VM_BUG_ON on PageHead from put_page.
v2-v3:
- Check if page is still compound page after inc refcnt.
v1-v2:
- Avoid taking compound lock for slab pages.

--8&amp;lt;--------------------------cut here--------------------------&amp;gt;8--

Transparent huge pages can change page-&amp;gt;flags (PG_compound_lock)
without taking Slab lock. Since THP can not break slab pages we can
safely access compound page without taking compound lock.

Specifically this patch fixes race between compound_unlock and slab
functions which does page-flags update. This can occur when
get_page/put_page is called on page from slab object.

Reported-by: Amey Bhide &amp;lt;abhide&amp;lt; at &amp;gt;nicira.com&amp;gt;
Signed-off-by: Pravin B Shelar &amp;lt;pshelar&amp;lt; at &amp;gt;nicira.com&amp;gt;
Reviewed-by: Christoph Lameter &amp;lt;cl&amp;lt; at &amp;gt;linux.com&amp;gt;
---
 include/linux/mm.h |    2 ++
 mm/swap.c          |   34 +++++++++++++++++++++++++++++++++-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8437e93..ddd58ce 100644
--- a/include&lt;/pre&gt;</description>
    <dc:creator>Pravin B Shelar</dc:creator>
    <dc:date>2012-05-22T23:25:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78837">
    <title>memcg-devel git tree updated to 3.4</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78837</link>
    <description>&lt;pre&gt;Hi,
JFYI I have just pushed memcg patch queue rebased on top of v3.4.
You can find it at a usual place:
git&amp;lt; at &amp;gt;github.com:mstsxfx/memcg-devel.git in since-3.4 branch

I hope I haven't forgotten about anything (there quite some patches that
are sitting in mmotm but I haven't seen them in linux-next - statistics
cleanup by Johannes and lruvec cleanup by Hugh - and I will push them as
soon as they appear there).

Current shortlog on top of v3.4:

Aneesh Kumar K.V (15):
      hugetlb: rename max_hstate to hugetlb_max_hstate
      hugetlbfs: don't use ERR_PTR with VM_FAULT* values
      hugetlbfs: add an inline helper for finding hstate index
      hugetlb: use mmu_gather instead of a temporary linked list for accumulating pages
      hugetlb: avoid taking i_mmap_mutex in unmap_single_vma() for hugetlb
      hugetlb: simplify migrate_huge_page()
      memcg: add HugeTLB extension
      hugetlb: add charge/uncharge calls for HugeTLB alloc/free
      memcg: track resource index in cftype private
      hugetlbfs: add &lt;/pre&gt;</description>
    <dc:creator>Michal Hocko</dc:creator>
    <dc:date>2012-05-22T15:57:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78819">
    <title>[PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78819</link>
    <description>&lt;pre&gt;From: "Aneesh Kumar K.V" &amp;lt;aneesh.kumar&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;

Expose the failcnt details to userspace similar to memory and memsw.

Signed-off-by: Aneesh Kumar K.V &amp;lt;aneesh.kumar&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
---
 include/linux/hugetlb.h |    2 +-
 mm/memcontrol.c         |   40 ++++++++++++++++++++++++++--------------
 2 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index ee80bc8..cfe3cf5c 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -219,7 +219,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct hstate {
 unsigned int surplus_huge_pages_node[MAX_NUMNODES];
 #ifdef CONFIG_MEM_RES_CTLR_HUGETLB
 /* mem cgroup control files */
-struct cftype mem_cgroup_files[4];
+struct cftype mem_cgroup_files[5];
 #endif
 char name[HSTATE_NAME_LEN];
 };
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f142ea9..bacb0df 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -4189,7 +4189,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; out:
 static int mem_cgroup_reset(struct cgroup *cont, unsigned int event)
 {
 struct mem&lt;/pre&gt;</description>
    <dc:creator>Aneesh Kumar K.V</dc:creator>
    <dc:date>2012-05-22T11:43:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78812">
    <title>[PATCH 1/2] mm/memblock: cleanup on duplicate VA/PA conversion</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78812</link>
    <description>&lt;pre&gt;The overall memblock has been organized into the memory regions
and reserved regions. Initially, the memory regions and reserved
regions are stored in the predetermined arrays of "struct memblock
_region". It's possible for the arrays to be enlarged when we have
newly added regions for them, but no enough space there. Under the
situation, We will created double-sized array to meet the requirement.
However, the original implementation converted the VA (Virtual Address)
of the newly allocated array of regions to PA (Physical Address), then
translate back when we allocates the new array from slab. That's
actually unnecessary.

The patch removes the duplicate VA/PA conversion.

Signed-off-by: Gavin Shan &amp;lt;shangw&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
---
 mm/memblock.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index a44eab3..eae06ea 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -212,14 +212,15 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int __init_memblock memblock_double_array(struct memblock_type&lt;/pre&gt;</description>
    <dc:creator>Gavin Shan</dc:creator>
    <dc:date>2012-05-22T08:31:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78782">
    <title>[PATCH] hugetlb: fix resv_map leak in error path</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78782</link>
    <description>&lt;pre&gt;
When called for anonymous (non-shared) mappings,
hugetlb_reserve_pages() does a resv_map_alloc().  It depends on
code in hugetlbfs's vm_ops-&amp;gt;close() to release that allocation.

However, in the mmap() failure path, we do a plain unmap_region()
without the remove_vma() which actually calls vm_ops-&amp;gt;close().

This is a decent fix.  This leak could get reintroduced if
new code (say, after hugetlb_reserve_pages() in
hugetlbfs_file_mmap()) decides to return an error.  But, I think
it would have to unroll the reservation anyway.

This hasn't been extensively tested.  Pretty much compile and
boot tested along with Christoph's test case:

http://marc.info/?l=linux-mm&amp;amp;m=133728900729735

Signed-off-by: Dave Hansen &amp;lt;dave&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
Acked-by: Mel Gorman &amp;lt;mel&amp;lt; at &amp;gt;csn.ul.ie&amp;gt;
ecked-by: KOSAKI Motohiro &amp;lt;kosaki.motohiro&amp;lt; at &amp;gt;jp.fujitsu.com&amp;gt;
Reported/tested-by: Christoph Lameter &amp;lt;cl&amp;lt; at &amp;gt;linux.com&amp;gt;

---

 linux-2.6.git-dave/mm/hugetlb.c |   28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff -p&lt;/pre&gt;</description>
    <dc:creator>Dave Hansen</dc:creator>
    <dc:date>2012-05-21T20:28:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.mm/78770">
    <title>[PATCH] slab+slob: dup name string</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.mm/78770</link>
    <description>&lt;pre&gt;The slub allocator creates a copy of the name string, and
frees it later. I would like all caches to behave the same,
whether it is the slab+slob starting to create a copy of it itself,
or the slub ceasing to.

This patch creates copies of the name string for slob and slab,
adopting slub behavior for them all.

For the slab, we can't really do it before the kmalloc caches are
up. We need to rely that caches created before the state was set to
EARLY will never be destroyed.

Signed-off-by: Glauber Costa &amp;lt;glommer&amp;lt; at &amp;gt;parallels.com&amp;gt;
CC: Christoph Lameter &amp;lt;cl&amp;lt; at &amp;gt;linux.com&amp;gt;
CC: Pekka Enberg &amp;lt;penberg&amp;lt; at &amp;gt;cs.helsinki.fi&amp;gt;
CC: David Rientjes &amp;lt;rientjes&amp;lt; at &amp;gt;google.com&amp;gt;
---
 mm/slab.c |   10 ++++++++--
 mm/slob.c |   12 ++++++++++--
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index e901a36..cabd217 100644
--- a/mm/slab.c
+++ b/mm/slab.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2118,6 +2118,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void __kmem_cache_destroy(struct kmem_cache *cachep)
 kfree(l3);
 }
 }
+kfree(cachep-&amp;gt;name);
 kmem_cache_free(&amp;amp;cache_cach&lt;/pre&gt;</description>
    <dc:creator>Glauber Costa</dc:creator>
    <dc:date>2012-05-21T15:18:59</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.kernel.mm">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.kernel.mm</link>
  </textinput>
</rdf:RDF>

