Eric Lee / smarc-fsl-linux-kernel

14 Jan, 2012

1 commit

13 Jan, 2012

1 commit

  • 515315a12   UBIFS: fix key printing ... Browse Code »
    43

    Before commit 56e46742e846e4de167dde0e1e1071ace1c882a5 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: Artem Bityutskiy

    Artem Bityutskiy
     

22 Nov, 2011

1 commit

04 Jul, 2011

4 commits

  • d304820a1   UBIFS: switch to ubifs_leb_read ... Browse Code »

    Instead of using 'ubi_read()' function directly, used the 'ubifs_leb_read()'
    helper function instead. This allows to get rid of several redundant error
    messages and make sure that we always have a stack dump on read errors.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • 2b1844a8c   UBIFS: introduce helper functions for debugging checks and tests ... Browse Code »

    This patch introduces helper functions for all debugging checks, so instead of
    doing

    if (!(ubifs_chk_flags & UBIFS_CHK_GEN))

    we now do

    if (!dbg_is_chk_gen(c))

    This is a preparation to further changes where the flags will go away, and
    we'll need to only change the helper functions, but the code which utilizes
    them won't be touched.

    At the same time this patch removes 'dbg_force_in_the_gaps()',
    'dbg_force_in_the_gaps_enabled()', and dbg_failure_mode helpers for
    consistency.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • f42eed7cb   UBIFS: harmonize znode flag helpers ... Browse Code »

    We have 3 znode flags: cow, obsolete, dirty. For the last flag we have a
    'ubifs_zn_dirty()' helper function, but for the other 2 flags we use
    'test_bit()' directly.

    This patch makes the situation more consistent and introduces helpers for the
    other 2 flags: 'ubifs_zn_cow()' and 'ubifs_zn_obsolete()'.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • 4315fb407   UBIFS: improve inode dumping function ... Browse Code »

    Teach 'dbg_dump_inode()' dump directory entries for directory inodes.
    This requires few additional changes:
    1. The 'c' argument of 'dbg_dump_inode()' cannot be const any more.
    2. Users of 'dbg_dump_inode()' should not have 'tnc_mutex' locked.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

03 Jun, 2011

1 commit

  • 837072377   UBIFS: fix clean znode counter corruption in error cases ... Browse Code »

    UBIFS maintains per-filesystem and global clean znode counters
    ('c->clean_zn_cnt' and 'ubifs_clean_zn_cnt'). It is important to maintain
    correct values there since the shrinker relies on 'ubifs_clean_zn_cnt'.

    However, in case of failures during commit the counters were corrupted. E.g.,
    if a failure happens in the middle of 'write_index()', then some nodes in the
    commit list ('c->cnext') are marked as clean, and some are marked as dirty. And
    the 'ubifs_destroy_tnc_subtree()' frees does not retrun correct count, and we
    end up with non-zero 'c->clean_zn_cnt' when unmounting. This means that if we
    have 2 file-sytem and one of them fails, and we unmount it,
    'ubifs_clean_zn_cnt' stays incorrect and confuses the shrinker.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

14 May, 2011

1 commit

18 Jan, 2011

1 commit

  • 18d1d7fbc   UBIFS: introduce mounting flag ... Browse Code »

    This is a preparational patch which removes the 'c->always_chk_crc' which was
    set during mounting and remounting to R/W mode and introduces 'c->mounting'
    flag which is set when mounting. Now the 'c->always_chk_crc' flag is the
    same as 'c->remounting_rw && c->mounting'.

    This patch is a preparation for the next one which will need to know when we
    are mounting and remounting to R/W mode, which is exactly what
    'c->always_chk_crc' effectively is, but its name does not suite the
    next patch. The other possibility would be to just re-name it, but then
    we'd end up with less logical flags coverage.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

30 Aug, 2010

1 commit

  • ba2f48f70   UBIFS: mark unused key objects as invalid ... Browse Code »

    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
     

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

10 Sep, 2009

1 commit

21 Mar, 2009

1 commit

27 Jan, 2009

1 commit

  • 6f7ab6d45   UBIFS: fix no_chk_data_crc ... Browse Code »

    When data CRC checking is disabled, UBIFS returns incorrect return
    code from the 'try_read_node()' function (0 instead of 1, which means
    CRC error), which make the caller re-read the data node again, but using
    a different code patch, so the second read is fine. Thus, we read the
    same node twice. And the result of this is that UBIFS is slower
    with no_chk_data_crc option than it is with chk_data_crc option.
    This patches fixes the problem.

    Reported-by: Reuben Dowle
    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

31 Dec, 2008

1 commit

  • f92b98268   UBIFS: fix checkpatch.pl warnings ... Browse Code »

    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: Artem Bityutskiy

    Artem Bityutskiy
     

22 Nov, 2008

1 commit

  • 6c0c42cdf   UBIFS: do not allocate too much ... Browse Code »

    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: Artem Bityutskiy

    Artem Bityutskiy
     

06 Nov, 2008

1 commit

  • e84461ad9   UBIFS: fix compilation warnings ... Browse Code »

    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: Randy Dunlap
    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

30 Sep, 2008

5 commits

17 Sep, 2008

1 commit

  • 6dcfac4f1   UBIFS: TNC / GC race fixes ... Browse Code »

    - update GC sequence number if any nodes may have been moved
    even if GC did not finish the LEB
    - don't ignore error return when reading

    Signed-off-by: Adrian Hunter
    Signed-off-by: Artem Bityutskiy

    Adrian Hunter
     

25 Aug, 2008

2 commits

  • 601c0bc46   UBIFS: allow for racing between GC and TNC ... Browse Code »

    The TNC mutex is unlocked prematurely when reading leaf nodes
    with non-hashed keys. This is unsafe because the node may be
    moved by garbage collection and the eraseblock unmapped, although
    that has never actually happened during stress testing.

    This patch fixes the flaw by detecting the race and retrying with
    the TNC mutex locked.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     
  • 761e29f3b   UBIFS: always read hashed-key nodes under TNC mutex ... Browse Code »

    Leaf-nodes that have a hashed key are stored in the
    leaf-node-cache (LNC) which is protected by the TNC
    mutex. Consequently, when reading a leaf node with
    a hashed key (i.e. directory entries, xattr entries)
    the TNC mutex is always required.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     

15 Jul, 2008

1 commit