<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/reiserfs/dir.c, branch linux-3.14.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.14.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.14.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2014-05-06T14:59:29Z</updated>
<entry>
<title>reiserfs: fix race in readdir</title>
<updated>2014-05-06T14:59:29Z</updated>
<author>
<name>Jeff Mahoney</name>
</author>
<published>2014-04-02T18:40:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3defef4e960c9b3ab1026b9b5a1f0393be5b0536'/>
<id>urn:sha1:3defef4e960c9b3ab1026b9b5a1f0393be5b0536</id>
<content type='text'>
commit 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44 upstream.

jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2)

The -ENOENT is due to readdir calling dir_emit on the same entry twice.

If the dir_emit callback sleeps and the tree is changed underneath us,
we won't be able to trust deh_offset(deh) anymore. We need to save
next_pos before we might sleep so we can find the next entry.

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&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>reiserfs: locking, handle nested locks properly</title>
<updated>2013-08-08T21:34:46Z</updated>
<author>
<name>Jeff Mahoney</name>
</author>
<published>2013-08-08T21:34:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=278f6679f454bf185a07d9a4ca355b153482d17a'/>
<id>urn:sha1:278f6679f454bf185a07d9a4ca355b153482d17a</id>
<content type='text'>
The reiserfs write lock replaced the BKL and uses similar semantics.

Frederic's locking code makes a distinction between when the lock is nested
and when it's being acquired/released, but I don't think that's the right
distinction to make.

The right distinction is between the lock being released at end-of-use and
the lock being released for a schedule. The unlock should return the depth
and the lock should restore it, rather than the other way around as it is now.

This patch implements that and adds a number of places where the lock
should be dropped.

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
</content>
</entry>
<entry>
<title>reiserfs: switch reiserfs_readdir_dentry to inode</title>
<updated>2013-06-29T08:56:51Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2013-05-18T02:58:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cd62cdae0bd7fb76cae66347dc4fc00e87ffc1c4'/>
<id>urn:sha1:cd62cdae0bd7fb76cae66347dc4fc00e87ffc1c4</id>
<content type='text'>
... and clean the callers up a bit

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>reiserfs: is_privroot_deh() needs only directory inode, actually</title>
<updated>2013-06-29T08:56:50Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2013-05-18T02:45:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=99ce4169a9ff1c6ecdcccf01638eb6d76e5d84d1'/>
<id>urn:sha1:99ce4169a9ff1c6ecdcccf01638eb6d76e5d84d1</id>
<content type='text'>
... and that - only to get the superblock.  Privroot is a directory
and we don't allow hardlinks to those...

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>[readdir] convert reiserfs</title>
<updated>2013-06-29T08:56:49Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2013-05-18T02:42:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4acf381e1b6c01d6058d353191259c952bd6f3e7'/>
<id>urn:sha1:4acf381e1b6c01d6058d353191259c952bd6f3e7</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>reiserfs: fix spurious multiple-fill in reiserfs_readdir_dentry</title>
<updated>2013-05-31T21:13:58Z</updated>
<author>
<name>Jeff Mahoney</name>
</author>
<published>2013-05-31T19:07:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0bdc7acba56a7ca4232f15f37b16f7ec079385ab'/>
<id>urn:sha1:0bdc7acba56a7ca4232f15f37b16f7ec079385ab</id>
<content type='text'>
After sleeping for filldir(), we check to see if the file system has
changed and research. The next_pos pointer is updated but its value
isn't pushed into the key used for the search itself. As a result,
the search returns the same item that the last cycle of the loop did
and filldir() is called multiple times with the same data.

The end result is that the buffer can contain the same name multiple
times. This can be returned to userspace or used internally in the
xattr code where it can manifest with the following warning:

jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2)

reiserfs_for_each_xattr uses reiserfs_readdir_dentry to iterate over
the xattr names and ends up trying to unlink the same name twice. The
second attempt fails with -ENOENT and the error is returned. At some
point I'll need to add support into reiserfsck to remove the orphaned
directories left behind when this occurs.

The fix is to push the value into the key before researching.

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>move private bits of reiserfs_fs.h to fs/reiserfs/reiserfs.h</title>
<updated>2012-03-21T01:29:43Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2012-03-17T05:16:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f466c6fdb3b1f043ff1977a8d2a1d0cd4dc164fa'/>
<id>urn:sha1:f466c6fdb3b1f043ff1977a8d2a1d0cd4dc164fa</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>fs: push i_mutex and filemap_write_and_wait down into -&gt;fsync() handlers</title>
<updated>2011-07-21T00:47:59Z</updated>
<author>
<name>Josef Bacik</name>
</author>
<published>2011-07-17T00:44:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=02c24a82187d5a628c68edfe71ae60dc135cd178'/>
<id>urn:sha1:02c24a82187d5a628c68edfe71ae60dc135cd178</id>
<content type='text'>
Btrfs needs to be able to control how filemap_write_and_wait_range() is called
in fsync to make it less of a painful operation, so push down taking i_mutex and
the calling of filemap_write_and_wait() down into the -&gt;fsync() handlers.  Some
file systems can drop taking the i_mutex altogether it seems, like ext3 and
ocfs2.  For correctness sake I just pushed everything down in all cases to make
sure that we keep the current behavior the same for everybody, and then each
individual fs maintainer can make up their mind about what to do from there.
Thanks,

Acked-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>drop unused dentry argument to -&gt;fsync</title>
<updated>2010-05-28T02:05:02Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2010-05-26T15:53:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7ea8085910ef3dd4f3cad6845aaa2b580d39b115'/>
<id>urn:sha1:7ea8085910ef3dd4f3cad6845aaa2b580d39b115</id>
<content type='text'>
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>fs/: do not fallback to default_llseek() when readdir() uses BKL</title>
<updated>2010-05-27T16:12:56Z</updated>
<author>
<name>jan Blunck</name>
</author>
<published>2010-05-26T21:44:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ca572727dbb945e443564029a495157fd2e72995'/>
<id>urn:sha1:ca572727dbb945e443564029a495157fd2e72995</id>
<content type='text'>
Do not use the fallback default_llseek() if the readdir operation of the
filesystem still uses the big kernel lock.

Since llseek() modifies
file-&gt;f_pos of the directory directly it may need locking to not confuse
readdir which usually uses file-&gt;f_pos directly as well

Since the special characteristics of the BKL (unlocked on schedule) are
not necessary in this case, the inode mutex can be used for locking as
provided by generic_file_llseek().  This is only possible since all
filesystems, except reiserfs, either use a directory as a flat file or
with disk address offsets.  Reiserfs on the other hand uses a 32bit hash
off the filename as the offset so generic_file_llseek() can get used as
well since the hash is always smaller than sb-&gt;s_maxbytes (= (512 &lt;&lt; 32) -
blocksize).

Signed-off-by: Jan Blunck &lt;jblunck@suse.de&gt;
Acked-by: Jan Kara &lt;jack@suse.cz&gt;
Acked-by: Anders Larsen &lt;al@alarsen.net&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
