1. 23 Jun, 2006 1 commit
  2. 22 May, 2006 2 commits
  3. 18 May, 2006 1 commit
    • David Woodhouse's avatar
      [JFFS2] Support new device nodes · aef9ab47
      David Woodhouse authored
      
      
      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: default avatarDavid Woodhouse <dwmw2@infradead.org>
      aef9ab47
  4. 13 May, 2006 1 commit
    • KaiGai Kohei's avatar
      [JFFS2][XATTR] XATTR support on JFFS2 (version. 5) · aa98d7cf
      KaiGai Kohei authored
      
      
      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: default avatarKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      aa98d7cf
  5. 05 May, 2006 1 commit
  6. 12 Jan, 2006 1 commit
  7. 29 Nov, 2005 1 commit
    • Thomas Gleixner's avatar
      [JFFS2] Fix the slab cache constructor of 'struct jffs2_inode_info' objects. · 21eeb7aa
      Thomas Gleixner authored
      
      
      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: default avatarArtem B. Bityutskiy <dedekind@infradead.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      21eeb7aa
  8. 07 Nov, 2005 1 commit
  9. 06 Nov, 2005 9 commits
  10. 06 Jul, 2005 1 commit
  11. 23 May, 2005 2 commits
  12. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!
      1da177e4