<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/jffs2, branch v2.6.23</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[JFFS2] fix write deadlock regression</title>
<updated>2007-09-02T17:18:38+00:00</updated>
<author>
<name>Jason Lunz</name>
<email>lunz@falooley.org</email>
</author>
<published>2007-09-01T19:06:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fc0e01974ccccc7530b7634a63ee3fcc57b845ea'/>
<id>fc0e01974ccccc7530b7634a63ee3fcc57b845ea</id>
<content type='text'>
I've bisected the deadlock when many small appends are done on jffs2 down to
this commit:

commit 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2
Author: Nick Piggin &lt;npiggin@suse.de&gt;
Date:   Sun May 6 14:49:04 2007 -0700

    mm: make read_cache_page synchronous

    Ensure pages are uptodate after returning from read_cache_page, which allows
    us to cut out most of the filesystem-internal PageUptodate calls.

    I didn't have a great look down the call chains, but this appears to fixes 7
    possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
    ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
    block2mtd.  All depending on whether the filler is async and/or can return
    with a !uptodate page.

It introduced a wait to read_cache_page, as well as a
read_cache_page_async function equivalent to the old read_cache_page
without any callers.

Switching jffs2_gc_fetch_page to read_cache_page_async for the old
behavior makes the deadlocks go away, but maybe reintroduces the
use-before-uptodate problem? I don't understand the mm/fs interaction
well enough to say.

[It's fine. dwmw2.]

Signed-off-by: Jason Lunz &lt;lunz@falooley.org&gt;
Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I've bisected the deadlock when many small appends are done on jffs2 down to
this commit:

commit 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2
Author: Nick Piggin &lt;npiggin@suse.de&gt;
Date:   Sun May 6 14:49:04 2007 -0700

    mm: make read_cache_page synchronous

    Ensure pages are uptodate after returning from read_cache_page, which allows
    us to cut out most of the filesystem-internal PageUptodate calls.

    I didn't have a great look down the call chains, but this appears to fixes 7
    possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
    ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
    block2mtd.  All depending on whether the filler is async and/or can return
    with a !uptodate page.

It introduced a wait to read_cache_page, as well as a
read_cache_page_async function equivalent to the old read_cache_page
without any callers.

Switching jffs2_gc_fetch_page to read_cache_page_async for the old
behavior makes the deadlocks go away, but maybe reintroduces the
use-before-uptodate problem? I don't understand the mm/fs interaction
well enough to say.

[It's fine. dwmw2.]

Signed-off-by: Jason Lunz &lt;lunz@falooley.org&gt;
Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>JFFS2 locking regression fix.</title>
<updated>2007-08-21T05:44:27+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw2@infradead.org</email>
</author>
<published>2007-08-20T10:05:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b5748643332bf75274e0b639926d57e86fb133cf'/>
<id>b5748643332bf75274e0b639926d57e86fb133cf</id>
<content type='text'>
Commit a491486a2087ac3dfc00efb4f838c8d684afaf54 introduced a locking
problem in JFFS2 -- we up() the alloc_sem when we weren't previously
holding it. This leads to all kinds of fun behaviour later.

There was a _reason_ for the
	if (1 /* alternative path needs testing */ ||
which the above-mentioned commit removed :)

Discovered and debugged by Giulio Fedel &lt;giulio.fedel@andorsystems.com&gt;

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit a491486a2087ac3dfc00efb4f838c8d684afaf54 introduced a locking
problem in JFFS2 -- we up() the alloc_sem when we weren't previously
holding it. This leads to all kinds of fun behaviour later.

There was a _reason_ for the
	if (1 /* alternative path needs testing */ ||
which the above-mentioned commit removed :)

Discovered and debugged by Giulio Fedel &lt;giulio.fedel@andorsystems.com&gt;

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] Print correct node offset when complaining about broken data CRC</title>
<updated>2007-08-02T20:43:46+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw2@infradead.org</email>
</author>
<published>2007-07-05T05:57:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b8e3ec30c232eb76c96ecab52205fe46e8b0473a'/>
<id>b8e3ec30c232eb76c96ecab52205fe46e8b0473a</id>
<content type='text'>
Debugging the hardware problems in OLPC trac #1905 would be a whole lot
easier if the correct node offsets were printed for the offending nodes.

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Debugging the hardware problems in OLPC trac #1905 would be a whole lot
easier if the correct node offsets were printed for the offending nodes.

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] Fix suspend failure with JFFS2 GC thread.</title>
<updated>2007-08-02T20:43:03+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw2@infradead.org</email>
</author>
<published>2007-06-28T18:49:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7b687707d769112aee220bafd50fa113363717ff'/>
<id>7b687707d769112aee220bafd50fa113363717ff</id>
<content type='text'>
The try_to_freeze() call was in the wrong place; we need it in the
signal-pending loop now that a pending freeze also makes
signal_pending() return true.

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The try_to_freeze() call was in the wrong place; we need it in the
signal-pending loop now that a pending freeze also makes
signal_pending() return true.

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] Deletion dirents should be REF_NORMAL, not REF_PRISTINE.</title>
<updated>2007-08-02T20:39:50+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw2@infradead.org</email>
</author>
<published>2007-06-29T12:39:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=71c23397752c0e40722d931ab9152342e9673336'/>
<id>71c23397752c0e40722d931ab9152342e9673336</id>
<content type='text'>
Otherwise they'll never actually get garbage-collected.
Noted by Jonathan Larmour.

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Otherwise they'll never actually get garbage-collected.
Noted by Jonathan Larmour.

Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] Prevent oops after 'node added in wrong place' debug check</title>
<updated>2007-08-02T20:36:35+00:00</updated>
<author>
<name>Joakim Tjernlund</name>
<email>Joakim.Tjernlund@transmode.se</email>
</author>
<published>2007-06-24T17:22:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5bd5c03c317085339deb044ba52fce131a6a0b67'/>
<id>5bd5c03c317085339deb044ba52fce131a6a0b67</id>
<content type='text'>
jffs2_add_physical_node_ref() should never really return error -- it's
an internal debugging check which triggered. We really need to work out
why and stop it happening. But in the meantime, let's make the failure
mode a little less nasty.

Signed-off-by: Joakim Tjernlund &lt;Joakim.Tjernlund@transmode.se&gt;
Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
jffs2_add_physical_node_ref() should never really return error -- it's
an internal debugging check which triggered. We really need to work out
why and stop it happening. But in the meantime, let's make the failure
mode a little less nasty.

Signed-off-by: Joakim Tjernlund &lt;Joakim.Tjernlund@transmode.se&gt;
Signed-off-by: David Woodhouse &lt;dwmw2@infradead.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mm: Remove slab destructors from kmem_cache_create().</title>
<updated>2007-07-20T01:11:58+00:00</updated>
<author>
<name>Paul Mundt</name>
<email>lethal@linux-sh.org</email>
</author>
<published>2007-07-20T01:11:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=20c2df83d25c6a95affe6157a4c9cac4cf5ffaac'/>
<id>20c2df83d25c6a95affe6157a4c9cac4cf5ffaac</id>
<content type='text'>
Slab destructors were no longer supported after Christoph's
c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
BUGs for both slab and slub, and slob never supported them
either.

This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).

Signed-off-by: Paul Mundt &lt;lethal@linux-sh.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Slab destructors were no longer supported after Christoph's
c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
BUGs for both slab and slub, and slob never supported them
either.

This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).

Signed-off-by: Paul Mundt &lt;lethal@linux-sh.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check</title>
<updated>2007-07-17T19:00:03+00:00</updated>
<author>
<name>Satyam Sharma</name>
<email>ssatyam@cse.iitk.ac.in</email>
</author>
<published>2007-07-17T09:30:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3bd858ab1c451725c07a805dcb315215dc85b86e'/>
<id>3bd858ab1c451725c07a805dcb315215dc85b86e</id>
<content type='text'>
Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
users to it. This is done because we want to avoid bugs in the future
where we check for only effective fsuid of the current task against a
file's owning uid, without simultaneously checking for CAP_FOWNER as
well, thus violating its semantics.
[ XFS uses special macros and structures, and in general looked ...
untouchable, so we leave it alone -- but it has been looked over. ]

The (current-&gt;fsuid != inode-&gt;i_uid) check in generic_permission() and
exec_permission_lite() is left alone, because those operations are
covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.

Signed-off-by: Satyam Sharma &lt;ssatyam@cse.iitk.ac.in&gt;
Cc: Al Viro &lt;viro@ftp.linux.org.uk&gt;
Acked-by: Serge E. Hallyn &lt;serge@hallyn.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
users to it. This is done because we want to avoid bugs in the future
where we check for only effective fsuid of the current task against a
file's owning uid, without simultaneously checking for CAP_FOWNER as
well, thus violating its semantics.
[ XFS uses special macros and structures, and in general looked ...
untouchable, so we leave it alone -- but it has been looked over. ]

The (current-&gt;fsuid != inode-&gt;i_uid) check in generic_permission() and
exec_permission_lite() is left alone, because those operations are
covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.

Signed-off-by: Satyam Sharma &lt;ssatyam@cse.iitk.ac.in&gt;
Cc: Al Viro &lt;viro@ftp.linux.org.uk&gt;
Acked-by: Serge E. Hallyn &lt;serge@hallyn.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Freezer: make kernel threads nonfreezable by default</title>
<updated>2007-07-17T17:23:02+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rjw@sisk.pl</email>
</author>
<published>2007-07-17T11:03:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=831441862956fffa17b9801db37e6ea1650b0f69'/>
<id>831441862956fffa17b9801db37e6ea1650b0f69</id>
<content type='text'>
Currently, the freezer treats all tasks as freezable, except for the kernel
threads that explicitly set the PF_NOFREEZE flag for themselves.  This
approach is problematic, since it requires every kernel thread to either
set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
care for the freezing of tasks at all.

It seems better to only require the kernel threads that want to or need to
be frozen to use some freezer-related code and to remove any
freezer-related code from the other (nonfreezable) kernel threads, which is
done in this patch.

The patch causes all kernel threads to be nonfreezable by default (ie.  to
have PF_NOFREEZE set by default) and introduces the set_freezable()
function that should be called by the freezable kernel threads in order to
unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
threads call set_freezable(), so it shouldn't cause any (intentional)
change of behaviour to appear.  Additionally, it updates documentation to
describe the freezing of tasks more accurately.

[akpm@linux-foundation.org: build fixes]
Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Acked-by: Nigel Cunningham &lt;nigel@nigel.suspend2.net&gt;
Cc: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Oleg Nesterov &lt;oleg@tv-sign.ru&gt;
Cc: Gautham R Shenoy &lt;ego@in.ibm.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, the freezer treats all tasks as freezable, except for the kernel
threads that explicitly set the PF_NOFREEZE flag for themselves.  This
approach is problematic, since it requires every kernel thread to either
set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
care for the freezing of tasks at all.

It seems better to only require the kernel threads that want to or need to
be frozen to use some freezer-related code and to remove any
freezer-related code from the other (nonfreezable) kernel threads, which is
done in this patch.

The patch causes all kernel threads to be nonfreezable by default (ie.  to
have PF_NOFREEZE set by default) and introduces the set_freezable()
function that should be called by the freezable kernel threads in order to
unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
threads call set_freezable(), so it shouldn't cause any (intentional)
change of behaviour to appear.  Additionally, it updates documentation to
describe the freezing of tasks more accurately.

[akpm@linux-foundation.org: build fixes]
Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Acked-by: Nigel Cunningham &lt;nigel@nigel.suspend2.net&gt;
Cc: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Oleg Nesterov &lt;oleg@tv-sign.ru&gt;
Cc: Gautham R Shenoy &lt;ego@in.ibm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sendfile: remove .sendfile from filesystems that use generic_file_sendfile()</title>
<updated>2007-07-10T06:04:13+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>jens.axboe@oracle.com</email>
</author>
<published>2007-06-01T09:49:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5ffc4ef45b3b0a57872f631b4e4ceb8ace0d7496'/>
<id>5ffc4ef45b3b0a57872f631b4e4ceb8ace0d7496</id>
<content type='text'>
They can use generic_file_splice_read() instead. Since sys_sendfile() now
prefers that, there should be no change in behaviour.

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
They can use generic_file_splice_read() instead. Since sys_sendfile() now
prefers that, there should be no change in behaviour.

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
