JFFS2/xattr problems.

[KaiGai Kohei]

Hello, David.

David Woodhouse wrote:
> I created a user xattr on JFFS2, then attempted to remove it. On NAND
> flash I get the following BUG():
> 
> jffs2_flash_writev(): Non-contiguous write to 004ca000
> wbuf was previously 004ca000-004ca040
> ------------[ cut here ]------------
> kernel BUG at /root/jffs2/wbuf.c:672!
> 
> Call Trace:
>  [<c8222aad>] jffs2_flash_writev+0x616/0x6ac [jffs2]
>  [<c823eadb>] nand_read_ecc+0x29/0x2f [nand]     [<c823eadb>] nand_read_ecc+0x29/0x2f [nand]
>  [<c8221a6a>] jffs2_flash_read+0x8a/0x22b [jffs2]     [<c8222b8b>] jffs2_flash_write+0x48/0x51 [jffs2]
>  [<c822364d>] delete_xattr_datum_node+0xcc/0x144 [jffs2]     [<c8223dea>] delete_xattr_datum+0x2c/0x3c [jffs2]
>  [<c8223ed2>] delete_xattr_ref+0x32/0x3b [jffs2]     [<c8224e37>] do_jffs2_setxattr+0x1a9/0x5aa [jffs2]
>  [<c01c1462>] _atomic_dec_and_lock+0x22/0x2c     [<c82254fc>] jffs2_user_setxattr+0x3c/0x47 [jffs2]
>  [<c016e9e8>] generic_removexattr+0x37/0x3d     [<c016ef78>] vfs_removexattr+0x78/0xc8
> 
> What is delete_xattr_datum_node() trying to do? It seems to be writing
> for a second time to an area of flash which has _already_ been written.
> You can't do that.

delete_xattr_datum_node() try to write invalid data to ensure the target
node was already deleted. I was worried about that a xdatum already removed
may be reused as a effective xdatum on next mounting.
But it's purely design problem that should be changed.

Alternatively, I plan to write a delete marker on new node allocated by
jffs2_reserve_space() when xdatum is removed.
I intend to be dealt with a xdatum with 0xffffffff of version number
as a delete marker for xdatum. This node will be ignored on next mounting.

There is a same issue on deletion of xattr_ref, I also plan to implement
with same method.

Some days will be necessary to change it.
Would you wait for a while?

> Also, just 'cp -av /lib/libc.so.6 /mnt/jffs2' is failing to set the
> POSIX ACL, with -EINVAL. This happens because posix_acl_equiv_mode()
> returns zero, because the ACL is entirely equivalent to normal modes. So
> the 'value' passed to do_jffs2_setxattr() is NULL, which should _delete_
> the corresponding xattr.
> 
> But because the xattr is not found, the code returns -EINVAL. Shouldn't
> that error be -ENOATTR? And shouldn't the ACL code then convert it to a
> more appropriate return value?

I agree, I'll fix it.

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>