1. 03 12月, 2008 9 次提交
  2. 22 11月, 2008 3 次提交
    • A
      UBIFS: pre-allocate bulk-read buffer · 3477d204
      Artem Bityutskiy 提交于
      To avoid memory allocation failure during bulk-read, pre-allocate
      a bulk-read buffer, so that if there is only one bulk-reader at
      a time, it would just use the pre-allocated buffer and would not
      do any memory allocation. However, if there are more than 1 bulk-
      reader, then only one reader would use the pre-allocated buffer,
      while the other reader would allocate the buffer for itself.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      3477d204
    • A
      UBIFS: do not allocate too much · 6c0c42cd
      Artem Bityutskiy 提交于
      Bulk-read allocates 128KiB or more using kmalloc. The allocation
      starts failing often when the memory gets fragmented. UBIFS still
      works fine in this case, because it falls-back to standard
      (non-optimized) read method, though. This patch teaches bulk-read
      to allocate exactly the amount of memory it needs, instead of
      allocating 128KiB every time.
      
      This patch is also a preparation to the further fix where we'll
      have a pre-allocated bulk-read buffer as well. For example, now
      the @bu object is prepared in 'ubifs_bulk_read()', so we could
      path either pre-allocated or allocated information to
      'ubifs_do_bulk_read()' later. Or teaching 'ubifs_do_bulk_read()'
      not to allocate 'bu->buf' if it is already there.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      6c0c42cd
    • A
      UBIFS: do not print scary memory allocation warnings · 39ce81ce
      Artem Bityutskiy 提交于
      Bulk-read allocates a lot of memory with 'kmalloc()', and when it
      is/gets fragmented 'kmalloc()' fails with a scarry warning. But
      because bulk-read is just an optimization, UBIFS keeps working fine.
      Supress the warning by passing __GFP_NOWARN option to 'kmalloc()'.
      
      This patch also introduces a macro for the magic 128KiB constant.
      This is just neater.
      
      Note, this is not really fixes the problem we had, but just hides
      the warnings. The further patches fix the problem.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      39ce81ce
  3. 07 11月, 2008 1 次提交
    • A
      UBIFS: allow for gaps when dirtying the LPT · 7e2d9bfa
      Adrian Hunter 提交于
      The LPT may have gaps in it because initially empty LEBs
      are not added by mkfs.ubifs - because it does not know how
      many there are.  Then UBIFS allocates empty LEBs in the
      reverse order that they are discovered i.e. they are
      added to, and removed from, the front of a list.  That
      creates a gap in the middle of the LPT.
      
      The function dirtying the LPT tree (for the purpose of
      small model garbage collection) assumed that a gap could
      only occur at the very end of the LPT and stopped dirtying
      prematurely, which in turn resulted in the LPT running
      out of space - something that is designed to be impossible.
      Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>
      7e2d9bfa
  4. 06 11月, 2008 3 次提交
    • 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
    • H
      UBIFS: endian handling fixes and annotations · 0ecb9529
      Harvey Harrison 提交于
      Noticed by sparse:
      fs/ubifs/file.c:75:2: warning: restricted __le64 degrades to integer
      fs/ubifs/file.c:629:4: warning: restricted __le64 degrades to integer
      fs/ubifs/dir.c:431:3: warning: restricted __le64 degrades to integer
      
      This should be checked to ensure the ubifs_assert is working as
      intended, I've done the suggested annotation in this patch.
      
      fs/ubifs/sb.c:298:6: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:298:6:    expected int [signed] [assigned] tmp
      fs/ubifs/sb.c:298:6:    got restricted __le64 [usertype] <noident>
      fs/ubifs/sb.c:299:19: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:299:19:    expected restricted __le64 [usertype] atime_sec
      fs/ubifs/sb.c:299:19:    got int [signed] [assigned] tmp
      fs/ubifs/sb.c:300:19: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:300:19:    expected restricted __le64 [usertype] ctime_sec
      fs/ubifs/sb.c:300:19:    got int [signed] [assigned] tmp
      fs/ubifs/sb.c:301:19: warning: incorrect type in assignment (different base types)
      fs/ubifs/sb.c:301:19:    expected restricted __le64 [usertype] mtime_sec
      fs/ubifs/sb.c:301:19:    got int [signed] [assigned] tmp
      
      This looks like a bugfix as your tmp was a u32 so there was truncation in
      the atime, mtime, ctime value, probably not intentional, add a tmp_le64
      and use it here.
      
      fs/ubifs/key.h:348:9: warning: cast to restricted __le32
      fs/ubifs/key.h:348:9: warning: cast to restricted __le32
      fs/ubifs/key.h:419:9: warning: cast to restricted __le32
      
      Read from the annotated union member instead.
      
      fs/ubifs/recovery.c:175:13: warning: incorrect type in assignment (different base types)
      fs/ubifs/recovery.c:175:13:    expected unsigned int [unsigned] [usertype] save_flags
      fs/ubifs/recovery.c:175:13:    got restricted __le32 [usertype] flags
      fs/ubifs/recovery.c:186:13: warning: incorrect type in assignment (different base types)
      fs/ubifs/recovery.c:186:13:    expected restricted __le32 [usertype] flags
      fs/ubifs/recovery.c:186:13:    got unsigned int [unsigned] [usertype] save_flags
      
      Do byteshifting at compile time of the flag value.  Annotate the saved_flags
      as le32.
      
      fs/ubifs/debug.c:368:10: warning: cast to restricted __le32
      fs/ubifs/debug.c:368:10: warning: cast from restricted __le64
      
      Should be checked if the truncation was intentional, I've changed the
      printk to print the full width.
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      0ecb9529
    • A
      UBIFS: remove printk · 069782a1
      Artem Bityutskiy 提交于
      Remove the "UBIFS background thread ubifs_bgd0_0 started" message.
      We kill the background thread when we switch to R/O mode, and
      start it again whan we switch to R/W mode. OLPC is doing this
      many times during boot, and we see this message many times as
      well, which is irritating. So just kill the message.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      069782a1
  5. 19 10月, 2008 3 次提交
    • G
      UBIFS: fix ubifs_compress commentary · 54779aab
      Geert Uytterhoeven 提交于
      Update the comment for ubifs_compress(), which incorrectly states that it
      returnsa success/failure indicator.
      Signed-off-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      54779aab
    • A
      UBIFS: amend printk · fae7fb29
      Artem Bityutskiy 提交于
      It is better to print "Reserved for root" than
      "Reserved pool size", because it is more obvious for users
      what this means.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      fae7fb29
    • A
      UBIFS: do not read unnecessary bytes when unpacking bits · 727d2dc0
      Adrian Hunter 提交于
      Fixes the following Oops:
      
      BUG: unable to handle kernel paging request at f8d24000
      IP: [<f8ff0657>] :ubifs:ubifs_unpack_bits+0xcd/0x231
      *pde = 34333067 *pte = 00000000
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: deflate zlib_deflate lzo lzo_decompress lzo_compress
      ubifs ubi nandsim nand nand_ids nand_ecc mtd nfsd lockd sunrpc exportfs
      [last unloaded: nand_ecc]
      
      Pid: 7450, comm: sync Not tainted (2.6.27-rc8-ubifs-2.6 #27)
      EIP: 0060:[<f8ff0657>] EFLAGS: 00010206 CPU: 0
      EIP is at ubifs_unpack_bits+0xcd/0x231 [ubifs]
      EAX: 00000000 EBX: 00000000 ECX: d7e43dc0 EDX: 0000ff00
      ESI: 00000004 EDI: f8d23ffe EBP: d7e43db4 ESP: d7e43d8c
      DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process sync (pid: 7450, ti=d7e42000 task=eb6f9530 task.ti=d7e42000)
      Stack: 00000400 c0103db4 dc5e8090 d7e43dc0 d7e43dc0 d7e43dc4 0000001c 00000004
            f496d1e0 f8d23ffc d7e43dd4 f8ffac7e f8d23ffe 00000000 f8d23ffe f2b7af68
            f496d1e0 f8d23ffc d7e43e2c f8ffadc5 00000000 0001f000 00000000 c03b10a7
      Call Trace:
      [<c0103db4>] ? restore_nocheck_notrace+0x0/0xe
      [<f8ffac7e>] ? is_a_node+0x43/0x92 [ubifs]
      [<f8ffadc5>] ? dbg_check_ltab+0xf8/0x5c9 [ubifs]
      [<c03b10a7>] ? mutex_lock_nested+0x1b2/0x2a0
      [<f8ffc86e>] ? ubifs_lpt_start_commit+0x49/0xecb [ubifs]
      [<c03b0ef3>] ? mutex_unlock+0xd/0xf
      [<f8fef017>] ? ubifs_tnc_start_commit+0x1cf/0xef8 [ubifs]
      [<f8fe65d8>] ? do_commit+0x18f/0x52d [ubifs]
      [<f8fe69f6>] ? ubifs_run_commit+0x80/0xca [ubifs]
      [<f8fd8d35>] ? ubifs_sync_fs+0xdb/0xf6 [ubifs]
      [<c0181a07>] ? sync_filesystems+0xc6/0x10c
      [<c019f279>] ? do_sync+0x3b/0x6a
      [<c019f2ba>] ? sys_sync+0x12/0x18
      [<c0103ced>] ? sysenter_do_call+0x12/0x35
      =======================
      Code: 4d ec 89 01 8b 45 e8 89 10 89 d8 89 f1 d3 e8 85 c0 74 07 29 d6 83 fe
      20 75 2a 89 d8 83 c4 1c 5b 5e 5f 5d c3 0f b6 57 01 c1 e2 08 <0f> b6 47 02
      c1 e0 10 09 c2 0f b6 07 09 c2 0f b
      EIP: [<f8ff0657>] ubifs_unpack_bits+0xcd/0x231 [ubifs] SS:ESP 0068:d7e43d8c
      ---[ end trace 1bbb4c407a6dd816 ]---
      Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>
      727d2dc0
  6. 14 10月, 2008 1 次提交
  7. 30 9月, 2008 20 次提交