1. 17 5月, 2012 1 次提交
  2. 03 5月, 2012 1 次提交
  3. 13 1月, 2012 1 次提交
    • A
      UBIFS: fix key printing · 515315a1
      Artem Bityutskiy 提交于
      Before commit 56e46742 we have had locking
      around all printing macros and we could use static buffers for creating
      key strings and printing them. However, now we do not have that locking and
      we cannot use static buffers. This commit removes the old DBGKEY() macros
      and introduces few new helper macros for printing debugging messages plus
      a key at the end. Thankfully, all the messages are already structures in
      a way that the key is printed in the end.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      515315a1
  4. 03 6月, 2011 1 次提交
  5. 16 5月, 2011 1 次提交
    • A
      UBIFS: synchronize write-buffer before switching to the next bud · cb14a184
      Artem Bityutskiy 提交于
      Currently when UBIFS fills up the current bud (which is the last in the journal
      head) and switches to the next bud, it first writes the log reference node for
      the next bud and only after this synchronizes the write-buffer of the previous
      bud. This is not a big deal, but an unclean power cut may lead to a situation
      when we have corruption in a next-to-last bud, although it is much more logical
      that we have to have corruption only in the last bud.
      
      This patch also removes write-buffer synchronization from
      'ubifs_wbuf_seek_nolock()' because this is not needed anymore (we synchronize
      the write-buffer explicitly everywhere now) and also because this is just
      prone to various errors.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      cb14a184
  6. 14 5月, 2011 2 次提交
    • A
      UBIFS: improve space checking debugging feature · f1bd66af
      Artem Bityutskiy 提交于
      This patch improves the 'dbg_check_space_info()' function which checks
      whether the amount of space before re-mounting and after re-mounting
      is the same (remounting from R/O to R/W modes and vice-versa).
      
      The problem is that 'dbg_check_space_info()' does not save the budgeting
      information before re-mounting, so when an error is reported, we do not
      know why the amount of free space changed.
      
      This patches makes the following changes:
      
      1. Teaches 'dbg_dump_budg()' function to accept a 'struct ubifs_budg_info'
         argument and print out the this argument. This way we may ask it to
         print any saved budgeting info, no only the current one.
      2. Accordingly changes all the callers of 'dbg_dump_budg()' to comply with
         the changed interface.
      3. Introduce a 'saved_bi' (saved budgeting info) field to
         'struct ubifs_debug_info' and save the budgeting info before re-mounting
         there.
      4. Change 'dbg_check_space_info()' and make it print both old and new
         budgeting information.
      5. Additionally, save 'c->igx_gc_cnt' and print it if and error happens. This
         value contributes to the amount of free space, so we have to print it.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      f1bd66af
    • A
      UBIFS: simplify dbg_dump_budg calling conventions · 8ff83089
      Artem Bityutskiy 提交于
      The current 'dbg_dump_budg()' calling convention is that the
      'c->space_lock' spinlock is held. However, none of the callers
      actually use it from contects which have 'c->space_lock' locked,
      so all callers have to explicitely lock and unlock the spinlock.
      This is not very sensible convention. This patch changes it and
      makes 'dbg_dump_budg()' lock the spinlock instead of imposing this
      to the callers. This simplifies the code a little.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      8ff83089
  7. 11 3月, 2011 1 次提交
    • M
      UBIFS: handle allocation failures in UBIFS write path · d882962f
      Matthew L. Creech 提交于
      Running kernel 2.6.37, my PPC-based device occasionally gets an
      order-2 allocation failure in UBIFS, which causes the root FS to
      become unwritable:
      
      kswapd0: page allocation failure. order:2, mode:0x4050
      Call Trace:
      [c787dc30] [c00085b8] show_stack+0x7c/0x194 (unreliable)
      [c787dc70] [c0061aec] __alloc_pages_nodemask+0x4f0/0x57c
      [c787dd00] [c0061b98] __get_free_pages+0x20/0x50
      [c787dd10] [c00e4f88] ubifs_jnl_write_data+0x54/0x200
      [c787dd50] [c00e82d4] do_writepage+0x94/0x198
      [c787dd90] [c00675e4] shrink_page_list+0x40c/0x77c
      [c787de40] [c0067de0] shrink_inactive_list+0x1e0/0x370
      [c787de90] [c0068224] shrink_zone+0x2b4/0x2b8
      [c787df00] [c0068854] kswapd+0x408/0x5d4
      [c787dfb0] [c0037bcc] kthread+0x80/0x84
      [c787dff0] [c000ef44] kernel_thread+0x4c/0x68
      
      Similar problems were encountered last April by Tomasz Stanislawski:
      
      http://patchwork.ozlabs.org/patch/50965/
      
      This patch implements Artem's suggested fix: fall back to a
      mutex-protected static buffer, allocated at mount time.  I tested it
      by forcing execution down the failure path, and didn't see any ill
      effects.
      
      Artem: massaged the patch a little, improved it so that we'd not
      allocate the write reserve buffer when we are in R/O mode.
      Signed-off-by: NMatthew L. Creech <mlcreech@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      d882962f
  8. 20 9月, 2010 1 次提交
    • A
      UBIFS: introduce new flags for RO mounts · 2ef13294
      Artem Bityutskiy 提交于
      Commit 2fde99cb "UBIFS: mark VFS SB RO too"
      introduced regression. This commit made UBIFS set the 'MS_RDONLY' flag in the
      VFS superblock when it switches to R/O mode due to an error. This was done
      to make VFS show the R/O UBIFS flag in /proc/mounts.
      
      However, several places in UBIFS relied on the 'MS_RDONLY' flag and assume this
      flag can only change when we re-mount. For example, 'ubifs_put_super()'.
      
      This patch introduces new UBIFS flag - 'c->ro_mount' which changes only when
      we re-mount, and preserves the way UBIFS was originally mounted (R/W or R/O).
      This allows us to de-initialize UBIFS cleanly in 'ubifs_put_super()'.
      
      This patch also changes all 'ubifs_assert(!c->ro_media)' assertions to
      'ubifs_assert(!c->ro_media && !c->ro_mount)', because we never should write
      anything if the FS was mounter R/O.
      
      All the places where we test for 'MS_RDONLY' flag in the VFS SB were changed
      and now we test the 'c->ro_mount' flag instead, because it preserves the
      original UBIFS mount type, unlike the 'MS_RDONLY' flag.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      2ef13294
  9. 17 9月, 2010 1 次提交
    • A
      UBIFS: introduce new flag for RO due to errors · 2680d722
      Artem Bityutskiy 提交于
      The R/O state may have various reasons:
      
      1. The UBI volume is R/O
      2. The FS is mounted R/O
      3. The FS switched to R/O mode because of an error
      
      However, in UBIFS we have only one variable which represents cases
      1 and 3 - 'c->ro_media'. Indeed, we set this to 1 if we switch to
      R/O mode due to an error, and then we test it in many places to
      make sure that we stop writing as soon as the error happens.
      
      But this is very unclean. One consequence of this, for example, is
      that in 'ubifs_remount_fs()' we use 'c->ro_media' to check whether
      we are in R/O mode because on an error, and we print a message
      in this case. However, if we are in R/O mode because the media
      is R/O, our message is bogus.
      
      This patch introduces new flag - 'c->ro_error' which is set when
      we switch to R/O mode because of an error. It also changes all
      "if (c->ro_media)" checks to "if (c->ro_error)" checks, because
      this is what the checks actually mean. We do not need to check
      for 'c->ro_media' because if the UBI volume is in R/O mode, we
      do not allow R/W mounting, and now writes can happen. This is
      guaranteed by VFS. But it is good to double-check this, so this
      patch also adds many "ubifs_assert(!c->ro_media)" checks.
      
      In the 'ubifs_remount_fs()' function this patch makes a bit more
      changes - it fixes the error messages as well.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      2680d722
  10. 15 9月, 2009 1 次提交
  11. 21 3月, 2009 1 次提交
  12. 08 3月, 2009 1 次提交
  13. 20 1月, 2009 1 次提交
  14. 06 1月, 2009 1 次提交
  15. 31 12月, 2008 2 次提交
    • A
      UBIFS: fix writing uncompressed files · a9f2fc0e
      Artem Bityutskiy 提交于
      UBIFS does not disable compression if ui->flags is non-zero, e.g.
      if the file has "sync" flag. This is because of the typo which
      is fixed by this patch. The patch also adds a couple of useful
      debugging prints.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      a9f2fc0e
    • A
      UBIFS: fix checkpatch.pl warnings · f92b9826
      Artem Bityutskiy 提交于
      These are mostly long lines and wrong indentation warning
      fixes. But also there are two volatile variables and
      checkpatch.pl complains about them:
      
      WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
      +       volatile int gc_seq;
      
      WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
      +       volatile int gced_lnum;
      
      Well, we anyway use smp_wmb() for c->gc_seq and c->gced_lnum, so
      these 'volatile' modifiers can be just dropped.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      f92b9826
  16. 06 11月, 2008 1 次提交
    • A
      UBIFS: fix compilation warnings · e84461ad
      Artem Bityutskiy 提交于
      We print 'ino_t' type using '%lu' printk() placeholder, but this
      results in many warnings when compiling for Alpha platform. Fix
      this by adding (unsingned long) casts.
      
      Fixes these warnings:
      
      fs/ubifs/journal.c:693: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/journal.c:1131: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/dir.c:163: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/tnc.c:2680: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/tnc.c:2700: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/replay.c:1066: warning: format '%lu' expects type 'long unsigned int', but argument 7 has type 'ino_t'
      fs/ubifs/orphan.c:108: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:135: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:142: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:154: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:159: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:451: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:539: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:612: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:843: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/orphan.c:856: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1438: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1443: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1475: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/recovery.c:1495: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:105: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:105: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:114: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:114: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:118: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:118: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
      fs/ubifs/debug.c:1591: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1671: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1674: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1680: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1699: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1788: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1821: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1833: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:1924: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1932: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1938: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1945: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1953: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1960: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1967: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1973: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1988: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
      fs/ubifs/debug.c:1991: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
      fs/ubifs/debug.c:2009: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'ino_t'
      Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      e84461ad
  17. 14 8月, 2008 1 次提交
    • A
      UBIFS: xattr bugfixes · c78c7e35
      Artem Bityutskiy 提交于
      Xattr code has not been tested for a while and there were
      serveral bugs. One of them is using wrong inode in
      'ubifs_jnl_change_xattr()'. The other is a deadlock in
      'ubifs_setxattr()': the i_mutex is locked in
      'cap_inode_need_killpriv()' path, so deadlock happens when
      'ubifs_setxattr()' tries to lock it again.
      
      Thanks to Zoltan Sogor for finding these bugs.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      c78c7e35
  18. 13 8月, 2008 5 次提交
  19. 15 7月, 2008 1 次提交