31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details you
    should have received a copy of the gnu general public license along
    with this program if not write to the free software foundation inc
    59 temple place suite 330 boston ma 02111 1307 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 1334 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Richard Fontana
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

07 Nov, 2017

1 commit


08 Oct, 2016

1 commit

  • Right now, various places in the kernel check for the existence of
    getxattr, setxattr, and removexattr inode operations and directly call
    those operations. Switch to helper functions and test for the IOP_XATTR
    flag instead.

    Signed-off-by: Andreas Gruenbacher
    Acked-by: James Morris
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

28 May, 2016

1 commit

  • smack ->d_instantiate() uses ->setxattr(), so to be able to call it before
    we'd hashed the new dentry and attached it to inode, we need ->setxattr()
    instances getting the inode as an explicit argument rather than obtaining
    it from dentry.

    Similar change for ->getxattr() had been done in commit ce23e64. Unlike
    ->getxattr() (which is used by both selinux and smack instances of
    ->d_instantiate()) ->setxattr() is used only by smack one and unfortunately
    it got missed back then.

    Reported-by: Seung-Woo Kim
    Tested-by: Casey Schaufler
    Signed-off-by: Al Viro

    Al Viro
     

03 May, 2016

1 commit


11 Apr, 2016

1 commit


05 Apr, 2016

1 commit

  • PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
    ago with promise that one day it will be possible to implement page
    cache with bigger chunks than PAGE_SIZE.

    This promise never materialized. And unlikely will.

    We have many places where PAGE_CACHE_SIZE assumed to be equal to
    PAGE_SIZE. And it's constant source of confusion on whether
    PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
    especially on the border between fs and mm.

    Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
    breakage to be doable.

    Let's stop pretending that pages in page cache are special. They are
    not.

    The changes are pretty straight-forward:

    - << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;

    - >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;

    - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};

    - page_cache_get() -> get_page();

    - page_cache_release() -> put_page();

    This patch contains automated changes generated with coccinelle using
    script below. For some reason, coccinelle doesn't patch header files.
    I've called spatch for them manually.

    The only adjustment after coccinelle is revert of changes to
    PAGE_CAHCE_ALIGN definition: we are going to drop it later.

    There are few places in the code where coccinelle didn't reach. I'll
    fix them manually in a separate patch. Comments and documentation also
    will be addressed with the separate patch.

    virtual patch

    @@
    expression E;
    @@
    - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
    + E

    @@
    expression E;
    @@
    - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
    + E

    @@
    @@
    - PAGE_CACHE_SHIFT
    + PAGE_SHIFT

    @@
    @@
    - PAGE_CACHE_SIZE
    + PAGE_SIZE

    @@
    @@
    - PAGE_CACHE_MASK
    + PAGE_MASK

    @@
    expression E;
    @@
    - PAGE_CACHE_ALIGN(E)
    + PAGE_ALIGN(E)

    @@
    expression E;
    @@
    - page_cache_get(E)
    + get_page(E)

    @@
    expression E;
    @@
    - page_cache_release(E)
    + put_page(E)

    Signed-off-by: Kirill A. Shutemov
    Acked-by: Michal Hocko
    Signed-off-by: Linus Torvalds

    Kirill A. Shutemov
     

27 Jan, 2016

1 commit


23 Jan, 2016

1 commit

  • parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
    inode_foo(inode) being mutex_foo(&inode->i_mutex).

    Please, use those for access to ->i_mutex; over the coming cycle
    ->i_mutex will become rwsem, with ->lookup() done with it held
    only shared.

    Signed-off-by: Al Viro

    Al Viro
     

07 Aug, 2015

1 commit


16 Apr, 2015

1 commit


20 Nov, 2014

1 commit


08 Nov, 2012

1 commit

  • ecryptfs_write_begin grabs a page from page cache for writing.
    If the page contains invalid data, or data older than the
    counterpart on the disk, eCryptfs will read out the
    corresponing data from the disk into the page, decrypt them,
    then perform writing. However, for this page, if the length
    of the data to be written into is equal to page size,
    that means the whole page of data will be overwritten,
    in which case, it does not matter whatever the data were before,
    it is beneficial to perform writing directly rather than bothering
    to read and decrypt first.

    With this optimization, according to our test on a machine with
    Intel Core 2 Duo processor, iozone 'write' operation on an existing
    file with write size being multiple of page size will enjoy a steady
    3x speedup.

    Signed-off-by: Li Wang
    Signed-off-by: Yunchuan Wen
    Signed-off-by: Tyler Hicks

    Li Wang
     

14 Jul, 2012

1 commit

  • A change was made about a year ago to get eCryptfs to better utilize its
    page cache during writes. The idea was to do the page encryption
    operations during page writeback, rather than doing them when initially
    writing into the page cache, to reduce the number of page encryption
    operations during sequential writes. This meant that the encrypted page
    would only be written to the lower filesystem during page writeback,
    which was a change from how eCryptfs had previously wrote to the lower
    filesystem in ecryptfs_write_end().

    The change caused a few eCryptfs-internal bugs that were shook out.
    Unfortunately, more grave side effects have been identified that will
    force changes outside of eCryptfs. Because the lower filesystem isn't
    consulted until page writeback, eCryptfs has no way to pass lower write
    errors (ENOSPC, mainly) back to userspace. Additionaly, it was reported
    that quotas could be bypassed because of the way eCryptfs may sometimes
    open the lower filesystem using a privileged kthread.

    It would be nice to resolve the latest issues, but it is best if the
    eCryptfs commits be reverted to the old behavior in the meantime.

    This reverts:
    32001d6f "eCryptfs: Flush file in vma close"
    5be79de2 "eCryptfs: Flush dirty pages in setattr"
    57db4e8d "ecryptfs: modify write path to encrypt page in writepage"

    Signed-off-by: Tyler Hicks
    Tested-by: Colin King
    Cc: Colin King
    Cc: Thieu Le

    Tyler Hicks
     

17 Feb, 2012

1 commit


26 Jan, 2012

1 commit


28 Mar, 2011

3 commits

  • Unlock the page in error path of ecryptfs_write_begin(). This may
    happen, for example, if decryption fails while bring the page
    up-to-date.

    Cc:
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • Change the write path to encrypt the data only when the page is written to
    disk in ecryptfs_writepage. Previously, ecryptfs encrypts the page in
    ecryptfs_write_end which means that if there are multiple write requests to
    the same page, ecryptfs ends up re-encrypting that page over and over again.
    This patch minimizes the number of encryptions needed.

    Signed-off-by: Thieu Le
    [tyhicks: Changed NULL .drop_inode sop pointer to generic_drop_inode]
    Signed-off-by: Tyler Hicks

    Thieu Le
     
  • Now that grow_file() is not called in the ecryptfs_create() path, the
    ECRYPTFS_NEW_FILE flag is no longer needed. It helped
    ecryptfs_readpage() know not to decrypt zeroes that were read from the
    lower file in the grow_file() path.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     

18 Jan, 2011

2 commits


22 May, 2010

2 commits


20 Apr, 2010

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6:
    eCryptfs: Turn lower lookup error messages into debug messages
    eCryptfs: Copy lower directory inode times and size on link
    ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode
    ecryptfs: fix error code for missing xattrs in lower fs
    eCryptfs: Decrypt symlink target for stat size
    eCryptfs: Strip metadata in xattr flag in encrypted view
    eCryptfs: Clear buffer before reading in metadata xattr
    eCryptfs: Rename ecryptfs_crypt_stat.num_header_bytes_at_front
    eCryptfs: Fix metadata in xattr feature regression

    Linus Torvalds
     

30 Mar, 2010

1 commit

  • …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
     

24 Mar, 2010

3 commits

  • The ecryptfs_encrypted_view mount option provides a unified way of
    viewing encrypted eCryptfs files. If the metadata is stored in a xattr,
    the metadata is moved to the file header when the file is read inside
    the eCryptfs mount. Because of this, we should strip the
    ECRYPTFS_METADATA_IN_XATTR flag from the header's flag section. This
    allows eCryptfs to treat the file as an eCryptfs file with a header
    at the front.

    Reviewed-by: Eric Sandeen
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • This patch renames the num_header_bytes_at_front variable to
    metadata_size since it now contains the max size of the metadata.

    Reviewed-by: Eric Sandeen
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • Fixes regression in 8faece5f906725c10e7a1f6caf84452abadbdc7b

    When using the ecryptfs_xattr_metadata mount option, eCryptfs stores the
    metadata (normally stored at the front of the file) in the user.ecryptfs
    xattr. This causes ecryptfs_crypt_stat.num_header_bytes_at_front to be
    0, since there is no header data at the front of the file. This results
    in too much memory being requested and ENOMEM being returned from
    ecryptfs_write_metadata().

    This patch fixes the problem by using the num_header_bytes_at_front
    variable for specifying the max size of the metadata, despite whether it
    is stored in the header or xattr.

    Reviewed-by: Eric Sandeen
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     

23 Sep, 2009

1 commit

  • Errors returned from vfs_read() and vfs_write() calls to the lower
    filesystem were being masked as -EINVAL. This caused some confusion to
    users who saw EINVAL instead of ENOSPC when the disk was full, for
    instance.

    Also, the actual bytes read or written were not accessible by callers to
    ecryptfs_read_lower() and ecryptfs_write_lower(), which may be useful in
    some cases. This patch updates the error handling logic where those
    functions are called in order to accept positive return codes indicating
    success.

    Cc: Eric Sandeen
    Acked-by: Serge Hallyn
    Cc: ecryptfs-devel@lists.launchpad.net
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     

22 Sep, 2009

1 commit


22 Apr, 2009

1 commit

  • ecryptfs_passthrough is a mount option that allows eCryptfs to allow
    data to be written to non-eCryptfs files in the lower filesystem. The
    passthrough option was causing data corruption due to it not always
    being treated as a non-eCryptfs file.

    The first 8 bytes of an eCryptfs file contains the decrypted file size.
    This value was being written to the non-eCryptfs files, too. Also,
    extra 0x00 characters were being written to make the file size a
    multiple of PAGE_CACHE_SIZE.

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     

05 Jan, 2009

1 commit

  • With the write_begin/write_end aops, page_symlink was broken because it
    could no longer pass a GFP_NOFS type mask into the point where the
    allocations happened. They are done in write_begin, which would always
    assume that the filesystem can be entered from reclaim. This bug could
    cause filesystem deadlocks.

    The funny thing with having a gfp_t mask there is that it doesn't really
    allow the caller to arbitrarily tinker with the context in which it can be
    called. It couldn't ever be GFP_ATOMIC, for example, because it needs to
    take the page lock. The only thing any callers care about is __GFP_FS
    anyway, so turn that into a single flag.

    Add a new flag for write_begin, AOP_FLAG_NOFS. Filesystems can now act on
    this flag in their write_begin function. Change __grab_cache_page to
    accept a nofs argument as well, to honour that flag (while we're there,
    change the name to grab_cache_page_write_begin which is more instructive
    and does away with random leading underscores).

    This is really a more flexible way to go in the end anyway -- if a
    filesystem happens to want any extra allocations aside from the pagecache
    ones in ints write_begin function, it may now use GFP_KERNEL (rather than
    GFP_NOFS) for common case allocations (eg. ocfs2_alloc_write_ctxt, for a
    random example).

    [kosaki.motohiro@jp.fujitsu.com: fix ubifs]
    [kosaki.motohiro@jp.fujitsu.com: fix fuse]
    Signed-off-by: Nick Piggin
    Reviewed-by: KOSAKI Motohiro
    Cc: [2.6.28.x]
    Signed-off-by: KOSAKI Motohiro
    Signed-off-by: Andrew Morton
    [ Cleaned up the calling convention: just pass in the AOP flags
    untouched to the grab_cache_page_write_begin() function. That
    just simplifies everybody, and may even allow future expansion of the
    logic. - Linus ]
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

17 Oct, 2008

1 commit


25 Jul, 2008

1 commit

  • Fixe sparse warnings:
    fs/ecryptfs/inode.c:368:15: warning: cast to restricted __be64
    fs/ecryptfs/mmap.c:385:12: warning: incorrect type in assignment (different base types)
    fs/ecryptfs/mmap.c:385:12: expected unsigned long long [unsigned] [assigned] [usertype] file_size
    fs/ecryptfs/mmap.c:385:12: got restricted __be64 [usertype]
    fs/ecryptfs/mmap.c:428:12: warning: incorrect type in assignment (different base types)
    fs/ecryptfs/mmap.c:428:12: expected unsigned long long [unsigned] [assigned] [usertype] file_size
    fs/ecryptfs/mmap.c:428:12: got restricted __be64 [usertype]

    Signed-off-by: Harvey Harrison
    Cc: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Harvey Harrison
     

29 Apr, 2008

1 commit


05 Mar, 2008

1 commit

  • When the page is not up to date, ecryptfs_prepare_write() should be
    acting much like ecryptfs_readpage(). This includes the painfully
    obvious step of actually decrypting the page contents read from the
    lower encrypted file.

    Note that this patch resolves a bug in eCryptfs in 2.6.24 that one can
    produce with these steps:

    # mount -t ecryptfs /secret /secret
    # echo "abc" > /secret/file.txt
    # umount /secret
    # mount -t ecryptfs /secret /secret
    # echo "def" >> /secret/file.txt
    # cat /secret/file.txt

    Without this patch, the resulting data returned from cat is likely to
    be something other than "abc\ndef\n".

    (Thanks to Benedikt Driessen for reporting this.)

    Signed-off-by: Michael Halcrow
    Cc: Benedikt Driessen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     

07 Feb, 2008

2 commits

  • Remove internal references to header extents; just keep track of header bytes
    instead. Headers can easily span multiple pages with the recent persistent
    file changes.

    Signed-off-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     
  • - make the following needlessly global code static:
    - crypto.c:ecryptfs_lower_offset_for_extent()
    - crypto.c:key_tfm_list
    - crypto.c:key_tfm_list_mutex
    - inode.c:ecryptfs_getxattr()
    - main.c:ecryptfs_init_persistent_file()

    - remove the no longer used mmap.c:ecryptfs_lower_page_cache

    - #if 0 the unused read_write.c:ecryptfs_read()

    Signed-off-by: Adrian Bunk
    Cc: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

06 Feb, 2008

1 commit

  • Simplify page cache zeroing of segments of pages through 3 functions

    zero_user_segments(page, start1, end1, start2, end2)

    Zeros two segments of the page. It takes the position where to
    start and end the zeroing which avoids length calculations and
    makes code clearer.

    zero_user_segment(page, start, end)

    Same for a single segment.

    zero_user(page, start, length)

    Length variant for the case where we know the length.

    We remove the zero_user_page macro. Issues:

    1. Its a macro. Inline functions are preferable.

    2. The KM_USER0 macro is only defined for HIGHMEM.

    Having to treat this special case everywhere makes the
    code needlessly complex. The parameter for zeroing is always
    KM_USER0 except in one single case that we open code.

    Avoiding KM_USER0 makes a lot of code not having to be dealing
    with the special casing for HIGHMEM anymore. Dealing with
    kmap is only necessary for HIGHMEM configurations. In those
    configurations we use KM_USER0 like we do for a series of other
    functions defined in highmem.h.

    Since KM_USER0 is depends on HIGHMEM the existing zero_user_page
    function could not be a macro. zero_user_* functions introduced
    here can be be inline because that constant is not used when these
    functions are called.

    Also extract the flushing of the caches to be outside of the kmap.

    [akpm@linux-foundation.org: fix nfs and ntfs build]
    [akpm@linux-foundation.org: fix ntfs build some more]
    Signed-off-by: Christoph Lameter
    Cc: Steven French
    Cc: Michael Halcrow
    Cc:
    Cc: Steven Whitehouse
    Cc: Trond Myklebust
    Cc: "J. Bruce Fields"
    Cc: Anton Altaparmakov
    Cc: Mark Fasheh
    Cc: David Chinner
    Cc: Michael Halcrow
    Cc: Steven French
    Cc: Steven Whitehouse
    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

18 Dec, 2007

1 commit

  • ecryptfs in 2.6.24-rc3 wasn't surviving fsx for me at all, dying after 4
    ops. Generally, encountering problems with stale data and improperly
    zeroed pages. An extending truncate + write for example would expose stale
    data.

    With the changes below I got to a million ops and beyond with all mmap ops
    disabled - mmap still needs work. (A version of this patch on a RHEL5
    kernel ran for over 110 million fsx ops)

    I added a few comments as well, to the best of my understanding
    as I read through the code.

    Signed-off-by: Eric Sandeen
    Acked-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sandeen