Eric Lee / smarc-fsl-linux-kernel

12 Nov, 2020

1 commit

  • 4358dcf4e   ANDROID: ext4: fix encrypt+casefold support ... Browse Code »

    When syncing ext4 with upstream commit f8f4acb6cded ("ext4: use generic
    casefolding support"), we forgot to take into account that some
    additional checks for the encryption key are needed for the
    encrypt+casefold support which isn't upstream yet.

    (These checks for the encryption key are still racy since they happen
    too late, but apparently they worked well enough...)

    This bug made it impossible to delete encrypted+casefolded directories
    without the encryption key, due to errors like:

    W : EXT4-fs warning (device vdc): __ext4fs_dirhash:270: inode #49202: comm Binder:378_4: Siphash requires key

    Fixes: 76bfcb2dc2f3 ("ANDROID: sync generic casefolding code with patches going upstream")
    Bug: 161184936
    Bug: 172809853
    Test: in kvm-xfstests test appliance:
    mkfs.ext4 -F -E encoding=utf8 -O encrypt /dev/vdc
    mount /vdc
    mkdir /vdc/dir
    chattr +F /vdc/dir
    keyid=$(head -c 64 /dev/zero | xfs_io -c add_enckey /vdc | awk '{print $NF}')
    xfs_io -c "set_encpolicy $keyid" /vdc/dir
    for i in `seq 1 100`; do
    mkdir /vdc/dir/$i
    done
    xfs_io -c "rm_enckey $keyid" /vdc
    rm -rf /vdc/dir # fails with the bug
    Change-Id: I67fbc9e34778519b229835e1d1b784bd42006ce7
    Signed-off-by: Eric Biggers

    Eric Biggers
     

28 Sep, 2020

1 commit

  • 76bfcb2dc   ANDROID: sync generic casefolding code with patches going upstream ... Browse Code »

    Get the generic casefolding code in sync with the patches that are
    queued in f2fs.git#dev for 5.10.

    Equivalently, this reverts the patch
    "ANDROID-fs-adjust-casefolding-support-to-match-android-mainline.patch"
    from the android-mainline quilt series, with the following conflicts:

    Conflicts:
    fs/ext4/hash.c # due to "ANDROID: ext4: Handle casefolding with encryption"
    fs/ext4/namei.c # due to "ANDROID: ext4: Handle casefolding with encryption"
    fs/f2fs/dir.c # due to "ANDROID: f2fs: Handle casefolding with Encryption"

    Bug: 161184936
    Cc: Daniel Rosenberg
    Cc: Paul Lawrence
    Cc: Jaegeuk Kim
    Change-Id: I0ae169f0f5f413fb21e4be7a163213aef3fa6756
    Signed-off-by: Eric Biggers

    Eric Biggers
     

24 Aug, 2020

1 commit

19 Aug, 2020

1 commit

26 Jun, 2020

1 commit

  • 705a3e5b1   ANDROID: ext4: Handle casefolding with encryption ... Browse Code »

    This adds support for encryption with casefolding.

    Since the name on disk is case preserving, and also encrypted, we can no
    longer just recompute the hash on the fly. Additionally, to avoid
    leaking extra information from the hash of the unencrypted name, we use
    siphash via an fscrypt v2 policy.

    The hash is stored at the end of the directory entry for all entries
    inside of an encrypted and casefolded directory apart from those that
    deal with '.' and '..'. This way, the change is backwards compatible
    with existing ext4 filesystems.

    Signed-off-by: Daniel Rosenberg
    Signed-off-by: Paul Lawrence
    Test: Boots, /data/media is case insensitive
    Bug: 138322712
    Change-Id: I07354e3129aa07d309fbe36c002fee1af718f348

    Daniel Rosenberg
     

21 Feb, 2020

1 commit

  • 8b67e802e   FROMLIST: ext4: Use generic casefolding support ... Browse Code »

    This switches ext4 over to the generic support provided in
    commit 65832afbeaaf ("fs: Add standard casefolding support")

    Signed-off-by: Daniel Rosenberg
    Test: Boots, /data/media is case insensitive
    Bug: 138322712
    Link: https://lore.kernel.org/linux-f2fs-devel/20200208013552.241832-1-drosen@google.com/T/#t
    Change-Id: I3a0705278100590df4c7cdd0dcdf945e9f11feb7

    Daniel Rosenberg
     

03 Sep, 2019

1 commit

  • 6456ca652   ext4: fix kernel oops caused by spurious casefold flag ... Browse Code »

    If an directory has the a casefold flag set without the casefold
    feature set, s_encoding will not be initialized, and this will cause
    the kernel to dereference a NULL pointer. In addition to adding
    checks to avoid these kernel oops, attempts to load inodes with the
    casefold flag when the casefold feature is not enable will cause the
    file system to be declared corrupted.

    Signed-off-by: Theodore Ts'o

    Theodore Ts'o
     

26 Apr, 2019

1 commit

  • b886ee3e7   ext4: Support case-insensitive file name lookups ... Browse Code »

    This patch implements the actual support for case-insensitive file name
    lookups in ext4, based on the feature bit and the encoding stored in the
    superblock.

    A filesystem that has the casefold feature set is able to configure
    directories with the +F (EXT4_CASEFOLD_FL) attribute, enabling lookups
    to succeed in that directory in a case-insensitive fashion, i.e: match
    a directory entry even if the name used by userspace is not a byte per
    byte match with the disk name, but is an equivalent case-insensitive
    version of the Unicode string. This operation is called a
    case-insensitive file name lookup.

    The feature is configured as an inode attribute applied to directories
    and inherited by its children. This attribute can only be enabled on
    empty directories for filesystems that support the encoding feature,
    thus preventing collision of file names that only differ by case.

    * dcache handling:

    For a +F directory, Ext4 only stores the first equivalent name dentry
    used in the dcache. This is done to prevent unintentional duplication of
    dentries in the dcache, while also allowing the VFS code to quickly find
    the right entry in the cache despite which equivalent string was used in
    a previous lookup, without having to resort to ->lookup().

    d_hash() of casefolded directories is implemented as the hash of the
    casefolded string, such that we always have a well-known bucket for all
    the equivalencies of the same string. d_compare() uses the
    utf8_strncasecmp() infrastructure, which handles the comparison of
    equivalent, same case, names as well.

    For now, negative lookups are not inserted in the dcache, since they
    would need to be invalidated anyway, because we can't trust missing file
    dentries. This is bad for performance but requires some leveraging of
    the vfs layer to fix. We can live without that for now, and so does
    everyone else.

    * on-disk data:

    Despite using a specific version of the name as the internal
    representation within the dcache, the name stored and fetched from the
    disk is a byte-per-byte match with what the user requested, making this
    implementation 'name-preserving'. i.e. no actual information is lost
    when writing to storage.

    DX is supported by modifying the hashes used in +F directories to make
    them case/encoding-aware. The new disk hashes are calculated as the
    hash of the full casefolded string, instead of the string directly.
    This allows us to efficiently search for file names in the htree without
    requiring the user to provide an exact name.

    * Dealing with invalid sequences:

    By default, when a invalid UTF-8 sequence is identified, ext4 will treat
    it as an opaque byte sequence, ignoring the encoding and reverting to
    the old behavior for that unique file. This means that case-insensitive
    file name lookup will not work only for that file. An optional bit can
    be set in the superblock telling the filesystem code and userspace tools
    to enforce the encoding. When that optional bit is set, any attempt to
    create a file name using an invalid UTF-8 sequence will fail and return
    an error to userspace.

    * Normalization algorithm:

    The UTF-8 algorithms used to compare strings in ext4 is implemented
    lives in fs/unicode, and is based on a previous version developed by
    SGI. It implements the Canonical decomposition (NFD) algorithm
    described by the Unicode specification 12.1, or higher, combined with
    the elimination of ignorable code points (NFDi) and full
    case-folding (CF) as documented in fs/unicode/utf8_norm.c.

    NFD seems to be the best normalization method for EXT4 because:

    - It has a lower cost than NFC/NFKC (which requires
    decomposing to NFD as an intermediary step)
    - It doesn't eliminate important semantic meaning like
    compatibility decompositions.

    Although:

    - This implementation is not completely linguistic accurate, because
    different languages have conflicting rules, which would require the
    specialization of the filesystem to a given locale, which brings all
    sorts of problems for removable media and for users who use more than
    one language.

    Signed-off-by: Gabriel Krisman Bertazi
    Signed-off-by: Theodore Ts'o

    Gabriel Krisman Bertazi
     

21 Feb, 2019

1 commit

  • 034f891a8   ext4: annotate implicit fall throughs ... Browse Code »

    There is a plan to build the kernel with -Wimplicit-fallthrough and
    these places in the code produced warnings (W=1). Fix them up.

    This commit remove the following warnings:

    fs/ext4/hash.c:233:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
    fs/ext4/hash.c:246:15: warning: this statement may fall through [-Wimplicit-fallthrough=]

    Signed-off-by: Mathieu Malaterre
    Signed-off-by: Theodore Ts'o
    Reviewed-by: Andreas Dilger

    Mathieu Malaterre
     

18 Dec, 2017

1 commit

  • f51667685   ext4: fix up remaining files with SPDX cleanups ... Browse Code »

    A number of ext4 source files were skipped due because their copyright
    permission statements didn't match the expected text used by the
    automated conversion utilities. I've added SPDX tags for the rest.

    While looking at some of these files, I've noticed that we have quite
    a bit of variation on the licenses that were used --- in particular
    some of the Red Hat licenses on the jbd2 files use a GPL2+ license,
    and we have some files that have a LGPL-2.1 license (which was quite
    surprising).

    I've not attempted to do any license changes. Even if it is perfectly
    legal to relicense to GPL 2.0-only for consistency's sake, that should
    be done with ext4 developer community discussion.

    Signed-off-by: Theodore Ts'o

    Theodore Ts'o
     

25 Aug, 2017

1 commit

03 Feb, 2017

1 commit

  • 1c83a9aab   ext4: move halfmd4 into hash.c directly ... Browse Code »

    The "half md4" transform should not be used by any new code. And
    fortunately, it's only used now by ext4. Since ext4 supports several
    hashing methods, at some point it might be desirable to move to
    something like SipHash. As an intermediate step, remove half md4 from
    cryptohash.h and lib, and make it just a local function in ext4's
    hash.c. There's precedent for doing this; the other function ext can use
    for its hashes -- TEA -- is also implemented in the same place. Also, by
    being a local function, this might allow gcc to perform some additional
    optimizations.

    Signed-off-by: Jason A. Donenfeld
    Reviewed-by: Andreas Dilger
    Cc: Theodore Ts'o
    Signed-off-by: Theodore Ts'o

    Jason A. Donenfeld
     

03 Apr, 2015

1 commit

02 Feb, 2013

1 commit

19 Mar, 2012

1 commit

  • d1f5273e9   ext4: return 32/64-bit dir name hash according to usage type ... Browse Code »
    43

    Traditionally ext2/3/4 has returned a 32-bit hash value from llseek()
    to appease NFSv2, which can only handle a 32-bit cookie for seekdir()
    and telldir(). However, this causes problems if there are 32-bit hash
    collisions, since the NFSv2 server can get stuck resending the same
    entries from the directory repeatedly.

    Allow ext4 to return a full 64-bit hash (both major and minor) for
    telldir to decrease the chance of hash collisions. This still needs
    integration on the NFS side.

    Patch-updated-by: Bernd Schubert
    (blame me if something is not correct)

    Signed-off-by: Fan Yong
    Signed-off-by: Andreas Dilger
    Signed-off-by: Bernd Schubert
    Signed-off-by: "Theodore Ts'o"

    Fan Yong
     

29 Oct, 2008

1 commit

09 Sep, 2008

1 commit

30 Apr, 2008

1 commit

15 Feb, 2007

1 commit

  • cd354f1ae   [PATCH] remove many unneeded #includes of sched.h ... Browse Code »

    After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

12 Oct, 2006

3 commits