<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs/configfs, branch v2.6.39-rc2</title>
<subtitle>Linux Kernel (branches are rebased on master from time to time)</subtitle>
<id>https://sre.ring0.de/linux/atom?h=v2.6.39-rc2</id>
<link rel='self' href='https://sre.ring0.de/linux/atom?h=v2.6.39-rc2'/>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/'/>
<updated>2011-01-16T21:22:29Z</updated>
<entry>
<title>configfs: change depends -&gt; select SYSFS</title>
<updated>2011-01-16T21:22:29Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2011-01-16T21:11:25Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=e205117285d6035af135c9d6c34a30ee6b8d1f2e'/>
<id>urn:sha1:e205117285d6035af135c9d6c34a30ee6b8d1f2e</id>
<content type='text'>
This patch changes configfs to select SYSFS to fix the following:

warning: (TARGET_CORE &amp;&amp; GFS2_FS) selects CONFIGFS_FS which has unmet direct dependencies (SYSFS)

Reported-by: Randy Dunlap &lt;randy.dunlap@oracle.com&gt;
Signed-off-by: Nicholas A. Bellinger &lt;nab@linux-iscsi.org&gt;
Acked-by: Joel Becker &lt;jlbec@evilplan.org&gt;
</content>
</entry>
<entry>
<title>switch configfs</title>
<updated>2011-01-13T01:03:12Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2011-01-12T21:41:05Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=d463a0c4b53a8fab505fd9aa3a1a04cb9f411b78'/>
<id>urn:sha1:d463a0c4b53a8fab505fd9aa3a1a04cb9f411b78</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>fs: dcache reduce branches in lookup path</title>
<updated>2011-01-07T06:50:28Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2011-01-07T06:49:55Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=fb045adb99d9b7c562dc7fef834857f78249daa1'/>
<id>urn:sha1:fb045adb99d9b7c562dc7fef834857f78249daa1</id>
<content type='text'>
Reduce some branches and memory accesses in dcache lookup by adding dentry
flags to indicate common d_ops are set, rather than having to check them.
This saves a pointer memory access (dentry-&gt;d_op) in common path lookup
situations, and saves another pointer load and branch in cases where we
have d_op but not the particular operation.

Patched with:

git grep -E '[.&gt;]([[:space:]])*d_op([[:space:]])*=' | xargs sed -e 's/\([^\t ]*\)-&gt;d_op = \(.*\);/d_set_d_op(\1, \2);/' -e 's/\([^\t ]*\)\.d_op = \(.*\);/d_set_d_op(\&amp;\1, \2);/' -i

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
</content>
</entry>
<entry>
<title>fs: dcache rationalise dget variants</title>
<updated>2011-01-07T06:50:24Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2011-01-07T06:49:43Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=dc0474be3e27463d4d4a2793f82366eed906f223'/>
<id>urn:sha1:dc0474be3e27463d4d4a2793f82366eed906f223</id>
<content type='text'>
dget_locked was a shortcut to avoid the lazy lru manipulation when we already
held dcache_lock (lru manipulation was relatively cheap at that point).
However, how that the lru lock is an innermost one, we never hold it at any
caller, so the lock cost can now be avoided. We already have well working lazy
dcache LRU, so it should be fine to defer LRU manipulations to scan time.

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
</content>
</entry>
<entry>
<title>fs: dcache remove dcache_lock</title>
<updated>2011-01-07T06:50:23Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2011-01-07T06:49:38Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=b5c84bf6f6fa3a7dfdcb556023a62953574b60ee'/>
<id>urn:sha1:b5c84bf6f6fa3a7dfdcb556023a62953574b60ee</id>
<content type='text'>
dcache_lock no longer protects anything. remove it.

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
</content>
</entry>
<entry>
<title>fs: dcache scale d_unhashed</title>
<updated>2011-01-07T06:50:21Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2011-01-07T06:49:33Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=da5029563a0a026c64821b09e8e7b4fd81d3fe1b'/>
<id>urn:sha1:da5029563a0a026c64821b09e8e7b4fd81d3fe1b</id>
<content type='text'>
Protect d_unhashed(dentry) condition with d_lock. This means keeping
DCACHE_UNHASHED bit in synch with hash manipulations.

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
</content>
</entry>
<entry>
<title>fs: dcache scale dentry refcount</title>
<updated>2011-01-07T06:50:21Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2011-01-07T06:49:32Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=b7ab39f631f505edc2bbdb86620d5493f995c9da'/>
<id>urn:sha1:b7ab39f631f505edc2bbdb86620d5493f995c9da</id>
<content type='text'>
Make d_count non-atomic and protect it with d_lock. This allows us to ensure a
0 refcount dentry remains 0 without dcache_lock. It is also fairly natural when
we start protecting many other dentry members with d_lock.

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
</content>
</entry>
<entry>
<title>fs: change d_delete semantics</title>
<updated>2011-01-07T06:50:18Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2011-01-07T06:49:23Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=fe15ce446beb3a33583af81ffe6c9d01a75314ed'/>
<id>urn:sha1:fe15ce446beb3a33583af81ffe6c9d01a75314ed</id>
<content type='text'>
Change d_delete from a dentry deletion notification to a dentry caching
advise, more like -&gt;drop_inode. Require it to be constant and idempotent,
and not take d_lock. This is how all existing filesystems use the callback
anyway.

This makes fine grained dentry locking of dput and dentry lru scanning
much simpler.

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
</content>
</entry>
<entry>
<title>config fs: avoid switching -&gt;d_op on live dentry</title>
<updated>2011-01-07T06:50:17Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2011-01-07T06:49:21Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=fbc8d4c04626e015b18cc61199f505920abb48f0'/>
<id>urn:sha1:fbc8d4c04626e015b18cc61199f505920abb48f0</id>
<content type='text'>
Switching d_op on a live dentry is racy in general, so avoid it. In this case
it is a negative dentry, which is safer, but there are still concurrent ops
which may be called on d_op in that case (eg. d_revalidate). So in general
a filesystem may not do this. Fix configfs so as not to do this.

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
</content>
</entry>
<entry>
<title>convert get_sb_single() users</title>
<updated>2010-10-29T08:16:28Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2010-07-24T21:48:30Z</published>
<link rel='alternate' type='text/html' href='https://sre.ring0.de/linux/commit/?id=fc14f2fef682df677d64a145256dbd263df2aa7b'/>
<id>urn:sha1:fc14f2fef682df677d64a145256dbd263df2aa7b</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
</feed>
