<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs, branch v3.10.7</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs?h=v3.10.7</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs?h=v3.10.7'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-08-15T05:59:10Z</updated>
<entry>
<title>reiserfs: fix deadlock in umount</title>
<updated>2013-08-15T05:59:10Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2013-08-05T13:37:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=71986ee029bada49f4517dbc6b0caf2243a566a2'/>
<id>urn:sha1:71986ee029bada49f4517dbc6b0caf2243a566a2</id>
<content type='text'>
commit 672fe15d091ce76d6fb98e489962e9add7c1ba4c upstream.

Since remove_proc_entry() started to wait for IO in progress (i.e.
since 2007 or so), the locking in fs/reiserfs/proc.c became wrong;
if procfs read happens between the moment when umount() locks the
victim superblock and removal of /proc/fs/reiserfs/&lt;device&gt;/*,
we'll get a deadlock - read will wait for s_umount (in sget(),
called by r_start()), while umount will wait in remove_proc_entry()
for that read to finish, holding s_umount all along.

Fortunately, the same change allows a much simpler race avoidance -
all we need to do is remove the procfs entries in the very beginning
of reiserfs -&gt;kill_sb(); that'll guarantee that pointer to superblock
will remain valid for the duration for procfs IO, so we don't need
sget() to keep the sucker alive.  As the matter of fact, we can
get rid of the home-grown iterator completely, and use single_open()
instead.

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>
<entry>
<title>debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)</title>
<updated>2013-08-15T05:59:10Z</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2013-07-26T15:12:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a9800654317a89b0224edbe51edcde8c54be2acc'/>
<id>urn:sha1:a9800654317a89b0224edbe51edcde8c54be2acc</id>
<content type='text'>
commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream.

debugfs_remove_recursive() is wrong,

1. it wrongly assumes that !list_empty(d_subdirs) means that this
   dir should be removed.

   This is not that bad by itself, but:

2. if d_subdirs does not becomes empty after __debugfs_remove()
   it gives up and silently fails, it doesn't even try to remove
   other entries.

   However -&gt;d_subdirs can be non-empty because it still has the
   already deleted !debugfs_positive() entries.

3. simple_release_fs() is called even if __debugfs_remove() fails.

Suppose we have

	dir1/
		dir2/
			file2
		file1

and someone opens dir1/dir2/file2.

Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes
away.

But debugfs_remove_recursive(dir1) silently fails and doesn't remove
this directory. Because it tries to delete (the already deleted)
dir1/dir2/file2 again and then fails due to "Avoid infinite loop"
logic.

Test-case:

	#!/bin/sh

	cd /sys/kernel/debug/tracing
	echo 'p:probe/sigprocmask sigprocmask' &gt;&gt; kprobe_events
	sleep 1000 &lt; events/probe/sigprocmask/id &amp;
	echo -n &gt;| kprobe_events

	[ -d events/probe ] &amp;&amp; echo "ERR!! failed to rm probe"

And after that it is not possible to create another probe entry.

With this patch debugfs_remove_recursive() skips !debugfs_positive()
files although this is not strictly needed. The most important change
is that it does not try to make -&gt;d_subdirs empty, it simply scans
the whole list(s) recursively and removes as much as possible.

Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.com

Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately</title>
<updated>2013-08-15T05:59:09Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2013-08-07T14:29:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d1e8adc0865d7091f3c437d984a8527259b80378'/>
<id>urn:sha1:d1e8adc0865d7091f3c437d984a8527259b80378</id>
<content type='text'>
commit 757c4f6260febff982276818bb946df89c1105aa upstream.

David reported that commit c2b93e06 (cifs: only set ops for inodes in
I_NEW state) caused a regression with mfsymlinks. Prior to that patch,
if a mfsymlink dentry was instantiated at readdir time, the inode would
get a new set of ops when it was revalidated. After that patch, this
did not occur.

This patch addresses this by simply skipping instantiating dentries in
the readdir codepath when we know that they will need to be immediately
revalidated. The next attempt to use that dentry will cause a new lookup
to occur (which is basically what we want to happen anyway).

Reported-and-Tested-by: David McBride &lt;dwm37@cam.ac.uk&gt;
Cc: "Stefan (metze) Metzmacher" &lt;metze@samba.org&gt;
Cc: Sachin Prabhu &lt;sprabhu@redhat.com&gt;
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;smfrench@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cifs: extend the buffer length enought for sprintf() using</title>
<updated>2013-08-15T05:59:09Z</updated>
<author>
<name>Chen Gang</name>
<email>gang.chen@asianux.com</email>
</author>
<published>2013-07-19T01:01:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4350018a57c333907db092beeb9fa65a82a258ed'/>
<id>urn:sha1:4350018a57c333907db092beeb9fa65a82a258ed</id>
<content type='text'>
commit 057d6332b24a4497c55a761c83c823eed9e3f23b upstream.

For cifs_set_cifscreds() in "fs/cifs/connect.c", 'desc' buffer length
is 'CIFSCREDS_DESC_SIZE' (56 is less than 256), and 'ses-&gt;domainName'
length may be "255 + '\0'".

The related sprintf() may cause memory overflow, so need extend related
buffer enough to hold all things.

It is also necessary to be sure of 'ses-&gt;domainName' must be less than
256, and define the related macro instead of hard code number '256'.

Signed-off-by: Chen Gang &lt;gang.chen@asianux.com&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Shirish Pargaonkar &lt;shirishpargaonkar@gmail.com&gt;
Reviewed-by: Scott Lovenberg &lt;scott.lovenberg@gmail.com&gt;
Signed-off-by: Steve French &lt;smfrench@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: flush the extent status cache during EXT4_IOC_SWAP_BOOT</title>
<updated>2013-08-15T05:59:09Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2013-08-12T13:29:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=72766b0bec55b104c414a22f2e8ecdbb6bb1e19e'/>
<id>urn:sha1:72766b0bec55b104c414a22f2e8ecdbb6bb1e19e</id>
<content type='text'>
commit cde2d7a796f7e895e25b43471ed658079345636d upstream.

Previously we weren't swapping only some of the extent_status LRU
fields during the processing of the EXT4_IOC_SWAP_BOOT ioctl.  The
much safer thing to do is to just completely flush the extent status
tree when doing the swap.

Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Cc: Zheng Liu &lt;gnehzuil.liu@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: fix mount/remount error messages for incompatible mount options</title>
<updated>2013-08-15T05:59:09Z</updated>
<author>
<name>Piotr Sarna</name>
<email>p.sarna@partner.samsung.com</email>
</author>
<published>2013-08-09T03:02:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c4fa10098c869072e96cca0f372b37d30fa10be2'/>
<id>urn:sha1:c4fa10098c869072e96cca0f372b37d30fa10be2</id>
<content type='text'>
commit 6ae6514b33f941d3386da0dfbe2942766eab1577 upstream.

Commit 5688978 ("ext4: improve handling of conflicting mount options")
introduced incorrect messages shown while choosing wrong mount options.

First of all, both cases of incorrect mount options,
"data=journal,delalloc" and "data=journal,dioread_nolock" result in
the same error message.

Secondly, the problem above isn't solved for remount option: the
mismatched parameter is simply ignored.  Moreover, ext4_msg states
that remount with options "data=journal,delalloc" succeeded, which is
not true.

To fix it up, I added a simple check after parse_options() call to
ensure that data=journal and delalloc/dioread_nolock parameters are
not present at the same time.

Signed-off-by: Piotr Sarna &lt;p.sarna@partner.samsung.com&gt;
Acked-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: allow the mount options nodelalloc and data=journal</title>
<updated>2013-08-15T05:59:09Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2013-08-09T03:01:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1929c51fc204bf84c5cbbd08861dd0a9da86b921'/>
<id>urn:sha1:1929c51fc204bf84c5cbbd08861dd0a9da86b921</id>
<content type='text'>
commit 59d9fa5c2e9086db11aa287bb4030151d0095a17 upstream.

Commit 26092bf ("ext4: use a table-driven handler for mount options")
wrongly disallows the specifying the mount options nodelalloc and
data=journal simultaneously.  This is incorrect; it should have only
disallowed the combination of delalloc and data=journal
simultaneously.

Reported-by: Piotr Sarna &lt;p.sarna@partner.samsung.com&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>LOCKD: Don't call utsname()-&gt;nodename from nlmclnt_setlockargs</title>
<updated>2013-08-15T05:59:08Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2013-08-05T16:06:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=870bfc6b47ecf64845dbf8e5d7a09877998e1b69'/>
<id>urn:sha1:870bfc6b47ecf64845dbf8e5d7a09877998e1b69</id>
<content type='text'>
commit 9a1b6bf818e74bb7aabaecb59492b739f2f4d742 upstream.

Firstly, nlmclnt_setlockargs can be called from a reclaimer thread, in
which case we're in entirely the wrong namespace.

Secondly, commit 8aac62706adaaf0fab02c4327761561c8bda9448 (move
exit_task_namespaces() outside of exit_notify()) now means that
exit_task_work() is called after exit_task_namespaces(), which
triggers an Oops when we're freeing up the locks.

Fix this by ensuring that we initialise the nlm_host's rpc_client at mount
time, so that the cl_nodename field is initialised to the value of
utsname()-&gt;nodename that the net namespace uses. Then replace the
lockd callers of utsname()-&gt;nodename.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Cc: Toralf Förster &lt;toralf.foerster@gmx.de&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Nix &lt;nix@esperi.org.uk&gt;
Cc: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Btrfs: release both paths before logging dir/changed extents</title>
<updated>2013-08-15T05:59:08Z</updated>
<author>
<name>Josef Bacik</name>
<email>jbacik@fusionio.com</email>
</author>
<published>2013-07-22T16:54:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=31a9bd79d76026a8c8cff63c6887483e2e766ee4'/>
<id>urn:sha1:31a9bd79d76026a8c8cff63c6887483e2e766ee4</id>
<content type='text'>
commit f3b15ccdbb9a79781578249a63318805e55a6c34 upstream.

The ceph guys tripped over this bug where we were still holding onto the
original path that we used to copy the inode with when logging.  This is based
on Chris's fix which was reported to fix the problem.  We need to drop the paths
in two cases anyway so just move the drop up so that we don't have duplicate
code.  Thanks,

Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
Signed-off-by: Chris Mason &lt;chris.mason@fusionio.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: fix retry handling in ext4_ext_truncate()</title>
<updated>2013-08-15T05:59:05Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2013-07-29T16:12:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c7039e94cecff031efbdc8ccf7e316c1c6130971'/>
<id>urn:sha1:c7039e94cecff031efbdc8ccf7e316c1c6130971</id>
<content type='text'>
commit 94eec0fc3520c759831763d866421b4d60b599b4 upstream.

We tested for ENOMEM instead of -ENOMEM.   Oops.

Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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