<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v3.0.44</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs?h=v3.0.44</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs?h=v3.0.44'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-10-02T16:47:54Z</updated>
<entry>
<title>Squashfs: fix mount time sanity check for corrupted superblock</title>
<updated>2012-10-02T16:47:54Z</updated>
<author>
<name>Phillip Lougher</name>
<email>phillip@squashfs.org.uk</email>
</author>
<published>2012-01-02T17:47:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9523d5244a925f514e5daf04e5030a68e91f55cd'/>
<id>urn:sha1:9523d5244a925f514e5daf04e5030a68e91f55cd</id>
<content type='text'>
commit cc37f75a9ffbbfcb1c3297534f293c8284e3c5a6 upstream.

A Squashfs filesystem containing nothing but an empty directory,
although unusual and ultimately pointless, is still valid.

The directory_table &gt;= next_table sanity check rejects these
filesystems as invalid because the directory_table is empty and
equal to next_table.

Signed-off-by: Phillip Lougher &lt;phillip@squashfs.org.uk&gt;
Cc: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFS: return error from decode_getfh in decode open</title>
<updated>2012-10-02T16:47:38Z</updated>
<author>
<name>Weston Andros Adamson</name>
<email>dros@netapp.com</email>
</author>
<published>2012-09-06T19:54:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=863f36bf5ad7edde2ec1196b098fec951fca16d3'/>
<id>urn:sha1:863f36bf5ad7edde2ec1196b098fec951fca16d3</id>
<content type='text'>
commit 01913b49cf1dc6409a07dd2a4cc6af2e77f3c410 upstream.

If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last
decode_* call must have succeeded.

Signed-off-by: Weston Andros Adamson &lt;dros@netapp.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFS: Fix a problem with the legacy binary mount code</title>
<updated>2012-10-02T16:47:38Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2012-09-04T15:05:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d351ebe91e308cebfefc6808fd96a53c9d8f0c7b'/>
<id>urn:sha1:d351ebe91e308cebfefc6808fd96a53c9d8f0c7b</id>
<content type='text'>
commit 872ece86ea5c367aa92f44689c2d01a1c767aeb3 upstream.

Apparently, am-utils is still using the legacy binary mountdata interface,
and is having trouble parsing /proc/mounts due to the 'port=' field being
incorrectly set.

The following patch should fix up the regression.

Reported-by: Marius Tolzmann &lt;tolzmann@molgen.mpg.de&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFS: Fix the initialisation of the readdir 'cookieverf' array</title>
<updated>2012-10-02T16:47:38Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2012-09-03T18:56:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=839e17b7fb531eec48714abf5962b0a1310f71d9'/>
<id>urn:sha1:839e17b7fb531eec48714abf5962b0a1310f71d9</id>
<content type='text'>
commit c3f52af3e03013db5237e339c817beaae5ec9e3a upstream.

When the NFS_COOKIEVERF helper macro was converted into a static
inline function in commit 99fadcd764 (nfs: convert NFS_*(inode)
helpers to static inline), we broke the initialisation of the
readdir cookies, since that depended on doing a memset with an
argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore
changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *).

At this point, NFS_COOKIEVERF seems to be more of an obfuscation
than a helper, so the best thing would be to just get rid of it.

Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881

Reported-by: Andi Kleen &lt;andi@firstfloor.org&gt;
Reported-by: David Binderman &lt;dcb314@hotmail.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>eCryptfs: Copy up attributes of the lower target inode after rename</title>
<updated>2012-10-02T16:47:23Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-09-13T19:00:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=047b8d01518246de438ba76a957889b6e661638e'/>
<id>urn:sha1:047b8d01518246de438ba76a957889b6e661638e</id>
<content type='text'>
commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a upstream.

After calling into the lower filesystem to do a rename, the lower target
inode's attributes were not copied up to the eCryptfs target inode. This
resulted in the eCryptfs target inode staying around, rather than being
evicted, because i_nlink was not updated for the eCryptfs inode. This
also meant that eCryptfs didn't do the final iput() on the lower target
inode so it stayed around, as well. This would result in a failure to
free up space occupied by the target file in the rename() operation.
Both target inodes would eventually be evicted when the eCryptfs
filesystem was unmounted.

This patch calls fsstack_copy_attr_all() after the lower filesystem
does its -&gt;rename() so that important inode attributes, such as i_nlink,
are updated at the eCryptfs layer. ecryptfs_evict_inode() is now called
and eCryptfs can drop its final reference on the lower inode.

http://launchpad.net/bugs/561129

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Tested-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vfs: dcache: use DCACHE_DENTRY_KILLED instead of DCACHE_DISCONNECTED in d_kill()</title>
<updated>2012-10-02T16:47:23Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@suse.cz</email>
</author>
<published>2012-09-17T20:31:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8b2b69f4e7a4cd7768323f84f17f09ab608e620d'/>
<id>urn:sha1:8b2b69f4e7a4cd7768323f84f17f09ab608e620d</id>
<content type='text'>
commit b161dfa6937ae46d50adce8a7c6b12233e96e7bd upstream.

IBM reported a soft lockup after applying the fix for the rename_lock
deadlock.  Commit c83ce989cb5f ("VFS: Fix the nfs sillyrename regression
in kernel 2.6.38") was found to be the culprit.

The nfs sillyrename fix used DCACHE_DISCONNECTED to indicate that the
dentry was killed.  This flag can be set on non-killed dentries too,
which results in infinite retries when trying to traverse the dentry
tree.

This patch introduces a separate flag: DCACHE_DENTRY_KILLED, which is
only set in d_kill() and makes try_to_ascend() test only this flag.

IBM reported successful test results with this patch.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Cc: Trond Myklebust &lt;Trond.Myklebust@netapp.com&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>vfs: make O_PATH file descriptors usable for 'fstat()'</title>
<updated>2012-10-02T16:47:23Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-09-14T21:48:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c168d49dbb4bc6cbd58b855166e5f98585479307'/>
<id>urn:sha1:c168d49dbb4bc6cbd58b855166e5f98585479307</id>
<content type='text'>
commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 upstream.

We already use them for openat() and friends, but fstat() also wants to
be able to use O_PATH file descriptors.  This should make it more
directly comparable to the O_SEARCH of Solaris.

Note that you could already do the same thing with "fstatat()" and an
empty path, but just doing "fstat()" directly is simpler and faster, so
there is no reason not to just allow it directly.

See also commit 332a2e1244bd, which did the same thing for fchdir, for
the same reasons.

Reported-by: ольга крыжановская &lt;olga.kryzhanovska@gmail.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&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>fuse: fix retrieve length</title>
<updated>2012-09-14T17:00:50Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@suse.cz</email>
</author>
<published>2012-09-04T16:45:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=fd63204e4873e9cbabd819ffdc15f3bcd85c6674'/>
<id>urn:sha1:fd63204e4873e9cbabd819ffdc15f3bcd85c6674</id>
<content type='text'>
commit c9e67d483776d8d2a5f3f70491161b205930ffe1 upstream.

In some cases fuse_retrieve() would return a short byte count if offset was
non-zero.  The data returned was correct, though.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext3: Fix fdatasync() for files with only i_size changes</title>
<updated>2012-09-14T17:00:50Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2012-09-03T14:50:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=04234b36211285e5242794b75137f42f177e0ef5'/>
<id>urn:sha1:04234b36211285e5242794b75137f42f177e0ef5</id>
<content type='text'>
commit 156bddd8e505b295540f3ca0e27dda68cb0d49aa upstream.

Code tracking when transaction needs to be committed on fdatasync(2) forgets
to handle a situation when only inode's i_size is changed. Thus in such
situations fdatasync(2) doesn't force transaction with new i_size to disk
and that can result in wrong i_size after a crash.

Fix the issue by updating inode's i_datasync_tid whenever its size is
updated.

Reported-by: Kristian Nielsen &lt;knielsen@knielsen-hq.org&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>udf: Fix data corruption for files in ICB</title>
<updated>2012-09-14T17:00:50Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2012-09-05T13:48:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=31147bc619c3379e335726e071ea012784ad9877'/>
<id>urn:sha1:31147bc619c3379e335726e071ea012784ad9877</id>
<content type='text'>
commit 9c2fc0de1a6e638fe58c354a463f544f42a90a09 upstream.

When a file is stored in ICB (inode), we overwrite part of the file, and
the page containing file's data is not in page cache, we end up corrupting
file's data by overwriting them with zeros. The problem is we use
simple_write_begin() which simply zeroes parts of the page which are not
written to. The problem has been introduced by be021ee4 (udf: convert to
new aops).

Fix the problem by providing a -&gt;write_begin function which makes the page
properly uptodate.

Reported-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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