<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/jffs2, branch v2.6.29</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[JFFS2] fix mount crash caused by removed nodes</title>
<updated>2009-02-21T10:09:29+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2009-02-16T20:29:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4c41bd0ec953954158f92bed5d3062645062b98e'/>
<id>4c41bd0ec953954158f92bed5d3062645062b98e</id>
<content type='text'>
At scan time we observed following scenario:

   node A inserted
   node B inserted
   node C inserted -&gt; sets overlapped flag on node B

   node A is removed due to CRC failure -&gt; overlapped flag on node B remains

   while (tn-&gt;overlapped)
   	 tn = tn_prev(tn);

   ==&gt; crash, when tn_prev(B) is referenced.

When the ultimate node is removed at scan time and the overlapped flag
is set on the penultimate node, then nothing updates the overlapped
flag of that node. The overlapped iterators blindly expect that the
ultimate node does not have the overlapped flag set, which causes the
scan code to crash.

It would be a huge overhead to go through the node chain on node
removal and fix up the overlapped flags, so detecting such a case on
the fly in the overlapped iterators is a simpler and reliable
solution.

Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
At scan time we observed following scenario:

   node A inserted
   node B inserted
   node C inserted -&gt; sets overlapped flag on node B

   node A is removed due to CRC failure -&gt; overlapped flag on node B remains

   while (tn-&gt;overlapped)
   	 tn = tn_prev(tn);

   ==&gt; crash, when tn_prev(B) is referenced.

When the ultimate node is removed at scan time and the overlapped flag
is set on the penultimate node, then nothing updates the overlapped
flag of that node. The overlapped iterators blindly expect that the
ultimate node does not have the overlapped flag set, which causes the
scan code to crash.

It would be a huge overhead to go through the node chain on node
removal and fix up the overlapped flags, so detecting such a case on
the fly in the overlapped iterators is a simpler and reliable
solution.

Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] force the jffs2 GC daemon to behave a bit better</title>
<updated>2009-02-14T08:59:04+00:00</updated>
<author>
<name>Andres Salomon</name>
<email>dilinger@queued.net</email>
</author>
<published>2009-02-11T21:27:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=efab0b5d3eed6aa71f8e3233e4e11774eedc04dc'/>
<id>efab0b5d3eed6aa71f8e3233e4e11774eedc04dc</id>
<content type='text'>
I've noticed some pretty poor behavior on OLPC machines after bootup, when
gdm/X are starting.  The GCD monopolizes the scheduler (which in turns
means it gets to do more nand i/o), which results in processes taking much
much longer than they should to start.

As an example, on an OLPC machine going from OFW to a usable X (via
auto-login gdm) takes 2m 30s.  The majority of this time is consumed by
the switch into graphical mode.  With this patch, we cut a full 60s off of
bootup time.  After bootup, things are much snappier as well.

Note that we have seen a CRC node error with this patch that causes the machine
to fail to boot, but we've also seen that problem without this patch.

Signed-off-by: Andres Salomon &lt;dilinger@debian.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I've noticed some pretty poor behavior on OLPC machines after bootup, when
gdm/X are starting.  The GCD monopolizes the scheduler (which in turns
means it gets to do more nand i/o), which results in processes taking much
much longer than they should to start.

As an example, on an OLPC machine going from OFW to a usable X (via
auto-login gdm) takes 2m 30s.  The majority of this time is consumed by
the switch into graphical mode.  With this patch, we cut a full 60s off of
bootup time.  After bootup, things are much snappier as well.

Note that we have seen a CRC node error with this patch that causes the machine
to fail to boot, but we've also seen that problem without this patch.

Signed-off-by: Andres Salomon &lt;dilinger@debian.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] remove junk prototypes</title>
<updated>2009-01-09T21:05:21+00:00</updated>
<author>
<name>Artem Bityutskiy</name>
<email>Artem.Bityutskiy@nokia.com</email>
</author>
<published>2009-01-08T17:38:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ab5610b434645518aca6e4de5ad851f9fef006f3'/>
<id>ab5610b434645518aca6e4de5ad851f9fef006f3</id>
<content type='text'>
'rb_prev()', 'rb_next()' and 'rb_replace_node()' are declared in
include/linux/rbtree.h, no need for JFFS2 to re-declare them. I
believe these are left-overs from the old days when the common
RB tree code did not have those call and JFFS2 had private
implementation.

Signed-off-by: Artem Bityutskiy &lt;Artem.Bityutskiy@nokia.com&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'rb_prev()', 'rb_next()' and 'rb_replace_node()' are declared in
include/linux/rbtree.h, no need for JFFS2 to re-declare them. I
believe these are left-overs from the old days when the common
RB tree code did not have those call and JFFS2 had private
implementation.

Signed-off-by: Artem Bityutskiy &lt;Artem.Bityutskiy@nokia.com&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6</title>
<updated>2009-01-05T09:50:33+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>David.Woodhouse@intel.com</email>
</author>
<published>2009-01-05T09:50:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=353816f43d1fb340ff2d9a911dd5d0799c09f6a5'/>
<id>353816f43d1fb340ff2d9a911dd5d0799c09f6a5</id>
<content type='text'>
Conflicts:
	arch/arm/mach-pxa/corgi.c
	arch/arm/mach-pxa/poodle.c
	arch/arm/mach-pxa/spitz.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	arch/arm/mach-pxa/corgi.c
	arch/arm/mach-pxa/poodle.c
	arch/arm/mach-pxa/spitz.c
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: symlink write_begin allocation context fix</title>
<updated>2009-01-04T21:33:20+00:00</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@suse.de</email>
</author>
<published>2009-01-04T20:00:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=54566b2c1594c2326a645a3551f9d989f7ba3c5e'/>
<id>54566b2c1594c2326a645a3551f9d989f7ba3c5e</id>
<content type='text'>
With the write_begin/write_end aops, page_symlink was broken because it
could no longer pass a GFP_NOFS type mask into the point where the
allocations happened.  They are done in write_begin, which would always
assume that the filesystem can be entered from reclaim.  This bug could
cause filesystem deadlocks.

The funny thing with having a gfp_t mask there is that it doesn't really
allow the caller to arbitrarily tinker with the context in which it can be
called.  It couldn't ever be GFP_ATOMIC, for example, because it needs to
take the page lock.  The only thing any callers care about is __GFP_FS
anyway, so turn that into a single flag.

Add a new flag for write_begin, AOP_FLAG_NOFS.  Filesystems can now act on
this flag in their write_begin function.  Change __grab_cache_page to
accept a nofs argument as well, to honour that flag (while we're there,
change the name to grab_cache_page_write_begin which is more instructive
and does away with random leading underscores).

This is really a more flexible way to go in the end anyway -- if a
filesystem happens to want any extra allocations aside from the pagecache
ones in ints write_begin function, it may now use GFP_KERNEL (rather than
GFP_NOFS) for common case allocations (eg.  ocfs2_alloc_write_ctxt, for a
random example).

[kosaki.motohiro@jp.fujitsu.com: fix ubifs]
[kosaki.motohiro@jp.fujitsu.com: fix fuse]
Signed-off-by: Nick Piggin &lt;npiggin@suse.de&gt;
Reviewed-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Cc: &lt;stable@kernel.org&gt;		[2.6.28.x]
Signed-off-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
[ Cleaned up the calling convention: just pass in the AOP flags
  untouched to the grab_cache_page_write_begin() function.  That
  just simplifies everybody, and may even allow future expansion of the
  logic.   - Linus ]
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With the write_begin/write_end aops, page_symlink was broken because it
could no longer pass a GFP_NOFS type mask into the point where the
allocations happened.  They are done in write_begin, which would always
assume that the filesystem can be entered from reclaim.  This bug could
cause filesystem deadlocks.

The funny thing with having a gfp_t mask there is that it doesn't really
allow the caller to arbitrarily tinker with the context in which it can be
called.  It couldn't ever be GFP_ATOMIC, for example, because it needs to
take the page lock.  The only thing any callers care about is __GFP_FS
anyway, so turn that into a single flag.

Add a new flag for write_begin, AOP_FLAG_NOFS.  Filesystems can now act on
this flag in their write_begin function.  Change __grab_cache_page to
accept a nofs argument as well, to honour that flag (while we're there,
change the name to grab_cache_page_write_begin which is more instructive
and does away with random leading underscores).

This is really a more flexible way to go in the end anyway -- if a
filesystem happens to want any extra allocations aside from the pagecache
ones in ints write_begin function, it may now use GFP_KERNEL (rather than
GFP_NOFS) for common case allocations (eg.  ocfs2_alloc_write_ctxt, for a
random example).

[kosaki.motohiro@jp.fujitsu.com: fix ubifs]
[kosaki.motohiro@jp.fujitsu.com: fix fuse]
Signed-off-by: Nick Piggin &lt;npiggin@suse.de&gt;
Reviewed-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Cc: &lt;stable@kernel.org&gt;		[2.6.28.x]
Signed-off-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
[ Cleaned up the calling convention: just pass in the AOP flags
  untouched to the grab_cache_page_write_begin() function.  That
  just simplifies everybody, and may even allow future expansion of the
  logic.   - Linus ]
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] Clean up fs/jffs2/compr_rubin.c</title>
<updated>2008-12-10T15:34:49+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>David.Woodhouse@intel.com</email>
</author>
<published>2008-12-10T15:34:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0bc4382ae901311fe53be5735026cbe3ea6f235f'/>
<id>0bc4382ae901311fe53be5735026cbe3ea6f235f</id>
<content type='text'>
Triggered by a smaller cleanup from Jianjun Kong &lt;jianjun@zeuux.org&gt;

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Triggered by a smaller cleanup from Jianjun Kong &lt;jianjun@zeuux.org&gt;

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[MTD] update internal API to support 64-bit device size</title>
<updated>2008-12-10T13:37:21+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>ext-adrian.hunter@nokia.com</email>
</author>
<published>2008-12-10T13:37:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=69423d99fc182a81f3c5db3eb5c140acc6fc64be'/>
<id>69423d99fc182a81f3c5db3eb5c140acc6fc64be</id>
<content type='text'>
MTD internal API presently uses 32-bit values to represent
device size.  This patch updates them to 64-bits but leaves
the external API unchanged.  Extending the external API
is a separate issue for several reasons.  First, no one
needs it at the moment.  Secondly, whether the implementation
is done with IOCTLs, sysfs or both is still debated.  Thirdly
external API changes require the internal API to be accepted
first.

Note that although the MTD API will be able to support 64-bit
device sizes, existing drivers do not and are not required
to do so, although NAND base has been updated.

In general, changing from 32-bit to 64-bit values cause little
or no changes to the majority of the code with the following
exceptions:
    	- printk message formats
    	- division and modulus of 64-bit values
    	- NAND base support
	- 32-bit local variables used by mtdpart and mtdconcat
	- naughtily assuming one structure maps to another
	in MEMERASE ioctl

Signed-off-by: Adrian Hunter &lt;ext-adrian.hunter@nokia.com&gt;
Signed-off-by: Artem Bityutskiy &lt;Artem.Bityutskiy@nokia.com&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MTD internal API presently uses 32-bit values to represent
device size.  This patch updates them to 64-bits but leaves
the external API unchanged.  Extending the external API
is a separate issue for several reasons.  First, no one
needs it at the moment.  Secondly, whether the implementation
is done with IOCTLs, sysfs or both is still debated.  Thirdly
external API changes require the internal API to be accepted
first.

Note that although the MTD API will be able to support 64-bit
device sizes, existing drivers do not and are not required
to do so, although NAND base has been updated.

In general, changing from 32-bit to 64-bit values cause little
or no changes to the majority of the code with the following
exceptions:
    	- printk message formats
    	- division and modulus of 64-bit values
    	- NAND base support
	- 32-bit local variables used by mtdpart and mtdconcat
	- naughtily assuming one structure maps to another
	in MEMERASE ioctl

Signed-off-by: Adrian Hunter &lt;ext-adrian.hunter@nokia.com&gt;
Signed-off-by: Artem Bityutskiy &lt;Artem.Bityutskiy@nokia.com&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.infradead.org/mtd-2.6</title>
<updated>2008-11-06T23:43:13+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-11-06T23:43:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c36194871293100bd4b2ecb54ac9774d6e627aa2'/>
<id>c36194871293100bd4b2ecb54ac9774d6e627aa2</id>
<content type='text'>
* git://git.infradead.org/mtd-2.6:
  [JFFS2] fix race condition in jffs2_lzo_compress()
  [MTD] [NOR] Fix cfi_send_gen_cmd handling of x16 devices in x8 mode (v4)
  [JFFS2] Fix lack of locking in thread_should_wake()
  [JFFS2] Fix build failure with !CONFIG_JFFS2_FS_WRITEBUFFER
  [MTD] [NAND] OMAP2: remove duplicated #include
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* git://git.infradead.org/mtd-2.6:
  [JFFS2] fix race condition in jffs2_lzo_compress()
  [MTD] [NOR] Fix cfi_send_gen_cmd handling of x16 devices in x8 mode (v4)
  [JFFS2] Fix lack of locking in thread_should_wake()
  [JFFS2] Fix build failure with !CONFIG_JFFS2_FS_WRITEBUFFER
  [MTD] [NAND] OMAP2: remove duplicated #include
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] fix race condition in jffs2_lzo_compress()</title>
<updated>2008-11-05T22:22:02+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>Geert.Uytterhoeven@sonycom.com</email>
</author>
<published>2008-11-05T22:21:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dc8a0843a435b2c0891e7eaea64faaf1ebec9b11'/>
<id>dc8a0843a435b2c0891e7eaea64faaf1ebec9b11</id>
<content type='text'>
deflate_mutex protects the globals lzo_mem and lzo_compress_buf.  However,
jffs2_lzo_compress() unlocks deflate_mutex _before_ it has copied out the
compressed data from lzo_compress_buf.  Correct this by moving the mutex
unlock after the copy.

In addition, document what deflate_mutex actually protects.

Cc: stable@kernel.org
Signed-off-by: Geert Uytterhoeven &lt;Geert.Uytterhoeven@sonycom.com&gt;
Acked-by: Richard Purdie &lt;rpurdie@openedhand.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
deflate_mutex protects the globals lzo_mem and lzo_compress_buf.  However,
jffs2_lzo_compress() unlocks deflate_mutex _before_ it has copied out the
compressed data from lzo_compress_buf.  Correct this by moving the mutex
unlock after the copy.

In addition, document what deflate_mutex actually protects.

Cc: stable@kernel.org
Signed-off-by: Geert Uytterhoeven &lt;Geert.Uytterhoeven@sonycom.com&gt;
Acked-by: Richard Purdie &lt;rpurdie@openedhand.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[JFFS2] Fix lack of locking in thread_should_wake()</title>
<updated>2008-10-31T14:52:24+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>David.Woodhouse@intel.com</email>
</author>
<published>2008-10-31T14:52:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b27cf88e9592953ae292d05324887f2f44979433'/>
<id>b27cf88e9592953ae292d05324887f2f44979433</id>
<content type='text'>
The thread_should_wake() function trawls through the list of 'very
dirty' eraseblocks, determining whether the background GC thread should
wake. Doing this without holding the appropriate locks is a bad idea.

OLPC Trac #8615

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Cc: stable@kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The thread_should_wake() function trawls through the list of 'very
dirty' eraseblocks, determining whether the background GC thread should
wake. Doing this without holding the appropriate locks is a bad idea.

OLPC Trac #8615

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Cc: stable@kernel.org
</pre>
</div>
</content>
</entry>
</feed>
