Eric Lee / smarc-fsl-linux-kernel

30 Apr, 2019

2 commits

15 Oct, 2018

1 commit

06 Aug, 2018

1 commit

12 Apr, 2018

1 commit

26 Mar, 2018

1 commit

  • 9678c5438   btrfs: Remove custom crc32c init code ... Browse Code »

    The custom crc32 init code was introduced in
    14a958e678cd ("Btrfs: fix btrfs boot when compiled as built-in") to
    enable using btrfs as a built-in. However, later as pointed out by
    60efa5eb2e88 ("Btrfs: use late_initcall instead of module_init") this
    wasn't enough and finally btrfs was switched to late_initcall which
    comes after the generic crc32c implementation is initiliased. The
    latter commit superseeded the former. Now that we don't have to
    maintain our own code let's just remove it and switch to using the
    generic implementation.

    Despite touching a lot of files the patch is really simple. Here is the gist of
    the changes:

    1. Select LIBCRC32C rather than the low-level modules.
    2. s/btrfs_crc32c/crc32c/g
    3. replace hash.h with linux/crc32c.h
    4. Move the btrfs namehash funcs to ctree.h and change the tree accordingly.

    I've tested this with btrfs being both a module and a built-in and xfstest
    doesn't complain.

    Does seem to fix the longstanding problem of not automatically selectiong
    the crc32c module when btrfs is used. Possibly there is a workaround in
    dracut.

    The modinfo confirms that now all the module dependencies are there:

    before:
    depends: zstd_compress,zstd_decompress,raid6_pq,xor,zlib_deflate

    after:
    depends: libcrc32c,zstd_compress,zstd_decompress,raid6_pq,xor,zlib_deflate

    Signed-off-by: Nikolay Borisov
    Reviewed-by: David Sterba
    [ add more info to changelog from mails ]
    Signed-off-by: David Sterba

    Nikolay Borisov
     

22 Jan, 2018

1 commit

  • bae15d95e   btrfs: Cleanup existing name_len checks ... Browse Code »

    Since tree-checker has verified leaf when reading from disk, we don't
    need the existing verify_dir_item() or btrfs_is_name_len_valid() checks.

    Signed-off-by: Qu Wenruo
    Reviewed-by: Nikolay Borisov
    Reviewed-by: David Sterba
    Signed-off-by: David Sterba

    Qu Wenruo
     

30 Jun, 2017

1 commit

  • 1164a9fb9   btrfs: fix validation of XATTR_ITEM dir items ... Browse Code »

    The XATTR_ITEM is a type of a directory item so we use the common
    validator helper. Unlike other dir items, it can have data. The way the
    name len validation is currently implemented does not reflect that. We'd
    have to adjust by the data_len when comparing the read and item limits.

    However, this will not work for multi-item xattr dir items.

    Example from tree dump of generic/337:

    item 7 key (257 XATTR_ITEM 751495445) itemoff 15667 itemsize 147
    location key (0 UNKNOWN.0 0) type XATTR
    transid 8 data_len 3 name_len 11
    name: user.foobar
    data 123
    location key (0 UNKNOWN.0 0) type XATTR
    transid 8 data_len 6 name_len 13
    name: user.WvG1c1Td
    data qwerty
    location key (0 UNKNOWN.0 0) type XATTR
    transid 8 data_len 5 name_len 19
    name: user.J3__T_Km3dVsW_
    data hello

    At the point of btrfs_is_name_len_valid call we don't have access to the
    data_len value of the 2nd and 3rd sub-item. So simple btrfs_dir_data_len(leaf,
    di) would always return 3, although we'd need to get 6 and 5 respectively to
    get the claculations right. (read_end + name_len + data_len vs item_end)

    We'd have to also pass data_len externally, which is not point of the
    name validation. The last check is supposed to test if there's at least
    one dir item space after the one we're processing. I don't think this is
    particularly useful, validation of the next item would catch that too.
    So the check is removed and we don't weaken the validation. Now tests
    btrfs/048, btrfs/053, generic/273 and generic/337 pass.

    Signed-off-by: David Sterba

    David Sterba
     

22 Jun, 2017

3 commits

  • 26a836cec   btrfs: Check name_len on add_inode_ref call path ... Browse Code »

    replay_one_buffer first reads buffers and dispatches items accroding to
    the item type.
    In this patch, add_inode_ref handles inode_ref and inode_extref.
    Then add_inode_ref calls ref_get_fields and extref_get_fields to read
    ref/extref name for the first time.
    So checking name_len before reading those two is fine.

    add_inode_ref also calls inode_in_dir to match ref/extref in parent_dir.
    The call graph includes btrfs_match_dir_item_name to read dir_item name
    in the parent dir.
    Checking first dir_item is not enough. Change it to verify every
    dir_item while doing matches.

    Signed-off-by: Su Yue
    Reviewed-by: David Sterba
    Signed-off-by: David Sterba

    Su Yue
     
  • e79a33270   btrfs: Check name_len with boundary in verify dir_item ... Browse Code »

    Originally, verify_dir_item verifies name_len of dir_item with fixed
    values but not item boundary.
    If corrupted name_len was not bigger than the fixed value, for example
    255, the function will think the dir_item is fine. And then reading
    beyond boundary will cause crash.

    Example:
    1. Corrupt one dir_item name_len to be 255.
    2. Run 'ls -lar /mnt/test/ > /dev/null'
    dmesg:
    [ 48.451449] BTRFS info (device vdb1): disk space caching is enabled
    [ 48.451453] BTRFS info (device vdb1): has skinny extents
    [ 48.489420] general protection fault: 0000 [#1] SMP
    [ 48.489571] Modules linked in: ext4 jbd2 mbcache btrfs xor raid6_pq
    [ 48.489716] CPU: 1 PID: 2710 Comm: ls Not tainted 4.10.0-rc1 #5
    [ 48.489853] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
    [ 48.490008] task: ffff880035df1bc0 task.stack: ffffc90004800000
    [ 48.490008] RIP: 0010:read_extent_buffer+0xd2/0x190 [btrfs]
    [ 48.490008] RSP: 0018:ffffc90004803d98 EFLAGS: 00010202
    [ 48.490008] RAX: 000000000000001b RBX: 000000000000001b RCX: 0000000000000000
    [ 48.490008] RDX: ffff880079dbf36c RSI: 0005080000000000 RDI: ffff880079dbf368
    [ 48.490008] RBP: ffffc90004803dc8 R08: ffff880078e8cc48 R09: ffff880000000000
    [ 48.490008] R10: 0000160000000000 R11: 0000000000001000 R12: ffff880079dbf288
    [ 48.490008] R13: ffff880078e8ca88 R14: 0000000000000003 R15: ffffc90004803e20
    [ 48.490008] FS: 00007fef50c60800(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
    [ 48.490008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 48.490008] CR2: 000055f335ac2ff8 CR3: 000000007356d000 CR4: 00000000001406e0
    [ 48.490008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 48.490008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 48.490008] Call Trace:
    [ 48.490008] btrfs_real_readdir+0x3b7/0x4a0 [btrfs]
    [ 48.490008] iterate_dir+0x181/0x1b0
    [ 48.490008] SyS_getdents+0xa7/0x150
    [ 48.490008] ? fillonedir+0x150/0x150
    [ 48.490008] entry_SYSCALL_64_fastpath+0x18/0xad
    [ 48.490008] RIP: 0033:0x7fef5032546b
    [ 48.490008] RSP: 002b:00007ffeafcdb830 EFLAGS: 00000206 ORIG_RAX: 000000000000004e
    [ 48.490008] RAX: ffffffffffffffda RBX: 00007fef5061db38 RCX: 00007fef5032546b
    [ 48.490008] RDX: 0000000000008000 RSI: 000055f335abaff0 RDI: 0000000000000003
    [ 48.490008] RBP: 00007fef5061dae0 R08: 00007fef5061db48 R09: 0000000000000000
    [ 48.490008] R10: 000055f335abafc0 R11: 0000000000000206 R12: 00007fef5061db38
    [ 48.490008] R13: 0000000000008040 R14: 00007fef5061db38 R15: 000000000000270e
    [ 48.490008] RIP: read_extent_buffer+0xd2/0x190 [btrfs] RSP: ffffc90004803d98
    [ 48.499455] ---[ end trace 321920d8e8339505 ]---

    Fix it by adding a parameter @slot and check name_len with item boundary
    by calling btrfs_is_name_len_valid.

    Signed-off-by: Su Yue
    rev
    Signed-off-by: David Sterba

    Su Yue
     
  • 19c6dcbfa   btrfs: Introduce btrfs_is_name_len_valid to avoid reading beyond boundary ... Browse Code »

    Introduce function btrfs_is_name_len_valid.

    The function compares parameter @name_len with item boundary then
    returns true if name_len is valid.

    Signed-off-by: Su Yue
    Reviewed-by: David Sterba
    [ s/btrfs_leaf_data/BTRFS_LEAF_DATA_OFFSET/ ]
    Signed-off-by: David Sterba

    Su Yue
     

10 Jun, 2017

1 commit

28 Feb, 2017

2 commits

14 Feb, 2017

3 commits

06 Dec, 2016

3 commits

27 Sep, 2016

1 commit

  • 5d163e0e6   btrfs: unsplit printed strings ... Browse Code »

    CodingStyle chapter 2:
    "[...] never break user-visible strings such as printk messages,
    because that breaks the ability to grep for them."

    This patch unsplits user-visible strings.

    Signed-off-by: Jeff Mahoney
    Signed-off-by: David Sterba

    Jeff Mahoney
     

21 Nov, 2014

1 commit

  • 5f5bc6b1e   Btrfs: make xattr replace operations atomic ... Browse Code »

    Replacing a xattr consists of doing a lookup for its existing value, delete
    the current value from the respective leaf, release the search path and then
    finally insert the new value. This leaves a time window where readers (getxattr,
    listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs,
    so this has security implications.

    This change also fixes 2 other existing issues which were:

    *) Deleting the old xattr value without verifying first if the new xattr will
    fit in the existing leaf item (in case multiple xattrs are packed in the
    same item due to name hash collision);

    *) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't
    exist but we have have an existing item that packs muliple xattrs with
    the same name hash as the input xattr. In this case we should return ENOSPC.

    A test case for xfstests follows soon.

    Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace
    implementation.

    Reported-by: Alexandre Oliva
    Signed-off-by: Filipe Manana
    Signed-off-by: Chris Mason

    Filipe Manana
     

18 Sep, 2014

1 commit

29 Jan, 2014

2 commits

12 Nov, 2013

2 commits

07 May, 2013

3 commits

  • 48a3b6366   btrfs: make static code static & remove dead code ... Browse Code »

    Big patch, but all it does is add statics to functions which
    are in fact static, then remove the associated dead-code fallout.

    removed functions:

    btrfs_iref_to_path()
    __btrfs_lookup_delayed_deletion_item()
    __btrfs_search_delayed_insertion_item()
    __btrfs_search_delayed_deletion_item()
    find_eb_for_page()
    btrfs_find_block_group()
    range_straddles_pages()
    extent_range_uptodate()
    btrfs_file_extent_length()
    btrfs_scrub_cancel_devid()
    btrfs_start_transaction_lflush()

    btrfs_print_tree() is left because it is used for debugging.
    btrfs_start_transaction_lflush() and btrfs_reada_detach() are
    left for symmetry.

    ulist.c functions are left, another patch will take care of those.

    Signed-off-by: Eric Sandeen
    Signed-off-by: Josef Bacik

    Eric Sandeen
     
  • 4b90c6801   Btrfs: remove unused argument of btrfs_extend_item() ... Browse Code »

    Argument 'trans' is not used in btrfs_extend_item().

    Signed-off-by: Tsutomu Itoh
    Signed-off-by: Josef Bacik

    Tsutomu Itoh
     
  • afe5fea72   Btrfs: cleanup of function where fixup_low_keys() is called ... Browse Code »

    If argument 'trans' is unnecessary in the function where
    fixup_low_keys() is called, 'trans' is deleted.

    Signed-off-by: Tsutomu Itoh
    Signed-off-by: Josef Bacik

    Tsutomu Itoh
     

18 Dec, 2012

1 commit

  • 9c52057c6   Btrfs: fix hash overflow handling ... Browse Code »

    The handling for directory crc hash overflows was fairly obscure,
    split_leaf returns EOVERFLOW when we try to extend the item and that is
    supposed to bubble up to userland. For a while it did so, but along the
    way we added better handling of errors and forced the FS readonly if we
    hit IO errors during the directory insertion.

    Along the way, we started testing only for EEXIST and the EOVERFLOW case
    was dropped. The end result is that we may force the FS readonly if we
    catch a directory hash bucket overflow.

    This fixes a few problem spots. First I add tests for EOVERFLOW in the
    places where we can safely just return the error up the chain.

    btrfs_rename is harder though, because it tries to insert the new
    directory item only after it has already unlinked anything the rename
    was going to overwrite. Rather than adding very complex logic, I added
    a helper to test for the hash overflow case early while it is still safe
    to bail out.

    Snapshot and subvolume creation had a similar problem, so they are using
    the new helper now too.

    Signed-off-by: Chris Mason
    Reported-by: Pascal Junod

    Chris Mason
     

22 Mar, 2012

2 commits

02 Aug, 2011

1 commit

11 Jul, 2011

1 commit

  • fa09200b8   Btrfs: try to only do one btrfs_search_slot in do_setxattr ... Browse Code »

    I've been watching how many btrfs_search_slot()'s we do and I noticed that when
    we create a file with selinux enabled we were doing 2 each time we initialize
    the security context. That's because we lookup the xattr first so we can delete
    it if we're setting a new value to an existing xattr. But in the create case we
    don't have any xattrs, so it is completely useless to have the extra lookup. So
    re-arrange things so that we only lookup first if we specifically have
    XATTR_REPLACE. That way in the basic case we only do 1 search, and in the more
    complicated case we do the normal 2 lookups. Thanks,

    Signed-off-by: Josef Bacik

    Josef Bacik
     

24 May, 2011

3 commits

23 May, 2011

1 commit

22 May, 2011

1 commit