25 Oct, 2010

1 commit


08 Aug, 2010

1 commit


20 May, 2010

1 commit


19 May, 2010

1 commit

  • jffs2_garbage_collect_pass() would previously return -EAGAIN if it
    couldn't find anything to garbage collect from, and there were blocks on
    the erase_pending_list. If the blocks were actually in the process of
    being erased, though, then they wouldn't be on that list. Check for
    nr_erasing_blocks being non-zero instead.

    Fix jffs2_reserve_space() to wait for the in-progress erases to
    complete, when jffs2_garbage_collect_pass() returns -EAGAIN.

    And fix jffs2_erase_succeeded() to actually wake up the erase_wait wq
    that jffs2_reserve_space() is now using.

    Signed-off-by: David Woodhouse

    David Woodhouse
     

16 Dec, 2009

1 commit

  • Ever since jffs2_garbage_collect_metadata() was first half-written in
    February 2001, it's been broken on architectures where 'char' is signed.
    When garbage collecting a symlink with target length above 127, the payload
    length would end up negative, causing interesting and bad things to happen.

    Cc: stable@kernel.org
    Signed-off-by: David Woodhouse

    David Woodhouse
     

02 May, 2008

2 commits


23 Apr, 2008

1 commit

  • When _all_ the blocks were on the erase_pending_list, we could't find a
    block to GC from but there was no _actually_ free space, and
    jffs2_reserve_space() would get a little unhappy.

    Handle this case by returning -EAGAIN from jffs2_garbage_collect_pass().
    There are two callers of that function -- jffs2_flush_wbuf_gc(), which
    will interpret it as an error and flush the writebuffer by other means,
    and jffs2_reserve_space(), which we modify to respond to -EAGAIN with an
    immediate call to jffs2_erase_pending_blocks() and another run round the
    loop.

    Signed-off-by: David Woodhouse

    David Woodhouse
     

22 Apr, 2008

2 commits


13 Oct, 2007

3 commits


10 Jul, 2007

1 commit


25 Apr, 2007

1 commit

  • In particular, remove the bit in the LICENCE file about contacting
    Red Hat for alternative arrangements. Their errant IS department broke
    that arrangement a long time ago -- the policy of collecting copyright
    assignments from contributors came to an end when the plug was pulled on
    the servers hosting the project, without notice or reason.

    We do still dual-license it for use with eCos, with the GPL+exception
    licence approved by the FSF as being GPL-compatible. It's just that nobody
    has the right to license it differently.

    Signed-off-by: David Woodhouse

    David Woodhouse
     

23 Apr, 2007

1 commit


19 Dec, 2006

1 commit


27 Jun, 2006

2 commits

  • If xattr_ref is associated with an orphan inode_cache
    on filesystem mounting, those xattr_refs are not
    released even if this inode_cache is released.

    This patch enables to call jffs2_xattr_delete_inode()
    for such a irregular inode_cachde too.

    Signed-off-by: KaiGai Kohei
    Signed-off-by: David Woodhouse

    KaiGai Kohei
     
  • - When xdatum is removed, a new xdatum with 'delete marker' is
    written. (version==0xffffffff means 'delete marker')
    - When xref is removed, a new xref with 'delete marker' is written.
    (odd-numbered xseqno means 'delete marker')

    - delete_xattr_(datum/xref)_delay() are new deletion functions
    are added. We can only use them if we can detect the target
    obsolete xdatum/xref as a orphan or errir one.
    (e.g when inode deletion, or detecting crc error)

    [1/3] jffs2-xattr-v6-01-delete_marker.patch

    Signed-off-by: KaiGai Kohei
    Signed-off-by: David Woodhouse

    KaiGai Kohei
     

24 May, 2006

2 commits


23 May, 2006

1 commit


22 May, 2006

1 commit


21 May, 2006

3 commits


19 May, 2006

1 commit

  • Device node major/minor numbers are just stored in the payload of a single
    data node. Just extend that to 4 bytes and use new_encode_dev() for it.

    We only use the 4-byte format if we _need_ to, if !old_valid_dev(foo).
    This preserves backwards compatibility with older code as much as
    possible. If we do make devices with major or minor numbers above 255, and
    then mount the file system with the old code, it'll just read the first
    two bytes and get the numbers wrong. If it comes to garbage-collect it,
    it'll then write back those wrong numbers. But that's about the best we
    can expect.

    Signed-off-by: David Woodhouse

    David Woodhouse
     

13 May, 2006

2 commits

  • Remove jffs2_garbage_collect_xattr(c, ic).
    jffs2_garbage_collect_xattr_datum/ref() are called from gc.c directly.

    In original implementation, jffs2_garbage_collect_xattr(c, ic) returns
    with holding a spinlock if 'ic' is inode_cache. But it returns after
    releasing a spinlock if 'ic' is xattr_datum/ref.
    It looks so confusable behavior. Thus, this patch makes caller manage
    locking/unlocking.

    [5/10] jffs2-xattr-v5.1-05-update_xattr_gc.patch

    Signed-off-by: KaiGai Kohei

    KaiGai Kohei
     
  • 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: KaiGai Kohei
    Signed-off-by: David Woodhouse

    KaiGai Kohei
     

17 Apr, 2006

1 commit

  • For a while now, we've postponed CRC-checking of data nodes to be done
    by the GC thread, instead of being done while the user is waiting for
    mount to finish. The GC thread would iterate through all the inodes on
    the system and check each of their data nodes. It would skip over inodes
    which had already been used or were already being read in by
    read_inode(), because their data nodes would have been examined anyway.

    However, we could sometimes reach the end of the for-each-inode loop and
    still have some unchecked space left, if an inode we'd skipped was
    _still_ in the process of being read. This fixes that race by actually
    waiting for read_inode() to finish rather than just moving on.

    Thanks to Ladislav Michl for coming up with a reproducible test case and
    helping to track it down.

    Signed-off-by: David Woodhouse

    David Woodhouse
     

07 Nov, 2005

4 commits


06 Nov, 2005

2 commits


23 May, 2005

4 commits