10 Jan, 2016

1 commit


30 Aug, 2010

1 commit

  • When scanning the flash, UBIFS builds a list of flash nodes of type
    'struct ubifs_scan_node'. Each scanned node has a 'snod->key' field. This field
    is valid for most of the nodes, but invalid for some node type, e.g., truncation
    nodes. It is safer to explicitly initialize such keys to something invalid,
    rather than leaving them initialized to all zeros, which has key type of
    UBIFS_INO_KEY.

    This patch introduces new "fake" key type UBIFS_INVALID_KEY and initializes
    unused 'snod->key' objects to this type. It also adds debugging assertions in
    the TNC code to make sure no one ever tries to look these nodes up in the TNC.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

10 Sep, 2009

1 commit


24 Jul, 2009

1 commit


08 Mar, 2009

1 commit


03 Dec, 2008

1 commit

  • I have a habit of compiling kernel with
    EXTRA_CFLAGS="-Wextra -Wno-unused -Wno-sign-compare -Wno-missing-field-initializers"
    and so fs/ubifs/key.h give lots (~10) of these every time:

    CC fs/ubifs/tnc_misc.o
    In file included from fs/ubifs/ubifs.h:1725,
    from fs/ubifs/tnc_misc.c:30:
    fs/ubifs/key.h: In function 'key_r5_hash':
    fs/ubifs/key.h:64: warning: comparison of unsigned expression >= 0 is always true
    fs/ubifs/key.h: In function 'key_test_hash':
    fs/ubifs/key.h:81: warning: comparison of unsigned expression >= 0 is always true

    This patch fixes the warnings.

    Signed-off-by: Artem Bityutskiy

    Kukkonen Mika
     

06 Nov, 2008

1 commit

  • 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]
    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: Harvey Harrison
    Signed-off-by: Artem Bityutskiy

    Harvey Harrison
     

30 Sep, 2008

1 commit

  • Some flash media are capable of reading sequentially at faster rates.
    UBIFS bulk-read facility is designed to take advantage of that, by
    reading in one go consecutive data nodes that are also located
    consecutively in the same LEB.

    Read speed on Arm platform with OneNAND goes from 17 MiB/s to
    19 MiB/s.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     

15 Jul, 2008

1 commit