This attached patches provide xattr support including POSIX-ACL and
SELinux support on JFFS2 (version.5).

There are some significant differences from previous version posted
at last December.
The biggest change is addition of EBS(Erase Block Summary) support.
Currently, both kernel and usermode utility (sumtool) can recognize
xattr nodes which have JFFS2_NODETYPE_XATTR/_XREF nodetype.

In addition, some bugs are fixed.
- A potential race condition was fixed.
- Unexpected fail when updating a xattr by same name/value pair was fixed.
- A bug when removing xattr name/value pair was fixed.

The fundamental structures (such as using two new nodetypes and exclusion
mechanism by rwsem) are unchanged. But most of implementation were reviewed
and updated if necessary.
Espacially, we had to change several internal implementations related to
load_xattr_datum() to avoid a potential race condition.

[1/2] xattr_on_jffs2.kernel.version-5.patch
[2/2] xattr_on_jffs2.utils.version-5.patch
Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

It seems like there is a potential race in the function jffs2_do_setattr()
in the case when attributes of a symlink are updated. The symlink metadata
is read without having f->sem locked.

The following patch should fix the race.
Signed-off-by: NDmitry Bazhenov <atrey@emcraft.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

fs: Use <linux/capability.h> where capable() is used.
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

JFFS2 initialize f->sem mutex as "locked" in the slab constructor which is a
bug. Objects are freed with unlocked f->sem mutex. So, when they allocated
again, f->sem is unlocked because the slab cache constructor is not called for
them. The constructor is called only once when memory pages are allocated for
objects (namely, when the slab layer allocates new slabs). So, sometimes
'struct jffs2_inode_info' are allocated with unlocked f->sem, sometimes with
locked. This is a bug. Instead, initialize f->sem as unlocked in the
constructor. I.e., in the "constructed" state f->sem must be unlocked.

From: Keijiro Yano <keijiro_yano@yahoo.co.jp>
Acked-by: NArtem B. Bityutskiy <dedekind@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NArtem B. Bityutskiy <dedekind@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

The goal of summary is to speed up the mount time. Erase block summary (EBS)
stores summary information at the end of every (closed) erase block. It is
no longer necessary to scan all nodes separetly (and read all pages of them)
just read this "small" summary, where every information is stored which is
needed at mount time.

This summary information is stored in a JFFS2_FEATURE_RWCOMPAT_DELETE. During
the mount process if there is no summary info the orignal scan process will
be executed. EBS works with NAND and NOR flashes, too.

There is a user space tool called sumtool to generate this summary
information for a JFFS2 image.
Signed-off-by: NFerenc Havasi <havasi@inf.u-szeged.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Remove support for virtual blocks, which are build by
concatenation of multiple physical erase blocks.

For more information please read the MTD mailing list thread
"[PATCH] remove support for virtual blocks"
Signed-off-by: NFerenc Havasi <havasi@inf.u-szeged.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Intels Sibley flash needs JFFS2 write buffer functionality
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Rename functions to a name matching the functionality.
Remove stall debug code
Signed-off-by: NArtem B. Bityutskiy <dedekind@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Various simplifiactions. printk format corrections.
Convert more code to use the new debug functions.
Signed-off-by: NArtem B. Bityutskiy <dedekind@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

When JFFS22 is unable to read the root inode, the bad root inode object is not
freed and remains sticked in the jffs2_i slab cache. When we further try to
free the slab cache (e.g., on rmmod jffs2), slab allocator subsystem panics.
Fix this bug.
Signed-off-by: NArtem B. Bityutskiy <dedekind@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

If debugging is disabled, define debugging functions as empty macros, instead
of using Dx() explicitly.
Signed-off-by: NArtem B. Bityutskiy <dedekind@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Move debug functions into a seperate source file
Signed-off-by: NArtem B. Bityutskiy <dedekind@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

This patch replaces the current CONFIG_JFFS2_FS_NAND, CONFIG_JFFS2_FS_NOR_ECC
and CONFIG_JFFS2_FS_DATAFLASH with a single configuration option -
CONFIG_JFFS2_FS_WRITEBUFFER.

The only functional change of this patch is that the slower div/mod
calculations for SECTOR_ADDR(), PAGE_DIV() and PAGE_MOD() are now always
used when CONFIG_JFFS2_FS_WRITEBUFFER is enabled.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

For Dataflash, can_mark_obsolete = false and the NAND write buffering
code (wbuf.c) is used.

Since the DataFlash chip will automatically erase pages when writing,
the cleanmarkers are not needed - so cleanmarker_oob = false and
cleanmarker_size = 0

DataFlash page-sizes are not a power of two (they're multiples of 528
bytes).  The SECTOR_ADDR macro (added in the previous core patch) is
replaced with a (slower) div/mod version if CONFIG_JFFS2_FS_DATAFLASH is
selected.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!