<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/fs/nfs/dir.c, branch linux-3.13.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.13.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.13.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2014-02-22T21:34:41+00:00</updated>
<entry>
<title>mm: fix page leak at nfs_symlink()</title>
<updated>2014-02-22T21:34:41+00:00</updated>
<author>
<name>Rafael Aquini</name>
<email>aquini@redhat.com</email>
</author>
<published>2014-02-10T22:25:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e54de0637c139aa700af18d12d9ee991f205a665'/>
<id>urn:sha1:e54de0637c139aa700af18d12d9ee991f205a665</id>
<content type='text'>
commit a0b54adda3fe4b4cc6d28f2a9217cd35d1aa888c upstream.

Changes in commit a0b8cab3b9b2 ("mm: remove lru parameter from
__pagevec_lru_add and remove parts of pagevec API") have introduced a
call to add_to_page_cache_lru() which causes a leak in nfs_symlink() as
now the page gets an extra refcount that is not dropped.

Jan Stancek observed and reported the leak effect while running test8
from Connectathon Testsuite.  After several iterations over the test
case, which creates several symlinks on a NFS mountpoint, the test
system was quickly getting into an out-of-memory scenario.

This patch fixes the page leak by dropping that extra refcount
add_to_page_cache_lru() is grabbing.

Signed-off-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Signed-off-by: Rafael Aquini &lt;aquini@redhat.com&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Acked-by: Rik van Riel &lt;riel@redhat.com&gt;
Cc: Jeff Layton &lt;jlayton@redhat.com&gt;
Cc: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2013-11-13T06:34:18+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-11-13T06:34:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9bc9ccd7db1c9f043f75380b5a5b94912046a60e'/>
<id>urn:sha1:9bc9ccd7db1c9f043f75380b5a5b94912046a60e</id>
<content type='text'>
Pull vfs updates from Al Viro:
 "All kinds of stuff this time around; some more notable parts:

   - RCU'd vfsmounts handling
   - new primitives for coredump handling
   - files_lock is gone
   - Bruce's delegations handling series
   - exportfs fixes

  plus misc stuff all over the place"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (101 commits)
  ecryptfs: -&gt;f_op is never NULL
  locks: break delegations on any attribute modification
  locks: break delegations on link
  locks: break delegations on rename
  locks: helper functions for delegation breaking
  locks: break delegations on unlink
  namei: minor vfs_unlink cleanup
  locks: implement delegations
  locks: introduce new FL_DELEG lock flag
  vfs: take i_mutex on renamed file
  vfs: rename I_MUTEX_QUOTA now that it's not used for quotas
  vfs: don't use PARENT/CHILD lock classes for non-directories
  vfs: pull ext4's double-i_mutex-locking into common code
  exportfs: fix quadratic behavior in filehandle lookup
  exportfs: better variable name
  exportfs: move most of reconnect_path to helper function
  exportfs: eliminate unused "noprogress" counter
  exportfs: stop retrying once we race with rename/remove
  exportfs: clear DISCONNECTED on all parents sooner
  exportfs: more detailed comment for path_reconnect
  ...
</content>
</entry>
<entry>
<title>Merge branch 'fscache' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into linux-next</title>
<updated>2013-10-28T23:36:46+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2013-10-28T23:33:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c698dbf9fecae54e5dc159cee76939228c533a25'/>
<id>urn:sha1:c698dbf9fecae54e5dc159cee76939228c533a25</id>
<content type='text'>
Pull fs-cache fixes from David Howells:

Can you pull these commits to fix an issue with NFS whereby caching can be
enabled on a file that is open for writing by subsequently opening it for
reading.  This can be made to crash by opening it for writing again if you're
quick enough.

The gist of the patchset is that the cookie should be acquired at inode
creation only and subsequently enabled and disabled as appropriate (which
dispenses with the backing objects when they're not needed).

The extra synchronisation that NFS does can then be dispensed with as it is
thenceforth managed by FS-Cache.

Could you send these on to Linus?

This likely will need fixing also in CIFS and 9P also once the FS-Cache
changes are upstream.  AFS and Ceph are probably safe.

* 'fscache' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
  NFS: Use i_writecount to control whether to get an fscache cookie in nfs_open()
  FS-Cache: Provide the ability to enable/disable cookies
  FS-Cache: Add use/unuse/wake cookie wrappers
</content>
</entry>
<entry>
<title>nfs: use IS_ROOT not DCACHE_DISCONNECTED</title>
<updated>2013-10-28T23:19:19+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2013-10-15T21:03:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a3f432bfd06a4ec3b812e32d3266e0d1ad75d008'/>
<id>urn:sha1:a3f432bfd06a4ec3b812e32d3266e0d1ad75d008</id>
<content type='text'>
This check was added by Al Viro with
d9e80b7de91db05c1c4d2e5ebbfd70b3b3ba0e0f "nfs d_revalidate() is too
trigger-happy with d_drop()", with the explanation that we don't want to
remove the root of a disconnected tree, which will still be included on
the s_anon list.

But DCACHE_DISCONNECTED does *not* actually identify dentries that are
disconnected from the dentry tree or hashed on s_anon.  IS_ROOT() is the
way to do that.

Also add a comment from Al's commit to remind us why this check is
there.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</content>
</entry>
<entry>
<title>nfs: use %p[dD] instead of open-coded (and often racy) equivalents</title>
<updated>2013-10-25T03:34:50+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2013-09-16T14:53:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6de1472f1a4a3bd912f515f29d3cf52a65a4c718'/>
<id>urn:sha1:6de1472f1a4a3bd912f515f29d3cf52a65a4c718</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>NFS: Use i_writecount to control whether to get an fscache cookie in nfs_open()</title>
<updated>2013-09-27T17:40:25+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-09-27T10:20:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f1fe29b4a02d0805aa7d0ff6b73410a9f9316d69'/>
<id>urn:sha1:f1fe29b4a02d0805aa7d0ff6b73410a9f9316d69</id>
<content type='text'>
Use i_writecount to control whether to get an fscache cookie in nfs_open() as
NFS does not do write caching yet.  I *think* this is the cause of a problem
encountered by Mark Moseley whereby __fscache_uncache_page() gets a NULL
pointer dereference because cookie-&gt;def is NULL:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [&lt;ffffffff812a1903&gt;] __fscache_uncache_page+0x23/0x160
PGD 0
Thread overran stack, or stack corrupted
Oops: 0000 [#1] SMP
Modules linked in: ...
CPU: 7 PID: 18993 Comm: php Not tainted 3.11.1 #1
Hardware name: Dell Inc. PowerEdge R420/072XWF, BIOS 1.3.5 08/21/2012
task: ffff8804203460c0 ti: ffff880420346640
RIP: 0010:[&lt;ffffffff812a1903&gt;] __fscache_uncache_page+0x23/0x160
RSP: 0018:ffff8801053af878 EFLAGS: 00210286
RAX: 0000000000000000 RBX: ffff8800be2f8780 RCX: ffff88022ffae5e8
RDX: 0000000000004c66 RSI: ffffea00055ff440 RDI: ffff8800be2f8780
RBP: ffff8801053af898 R08: 0000000000000001 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000000 R12: ffffea00055ff440
R13: 0000000000001000 R14: ffff8800c50be538 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88042fc60000(0063) knlGS:00000000e439c700
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000000000010 CR3: 0000000001d8f000 CR4: 00000000000607f0
Stack:
...
Call Trace:
[&lt;ffffffff81365a72&gt;] __nfs_fscache_invalidate_page+0x42/0x70
[&lt;ffffffff813553d5&gt;] nfs_invalidate_page+0x75/0x90
[&lt;ffffffff811b8f5e&gt;] truncate_inode_page+0x8e/0x90
[&lt;ffffffff811b90ad&gt;] truncate_inode_pages_range.part.12+0x14d/0x620
[&lt;ffffffff81d6387d&gt;] ? __mutex_lock_slowpath+0x1fd/0x2e0
[&lt;ffffffff811b95d3&gt;] truncate_inode_pages_range+0x53/0x70
[&lt;ffffffff811b969d&gt;] truncate_inode_pages+0x2d/0x40
[&lt;ffffffff811b96ff&gt;] truncate_pagecache+0x4f/0x70
[&lt;ffffffff81356840&gt;] nfs_setattr_update_inode+0xa0/0x120
[&lt;ffffffff81368de4&gt;] nfs3_proc_setattr+0xc4/0xe0
[&lt;ffffffff81357f78&gt;] nfs_setattr+0xc8/0x150
[&lt;ffffffff8122d95b&gt;] notify_change+0x1cb/0x390
[&lt;ffffffff8120a55b&gt;] do_truncate+0x7b/0xc0
[&lt;ffffffff8121f96c&gt;] do_last+0xa4c/0xfd0
[&lt;ffffffff8121ffbc&gt;] path_openat+0xcc/0x670
[&lt;ffffffff81220a0e&gt;] do_filp_open+0x4e/0xb0
[&lt;ffffffff8120ba1f&gt;] do_sys_open+0x13f/0x2b0
[&lt;ffffffff8126aaf6&gt;] compat_SyS_open+0x36/0x50
[&lt;ffffffff81d7204c&gt;] sysenter_dispatch+0x7/0x24

The code at the instruction pointer was disassembled:

&gt; (gdb) disas __fscache_uncache_page
&gt; Dump of assembler code for function __fscache_uncache_page:
&gt; ...
&gt; 0xffffffff812a18ff &lt;+31&gt;: mov 0x48(%rbx),%rax
&gt; 0xffffffff812a1903 &lt;+35&gt;: cmpb $0x0,0x10(%rax)
&gt; 0xffffffff812a1907 &lt;+39&gt;: je 0xffffffff812a19cd &lt;__fscache_uncache_page+237&gt;

These instructions make up:

	ASSERTCMP(cookie-&gt;def-&gt;type, !=, FSCACHE_COOKIE_TYPE_INDEX);

That cmpb is the faulting instruction (%rax is 0).  So cookie-&gt;def is NULL -
which presumably means that the cookie has already been at least partway
through __fscache_relinquish_cookie().

What I think may be happening is something like a three-way race on the same
file:

	PROCESS 1	PROCESS 2	PROCESS 3
	===============	===============	===============
	open(O_TRUNC|O_WRONLY)
			open(O_RDONLY)
					open(O_WRONLY)
	--&gt;nfs_open()
	--&gt;nfs_fscache_set_inode_cookie()
	nfs_fscache_inode_lock()
	nfs_fscache_disable_inode_cookie()
	__fscache_relinquish_cookie()
	nfs_inode-&gt;fscache = NULL
	&lt;--nfs_fscache_set_inode_cookie()

			--&gt;nfs_open()
			--&gt;nfs_fscache_set_inode_cookie()
			nfs_fscache_inode_lock()
			nfs_fscache_enable_inode_cookie()
			__fscache_acquire_cookie()
			nfs_inode-&gt;fscache = cookie
			&lt;--nfs_fscache_set_inode_cookie()
	&lt;--nfs_open()
	--&gt;nfs_setattr()
	...
	...
	--&gt;nfs_invalidate_page()
	--&gt;__nfs_fscache_invalidate_page()
	cookie = nfsi-&gt;fscache
					--&gt;nfs_open()
					--&gt;nfs_fscache_set_inode_cookie()
					nfs_fscache_inode_lock()
					nfs_fscache_disable_inode_cookie()
					--&gt;__fscache_relinquish_cookie()
	--&gt;__fscache_uncache_page(cookie)
	&lt;crash&gt;
					&lt;--__fscache_relinquish_cookie()
					nfs_inode-&gt;fscache = NULL
					&lt;--nfs_fscache_set_inode_cookie()

What is needed is something to prevent process #2 from reacquiring the cookie
- and I think checking i_writecount should do the trick.

It's also possible to have a two-way race on this if the file is opened
O_TRUNC|O_RDONLY instead.

Reported-by: Mark Moseley &lt;moseleymark@gmail.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
</entry>
<entry>
<title>NFSv4: Honour the 'opened' parameter in the atomic_open() filesystem method</title>
<updated>2013-09-26T14:20:18+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2013-09-23T22:01:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5bc2afc2b53fc73f154e6344cd898585628e6d27'/>
<id>urn:sha1:5bc2afc2b53fc73f154e6344cd898585628e6d27</id>
<content type='text'>
Determine if we've created a new file by examining the directory change
attribute and/or the O_EXCL flag.

This fixes a regression when doing a non-exclusive create of a new file.
If the FILE_CREATED flag is not set, the atomic_open() command will
perform full file access permissions checks instead of just checking
for MAY_OPEN.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
</content>
</entry>
<entry>
<title>nfs: set FILE_CREATED</title>
<updated>2013-09-16T23:17:24+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@suse.cz</email>
</author>
<published>2013-09-16T12:52:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=01c919abaf2f3d6a8e59eddf4ee22df1631ab067'/>
<id>urn:sha1:01c919abaf2f3d6a8e59eddf4ee22df1631ab067</id>
<content type='text'>
Set FILE_CREATED on O_CREAT|O_EXCL.  If the NFS server honored our request
for exclusivity then this must be correct.

Currently this is a no-op, since the VFS sets FILE_CREATED anyway.  The
next patch will, however, require this flag to be always set by
filesystems.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Cc: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>fs: convert fs shrinkers to new scan/count API</title>
<updated>2013-09-10T22:56:31+00:00</updated>
<author>
<name>Dave Chinner</name>
<email>dchinner@redhat.com</email>
</author>
<published>2013-08-28T00:18:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1ab6c4997e04a00c50c6d786c2f046adc0d1f5de'/>
<id>urn:sha1:1ab6c4997e04a00c50c6d786c2f046adc0d1f5de</id>
<content type='text'>
Convert the filesystem shrinkers to use the new API, and standardise some
of the behaviours of the shrinkers at the same time.  For example,
nr_to_scan means the number of objects to scan, not the number of objects
to free.

I refactored the CIFS idmap shrinker a little - it really needs to be
broken up into a shrinker per tree and keep an item count with the tree
root so that we don't need to walk the tree every time the shrinker needs
to count the number of objects in the tree (i.e.  all the time under
memory pressure).

[glommer@openvz.org: fixes for ext4, ubifs, nfs, cifs and glock. Fixes are needed mainly due to new code merged in the tree]
[assorted fixes folded in]
Signed-off-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Signed-off-by: Glauber Costa &lt;glommer@openvz.org&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Acked-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Acked-by: Jan Kara &lt;jack@suse.cz&gt;
Acked-by: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Cc: Arve Hjønnevåg &lt;arve@android.com&gt;
Cc: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: Gleb Natapov &lt;gleb@redhat.com&gt;
Cc: Greg Thelen &lt;gthelen@google.com&gt;
Cc: J. Bruce Fields &lt;bfields@redhat.com&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: Jerome Glisse &lt;jglisse@redhat.com&gt;
Cc: John Stultz &lt;john.stultz@linaro.org&gt;
Cc: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Cc: Kent Overstreet &lt;koverstreet@google.com&gt;
Cc: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Cc: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Cc: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>super: fix calculation of shrinkable objects for small numbers</title>
<updated>2013-09-10T22:56:29+00:00</updated>
<author>
<name>Glauber Costa</name>
<email>glommer@openvz.org</email>
</author>
<published>2013-08-28T00:17:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=55f841ce9395a72c6285fbcc4c403c0c786e1c74'/>
<id>urn:sha1:55f841ce9395a72c6285fbcc4c403c0c786e1c74</id>
<content type='text'>
The sysctl knob sysctl_vfs_cache_pressure is used to determine which
percentage of the shrinkable objects in our cache we should actively try
to shrink.

It works great in situations in which we have many objects (at least more
than 100), because the aproximation errors will be negligible.  But if
this is not the case, specially when total_objects &lt; 100, we may end up
concluding that we have no objects at all (total / 100 = 0, if total &lt;
100).

This is certainly not the biggest killer in the world, but may matter in
very low kernel memory situations.

Signed-off-by: Glauber Costa &lt;glommer@openvz.org&gt;
Reviewed-by: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Acked-by: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Dave Chinner &lt;david@fromorbit.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Cc: Arve Hjønnevåg &lt;arve@android.com&gt;
Cc: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: Gleb Natapov &lt;gleb@redhat.com&gt;
Cc: Greg Thelen &lt;gthelen@google.com&gt;
Cc: J. Bruce Fields &lt;bfields@redhat.com&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: Jerome Glisse &lt;jglisse@redhat.com&gt;
Cc: John Stultz &lt;john.stultz@linaro.org&gt;
Cc: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Cc: Kent Overstreet &lt;koverstreet@google.com&gt;
Cc: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Cc: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Cc: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
</feed>
