Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 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
  3. 07 9月, 2010 2 次提交
  5. 30 8月, 2010 11 次提交
    • A
      UBIFS: improve error reporting when reading bad node · 3a8fa0ed
      由 Artem Bityutskiy 提交于 
      When an error happens during validation of read node, the typical situation is that
the LEB we read is unmapped (due to some bug). It is handy to include the mapping
status into the error message.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      3a8fa0ed
    • A
      UBIFS: introduce list sorting debugging checks · 3bb66b47
      由 Artem Bityutskiy 提交于 
      The UBIFS bug in the GC list sorting comparison functions inspired
me to write internal debugging check functions which verify that
the list of nodes is sorted properly.

So, this patch implements 2 new debugging functions:
 o 'dbg_check_data_nodes_order()' - check order of data nodes list
 o 'dbg_check_nondata_nodes_order()' - check order of non-data nodes list

The debugging functions are executed only if general UBIFS debugging checks are
enabled. And they are compiled out if UBIFS debugging is disabled.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      3bb66b47
    • A
      UBIFS: fix assertion warnings in comparison function · 1a9476a7
      由 Artem Bityutskiy 提交于 
      When running the integrity test ('integck' from mtd-utils) on current
UBIFS on 2.6.35, I see that assertions in UBIFS 'list_sort()' comparison
functions trigger sometimes, e.g.:

UBIFS assert failed in data_nodes_cmp at 132 (pid 28311)

My investigation showed that this happens when 'list_sort()' calls the 'cmp()'
function with equivalent arguments. In this case, the 'struct list_head'
parameter, passed to 'cmp()' is bogus, and it does not belong to any element in
the original list.

And this issue seems to be introduced by commit:

commit 835cc0c8
Author: Don Mullis <don.mullis@gmail.com>
Date:   Fri Mar 5 13:43:15 2010 -0800

It is easy to work around the issue by doing:

if (a == b)
	return 0;

in UBIFS. It works, but 'lib_sort()' should nevertheless be fixed. Although it
is harmless to have this piece of code in UBIFS.

This patch adds that code to both UBIFS 'cmp()' functions:
'data_nodes_cmp()' and 'nondata_nodes_cmp()'.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      1a9476a7
    • A
      UBIFS: mark unused key objects as invalid · ba2f48f7
      由 Artem Bityutskiy 提交于 
      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: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      ba2f48f7
    • A
      UBIFS: do not write rubbish into truncation scanning node · 5b7a3a2e
      由 Artem Bityutskiy 提交于 
      In the scanning code, in 'ubifs_add_snod()', we write rubbish into
'snod->key', because we assume that on-flash truncation nodes have a key, but
they do not. If the other parts of UBIFS then mistakenly try to look-up
the truncation node key (they should not do this, but may do because of a bug),
we can succeed and corrupt TNC. It looks like we did have such a situation in
'sort_nodes()' in gc.c.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      5b7a3a2e
    • A
      UBIFS: improve assertion in node comparison functions · 66576833
      由 Artem Bityutskiy 提交于 
      Improve assertions in gc.c in the comparison functions for 'list_sort()': check
key types _and_ node types.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      66576833
    • A
      UBIFS: do not use key type in list_sort · ab87118d
      由 Artem Bityutskiy 提交于 
      In comparison function for 'list_sort()' we use key type to distinguish between
node types. However, we have a bit simper way to detect node type -
'snod->type'. This more logical to use, comparing to decoding key types. Also
allows to get rid of 2 local variables.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      ab87118d
    • A
      UBIFS: do not look up truncation nodes · 44ec83b8
      由 Artem Bityutskiy 提交于 
      When moving nodes in GC, do not try to look up truncation nodes in TNC,
because they do not exist there. This would be harmless, because the TNC
look-up would fail, if we did not have bug 'ubifs_add_snod()' which reads
garbage into 'snod->key'. But in any case, it is less error prone to
explicitly ignore everything but inode, data, dentry and xentry nodes.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      44ec83b8
    • A
      UBIFS: fix assertion warning · e3408ad4
      由 Artem Bityutskiy 提交于 
      This patch fixes the following false assertion warning:

UBIFS assert failed in data_nodes_cmp at 130 (pid 15107)

The assertion was wrong because it did not take into account that the
node can be an xentry.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      e3408ad4
    • A
      UBIFS: do not treat ENOSPC specially · efe1881f
      由 Artem Bityutskiy 提交于 
      'ubifs_garbage_collect_leb()' should never return '-ENOSPC', and if it
does, this is an error. Thus, do not treat this error code specially.
'-EAGAIN' is a special error code, but not '-ENOSPC'.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      efe1881f
    • A
      UBIFS: switch to RO mode after synchronizing · 5ffef88f
      由 Artem Bityutskiy 提交于 
      In 'ubifs_garbage_collect()' on error path, we first switch to R/O mode, and
then synchronize write-buffers (to make sure no data are lost). But the GC
write-buffer synchronization will fail, because we are already in R/O mode.
This patch re-orders this and makes sure we first synchronize the write-buffer,
and then switch to R/O mode.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      5ffef88f
  7. 29 8月, 2010 25 次提交
  9. 28 8月, 2010 1 次提交
    • D
      ALSA: pcm: add more format names · 7a28826a
      由 Dan Carpenter 提交于 
      There were some new formats added in commit 15c0cee6 "ALSA: pcm:
Define G723 3-bit and 5-bit formats".  That commit increased
SNDRV_PCM_FORMAT_LAST as well.  My concern is that there are a couple
places which do:

        for (i = 0; i < SNDRV_PCM_FORMAT_LAST; i++) {
                if (dummy->pcm_hw.formats & (1ULL << i))
                        snd_iprintf(buffer, " %s", snd_pcm_format_name(i));
        }

I haven't tested these but it looks like if "i" were equal to
SNDRV_PCM_FORMAT_G723_24 or higher then we might read past the end of
the array.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7a28826a