<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v3.4.88</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs?h=v3.4.88</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs?h=v3.4.88'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-04-27T00:13:20Z</updated>
<entry>
<title>jffs2: remove from wait queue after schedule()</title>
<updated>2014-04-27T00:13:20Z</updated>
<author>
<name>Li Zefan</name>
<email>lizefan@huawei.com</email>
</author>
<published>2014-02-12T20:44:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=371d9bb7dab6293e79aafb5481b842629a60aa5e'/>
<id>urn:sha1:371d9bb7dab6293e79aafb5481b842629a60aa5e</id>
<content type='text'>
commit 3ead9578443b66ddb3d50ed4f53af8a0c0298ec5 upstream.

@wait is a local variable, so if we don't remove it from the wait queue
list, later wake_up() may end up accessing invalid memory.

This was spotted by eyes.

Signed-off-by: Li Zefan &lt;lizefan@huawei.com&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>jffs2: avoid soft-lockup in jffs2_reserve_space_gc()</title>
<updated>2014-04-27T00:13:20Z</updated>
<author>
<name>Li Zefan</name>
<email>lizefan@huawei.com</email>
</author>
<published>2014-02-12T20:44:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5c8e8e1378bb5be5600f8ed23d8bc61cc466b6eb'/>
<id>urn:sha1:5c8e8e1378bb5be5600f8ed23d8bc61cc466b6eb</id>
<content type='text'>
commit 13b546d96207c131eeae15dc7b26c6e7d0f1cad7 upstream.

We triggered soft-lockup under stress test on 2.6.34 kernel.

BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488]
...
[&lt;bf09a4d4&gt;] (jffs2_do_reserve_space+0x420/0x440 [jffs2])
[&lt;bf09a528&gt;] (jffs2_reserve_space_gc+0x34/0x78 [jffs2])
[&lt;bf0a1350&gt;] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2])
[&lt;bf0a2078&gt;] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2])
[&lt;bf09a670&gt;] (jffs2_reserve_space+0x104/0x2a8 [jffs2])
[&lt;bf09dc48&gt;] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2])
[&lt;bf097d8c&gt;] (jffs2_write_end+0x198/0x2c0 [jffs2])
[&lt;c00e00a4&gt;] (generic_file_buffered_write+0x158/0x200)
[&lt;c00e14f4&gt;] (__generic_file_aio_write+0x3a4/0x414)
[&lt;c00e15c0&gt;] (generic_file_aio_write+0x5c/0xbc)
[&lt;c012334c&gt;] (do_sync_write+0x98/0xd4)
[&lt;c0123a84&gt;] (vfs_write+0xa8/0x150)
[&lt;c0123d74&gt;] (sys_write+0x3c/0xc0)]

Fix this by adding a cond_resched() in the while loop.

[akpm@linux-foundation.org: don't initialize `ret']
Signed-off-by: Li Zefan &lt;lizefan@huawei.com&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>jffs2: Fix crash due to truncation of csize</title>
<updated>2014-04-27T00:13:20Z</updated>
<author>
<name>Ajesh Kunhipurayil Vijayan</name>
<email>ajesh@broadcom.com</email>
</author>
<published>2014-01-06T13:36:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b49c0b860779db3f81d88a1ba4edc9b2f2d27b96'/>
<id>urn:sha1:b49c0b860779db3f81d88a1ba4edc9b2f2d27b96</id>
<content type='text'>
commit 41bf1a24c1001f4d0d41a78e1ac575d2f14789d7 upstream.

mounting JFFS2 partition sometimes crashes with this call trace:

[ 1322.240000] Kernel bug detected[#1]:
[ 1322.244000] Cpu 2
[ 1322.244000] $ 0   : 0000000000000000 0000000000000018 000000003ff00070 0000000000000001
[ 1322.252000] $ 4   : 0000000000000000 c0000000f3980150 0000000000000000 0000000000010000
[ 1322.260000] $ 8   : ffffffffc09cd5f8 0000000000000001 0000000000000088 c0000000ed300de8
[ 1322.268000] $12   : e5e19d9c5f613a45 ffffffffc046d464 0000000000000000 66227ba5ea67b74e
[ 1322.276000] $16   : c0000000f1769c00 c0000000ed1e0200 c0000000f3980150 0000000000000000
[ 1322.284000] $20   : c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 c0000000f39818f0
[ 1322.292000] $24   : 0000000000000004 0000000000000000
[ 1322.300000] $28   : c0000000ed2c0000 c0000000ed2cfab8 0000000000010000 ffffffffc039c0b0
[ 1322.308000] Hi    : 000000000000023c
[ 1322.312000] Lo    : 000000000003f802
[ 1322.316000] epc   : ffffffffc039a9f8 check_tn_node+0x88/0x3b0
[ 1322.320000]     Not tainted
[ 1322.324000] ra    : ffffffffc039c0b0 jffs2_do_read_inode_internal+0x1250/0x1e48
[ 1322.332000] Status: 5400f8e3    KX SX UX KERNEL EXL IE
[ 1322.336000] Cause : 00800034
[ 1322.340000] PrId  : 000c1004 (Netlogic XLP)
[ 1322.344000] Modules linked in:
[ 1322.348000] Process jffs2_gcd_mtd7 (pid: 264, threadinfo=c0000000ed2c0000, task=c0000000f0e68dd8, tls=0000000000000000)
[ 1322.356000] Stack : c0000000f1769e30 c0000000ed010780 c0000000ed010780 c0000000ed300000
        c0000000f1769c00 c0000000f3980150 c0000000f3a80000 00000000fffffffc
        c0000000ed2cfbd8 ffffffffc039c0b0 ffffffffc09c6340 0000000000001000
        0000000000000dec ffffffffc016c9d8 c0000000f39805a0 c0000000f3980180
        0000008600000000 0000000000000000 0000000000000000 0000000000000000
        0001000000000dec c0000000f1769d98 c0000000ed2cfb18 0000000000010000
        0000000000010000 0000000000000044 c0000000f3a80000 c0000000f1769c00
        c0000000f3d207a8 c0000000f1769d98 c0000000f1769de0 ffffffffc076f9c0
        0000000000000009 0000000000000000 0000000000000000 ffffffffc039cf90
        0000000000000017 ffffffffc013fbdc 0000000000000001 000000010003e61c
        ...
[ 1322.424000] Call Trace:
[ 1322.428000] [&lt;ffffffffc039a9f8&gt;] check_tn_node+0x88/0x3b0
[ 1322.432000] [&lt;ffffffffc039c0b0&gt;] jffs2_do_read_inode_internal+0x1250/0x1e48
[ 1322.440000] [&lt;ffffffffc039cf90&gt;] jffs2_do_crccheck_inode+0x70/0xd0
[ 1322.448000] [&lt;ffffffffc03a1b80&gt;] jffs2_garbage_collect_pass+0x160/0x870
[ 1322.452000] [&lt;ffffffffc03a392c&gt;] jffs2_garbage_collect_thread+0xdc/0x1f0
[ 1322.460000] [&lt;ffffffffc01541c8&gt;] kthread+0xb8/0xc0
[ 1322.464000] [&lt;ffffffffc0106d18&gt;] kernel_thread_helper+0x10/0x18
[ 1322.472000]
[ 1322.472000]
Code: 67bd0050  94a4002c  2c830001 &lt;00038036&gt; de050218  2403fffc  0080a82d  00431824  24630044
[ 1322.480000] ---[ end trace b052bb90e97dfbf5 ]---

The variable csize in structure jffs2_tmp_dnode_info is of type uint16_t, but it
is used to hold the compressed data length(csize) which is declared as uint32_t.
So, when the value of csize exceeds 16bits, it gets truncated when assigned to
tn-&gt;csize. This is causing a kernel BUG.
Changing the definition of csize in jffs2_tmp_dnode_info to uint32_t fixes the issue.

Signed-off-by: Ajesh Kunhipurayil Vijayan &lt;ajesh@broadcom.com&gt;
Signed-off-by: Kamlakant Patel &lt;kamlakant.patel@broadcom.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>jffs2: Fix segmentation fault found in stress test</title>
<updated>2014-04-27T00:13:19Z</updated>
<author>
<name>Kamlakant Patel</name>
<email>kamlakant.patel@broadcom.com</email>
</author>
<published>2014-01-06T13:36:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3dba9e3a42493e2c6453f3863a999778ad3dd3b0'/>
<id>urn:sha1:3dba9e3a42493e2c6453f3863a999778ad3dd3b0</id>
<content type='text'>
commit 3367da5610c50e6b83f86d366d72b41b350b06a2 upstream.

Creating a large file on a JFFS2 partition sometimes crashes with this call
trace:

[  306.476000] CPU 13 Unable to handle kernel paging request at virtual address c0000000dfff8002, epc == ffffffffc03a80a8, ra == ffffffffc03a8044
[  306.488000] Oops[#1]:
[  306.488000] Cpu 13
[  306.492000] $ 0   : 0000000000000000 0000000000000000 0000000000008008 0000000000008007
[  306.500000] $ 4   : c0000000dfff8002 000000000000009f c0000000e0007cde c0000000ee95fa58
[  306.508000] $ 8   : 0000000000000001 0000000000008008 0000000000010000 ffffffffffff8002
[  306.516000] $12   : 0000000000007fa9 000000000000ff0e 000000000000ff0f 80e55930aebb92bb
[  306.524000] $16   : c0000000e0000000 c0000000ee95fa5c c0000000efc80000 ffffffffc09edd70
[  306.532000] $20   : ffffffffc2b60000 c0000000ee95fa58 0000000000000000 c0000000efc80000
[  306.540000] $24   : 0000000000000000 0000000000000004
[  306.548000] $28   : c0000000ee950000 c0000000ee95f738 0000000000000000 ffffffffc03a8044
[  306.556000] Hi    : 00000000000574a5
[  306.560000] Lo    : 6193b7a7e903d8c9
[  306.564000] epc   : ffffffffc03a80a8 jffs2_rtime_compress+0x98/0x198
[  306.568000]     Tainted: G        W
[  306.572000] ra    : ffffffffc03a8044 jffs2_rtime_compress+0x34/0x198
[  306.580000] Status: 5000f8e3    KX SX UX KERNEL EXL IE
[  306.584000] Cause : 00800008
[  306.588000] BadVA : c0000000dfff8002
[  306.592000] PrId  : 000c1100 (Netlogic XLP)
[  306.596000] Modules linked in:
[  306.596000] Process dd (pid: 170, threadinfo=c0000000ee950000, task=c0000000ee6e0858, tls=0000000000c47490)
[  306.608000] Stack : 7c547f377ddc7ee4 7ffc7f967f5d7fae 7f617f507fc37ff4 7e7d7f817f487f5f
        7d8e7fec7ee87eb3 7e977ff27eec7f9e 7d677ec67f917f67 7f3d7e457f017ed7
        7fd37f517f867eb2 7fed7fd17ca57e1d 7e5f7fe87f257f77 7fd77f0d7ede7fdb
        7fba7fef7e197f99 7fde7fe07ee37eb5 7f5c7f8c7fc67f65 7f457fb87f847e93
        7f737f3e7d137cd9 7f8e7e9c7fc47d25 7dbb7fac7fb67e52 7ff17f627da97f64
        7f6b7df77ffa7ec5 80057ef17f357fb3 7f767fa27dfc7fd5 7fe37e8e7fd07e53
        7e227fcf7efb7fa1 7f547e787fa87fcc 7fcb7fc57f5a7ffb 7fc07f6c7ea97e80
        7e2d7ed17e587ee0 7fb17f9d7feb7f31 7f607e797e887faa 7f757fdd7c607ff3
        7e877e657ef37fbd 7ec17fd67fe67ff7 7ff67f797ff87dc4 7eef7f3a7c337fa6
        7fe57fc97ed87f4b 7ebe7f097f0b8003 7fe97e2a7d997cba 7f587f987f3c7fa9
        ...
[  306.676000] Call Trace:
[  306.680000] [&lt;ffffffffc03a80a8&gt;] jffs2_rtime_compress+0x98/0x198
[  306.684000] [&lt;ffffffffc0394f10&gt;] jffs2_selected_compress+0x110/0x230
[  306.692000] [&lt;ffffffffc039508c&gt;] jffs2_compress+0x5c/0x388
[  306.696000] [&lt;ffffffffc039dc58&gt;] jffs2_write_inode_range+0xd8/0x388
[  306.704000] [&lt;ffffffffc03971bc&gt;] jffs2_write_end+0x16c/0x2d0
[  306.708000] [&lt;ffffffffc01d3d90&gt;] generic_file_buffered_write+0xf8/0x2b8
[  306.716000] [&lt;ffffffffc01d4e7c&gt;] __generic_file_aio_write+0x1ac/0x350
[  306.720000] [&lt;ffffffffc01d50a0&gt;] generic_file_aio_write+0x80/0x168
[  306.728000] [&lt;ffffffffc021f7dc&gt;] do_sync_write+0x94/0xf8
[  306.732000] [&lt;ffffffffc021ff6c&gt;] vfs_write+0xa4/0x1a0
[  306.736000] [&lt;ffffffffc02202e8&gt;] SyS_write+0x50/0x90
[  306.744000] [&lt;ffffffffc0116cc0&gt;] handle_sys+0x180/0x1a0
[  306.748000]
[  306.748000]
Code: 020b202d  0205282d  90a50000 &lt;90840000&gt; 14a40038  00000000  0060602d  0000282d  016c5823
[  306.760000] ---[ end trace 79dd088435be02d0 ]---
Segmentation fault

This crash is caused because the 'positions' is declared as an array of signed
short. The value of position is in the range 0..65535, and will be converted
to a negative number when the position is greater than 32767 and causes a
corruption and crash. Changing the definition to 'unsigned short' fixes this
issue

Signed-off-by: Jayachandran C &lt;jchandra@broadcom.com&gt;
Signed-off-by: Kamlakant Patel &lt;kamlakant.patel@broadcom.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>proc: pid/status: show all supplementary groups</title>
<updated>2014-04-14T13:44:15Z</updated>
<author>
<name>Artem Bityutskiy</name>
<email>artem.bityutskiy@linux.intel.com</email>
</author>
<published>2012-12-18T00:03:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4ca2cf4abaae2bda2feea8ec5eb0d18723a43553'/>
<id>urn:sha1:4ca2cf4abaae2bda2feea8ec5eb0d18723a43553</id>
<content type='text'>
commit 8d238027b87e654be552eabdf492042a34c5c300 upstream.

We display a list of supplementary group for each process in
/proc/&lt;pid&gt;/status.  However, we show only the first 32 groups, not all of
them.

Although this is rare, but sometimes processes do have more than 32
supplementary groups, and this kernel limitation breaks user-space apps
that rely on the group list in /proc/&lt;pid&gt;/status.

Number 32 comes from the internal NGROUPS_SMALL macro which defines the
length for the internal kernel "small" groups buffer.  There is no
apparent reason to limit to this value.

This patch removes the 32 groups printing limit.

The Linux kernel limits the amount of supplementary groups by NGROUPS_MAX,
which is currently set to 65536.  And this is the maximum count of groups
we may possibly print.

Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Acked-by: Serge E. Hallyn &lt;serge.hallyn@ubuntu.com&gt;
Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Qiang Huang &lt;h.huangqiang@huawei.com&gt;
Cc: Li Zefan &lt;lizefan@huawei.com&gt;
Cc: Jianguo Wu &lt;wujianguo@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: atomically set inode-&gt;i_flags in ext4_set_inode_flags()</title>
<updated>2014-04-03T18:58:46Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-03-30T14:20:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ff624a813eef9f51a8d4f3dd8e4f12db9286433d'/>
<id>urn:sha1:ff624a813eef9f51a8d4f3dd8e4f12db9286433d</id>
<content type='text'>
commit 00a1a053ebe5febcfc2ec498bd894f035ad2aa06 upstream.

Use cmpxchg() to atomically set i_flags instead of clearing out the
S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the
EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race
where an immutable file has the immutable flag cleared for a brief
window of time.

Reported-by: John Sullivan &lt;jsrhbz@kanargh.force9.co.uk&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&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>Btrfs: fix data corruption when reading/updating compressed extents</title>
<updated>2014-03-24T04:37:08Z</updated>
<author>
<name>Filipe David Borba Manana</name>
<email>fdmanana@gmail.com</email>
</author>
<published>2014-02-08T15:47:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dba79490e526dbca167e41b46745f168c356ffe5'/>
<id>urn:sha1:dba79490e526dbca167e41b46745f168c356ffe5</id>
<content type='text'>
commit a2aa75e18a21b21952dc6daa9bac7c9f4426f81f upstream.

When using a mix of compressed file extents and prealloc extents, it
is possible to fill a page of a file with random, garbage data from
some unrelated previous use of the page, instead of a sequence of zeroes.

A simple sequence of steps to get into such case, taken from the test
case I made for xfstests, is:

   _scratch_mkfs
   _scratch_mount "-o compress-force=lzo"
   $XFS_IO_PROG -f -c "pwrite -S 0x06 -b 18670 266978 18670" $SCRATCH_MNT/foobar
   $XFS_IO_PROG -c "falloc 26450 665194" $SCRATCH_MNT/foobar
   $XFS_IO_PROG -c "truncate 542872" $SCRATCH_MNT/foobar
   $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar

This results in the following file items in the fs tree:

   item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160
       inode generation 6 transid 6 size 542872 block group 0 mode 100600
   item 5 key (257 INODE_REF 256) itemoff 15863 itemsize 16
       inode ref index 2 namelen 6 name: foobar
   item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53
       extent data disk byte 0 nr 0 gen 6
       extent data offset 0 nr 24576 ram 266240
       extent compression 0
   item 7 key (257 EXTENT_DATA 24576) itemoff 15757 itemsize 53
       prealloc data disk byte 12849152 nr 241664 gen 6
       prealloc data offset 0 nr 241664
   item 8 key (257 EXTENT_DATA 266240) itemoff 15704 itemsize 53
       extent data disk byte 12845056 nr 4096 gen 6
       extent data offset 0 nr 20480 ram 20480
       extent compression 2
   item 9 key (257 EXTENT_DATA 286720) itemoff 15651 itemsize 53
       prealloc data disk byte 13090816 nr 405504 gen 6
       prealloc data offset 0 nr 258048

The on disk extent at offset 266240 (which corresponds to 1 single disk block),
contains 5 compressed chunks of file data. Each of the first 4 compress 4096
bytes of file data, while the last one only compresses 3024 bytes of file data.
Therefore a read into the file region [285648 ; 286720[ (length = 4096 - 3024 =
1072 bytes) should always return zeroes (our next extent is a prealloc one).

The solution here is the compression code path to zero the remaining (untouched)
bytes of the last page it uncompressed data into, as the information about how
much space the file data consumes in the last page is not known in the upper layer
fs/btrfs/extent_io.c:__do_readpage(). In __do_readpage we were correctly zeroing
the remainder of the page but only if it corresponds to the last page of the inode
and if the inode's size is not a multiple of the page size.

This would cause not only returning random data on reads, but also permanently
storing random data when updating parts of the region that should be zeroed.
For the example above, it means updating a single byte in the region [285648 ; 286720[
would store that byte correctly but also store random data on disk.

A test case for xfstests follows soon.

Signed-off-by: Filipe David Borba Manana &lt;fdmanana@gmail.com&gt;
Signed-off-by: Chris Mason &lt;clm@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fs/proc/base.c: fix GPF in /proc/$PID/map_files</title>
<updated>2014-03-24T04:37:06Z</updated>
<author>
<name>Artem Fetishev</name>
<email>artem_fetishev@epam.com</email>
</author>
<published>2014-03-10T22:49:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bfe635e52ede4c72819099b0fce72e28eec6e6c6'/>
<id>urn:sha1:bfe635e52ede4c72819099b0fce72e28eec6e6c6</id>
<content type='text'>
commit 70335abb2689c8cd5df91bf2d95a65649addf50b upstream.

The expected logic of proc_map_files_get_link() is either to return 0
and initialize 'path' or return an error and leave 'path' uninitialized.

By the time dname_to_vma_addr() returns 0 the corresponding vma may have
already be gone.  In this case the path is not initialized but the
return value is still 0.  This results in 'general protection fault'
inside d_path().

Steps to reproduce:

  CONFIG_CHECKPOINT_RESTORE=y

    fd = open(...);
    while (1) {
        mmap(fd, ...);
        munmap(fd, ...);
    }

  ls -la /proc/$PID/map_files

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=68991

Signed-off-by: Artem Fetishev &lt;artem_fetishev@epam.com&gt;
Signed-off-by: Aleksandr Terekhov &lt;aleksandr_terekhov@epam.com&gt;
Reported-by: &lt;wiebittewas@gmail.com&gt;
Acked-by: Pavel Emelyanov &lt;xemul@parallels.com&gt;
Acked-by: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Reviewed-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>NFS: Fix a delegation callback race</title>
<updated>2014-03-24T04:37:06Z</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@primarydata.com</email>
</author>
<published>2014-03-03T03:03:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e877d416818ff7439d01f88bf6d70131a27f730e'/>
<id>urn:sha1:e877d416818ff7439d01f88bf6d70131a27f730e</id>
<content type='text'>
commit 755a48a7a4eb05b9c8424e3017d947b2961a60e0 upstream.

The clean-up in commit 36281caa839f ended up removing a NULL pointer check
that is needed in order to prevent an Oops in
nfs_async_inode_return_delegation().

Reported-by: "Yan, Zheng" &lt;zheng.z.yan@intel.com&gt;
Link: http://lkml.kernel.org/r/5313E9F6.2020405@intel.com
Fixes: 36281caa839f (NFSv4: Further clean-ups of delegation stateid validation)
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ocfs2 syncs the wrong range...</title>
<updated>2014-03-24T04:37:03Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2014-02-10T20:18:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=efcb9185af1155146326a850aaa6617a5bb55172'/>
<id>urn:sha1:efcb9185af1155146326a850aaa6617a5bb55172</id>
<content type='text'>
commit 1b56e98990bcdbb20b9fab163654b9315bf158e8 upstream.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
