#
42c3732f |
|
30-Dec-2023 |
Chuck Lever <chuck.lever@oracle.com> |
fs: Create a generic is_dot_dotdot() utility De-duplicate the same functionality in several places by hoisting the is_dot_dotdot() utility function into linux/fs.h. Suggested-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
#
8b70deb8 |
|
26-Apr-2023 |
Fabio M. De Francesco <fmdefrancesco@gmail.com> |
fs/ecryptfs: Replace kmap() with kmap_local_page() kmap() has been deprecated in favor of kmap_local_page(). Therefore, replace kmap() with kmap_local_page() in fs/ecryptfs. There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. The tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid. Obviously, thread locality implies that the kernel virtual addresses returned by kmap_local_page() are only valid in the context of the callers (i.e., they cannot be handed to other threads). The use of kmap_local_page() in fs/ecryptfs does not break the above-mentioned assumption, so it is allowed and preferred. Tested in a QEMU/KVM x86_32 VM, 6GB RAM, booting a kernel with HIGHMEM64GB enabled. Suggested-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: "Fabio M. De Francesco" <fmdefrancesco@gmail.com> Message-Id: <20230426172223.8896-2-fmdefrancesco@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
|
#
20066bf7 |
|
06-Feb-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
fs: ecryptfs: Use crypto_wait_req This patch replaces the custom crypto completion function with crypto_req_done. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
39f60c1c |
|
12-Jan-2023 |
Christian Brauner <brauner@kernel.org> |
fs: port xattr to mnt_idmap Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
|
#
c6052f09 |
|
03-May-2021 |
Phillip Potter <phil@philpotter.co.uk> |
fs: ecryptfs: remove BUG_ON from crypt_scatterlist crypt_stat memory itself is allocated when inode is created, in ecryptfs_alloc_inode, which returns NULL on failure and is handled by callers, which would prevent us getting to this point. It then calls ecryptfs_init_crypt_stat which allocates crypt_stat->tfm checking for and likewise handling allocation failure. Finally, crypt_stat->flags has ECRYPTFS_STRUCT_INITIALIZED merged into it in ecryptfs_init_crypt_stat as well. Simply put, the conditions that the BUG_ON checks for will never be triggered, as to even get to this function, the relevant conditions will have already been fulfilled (or the inode allocation would fail in the first place and thus no call to this function or those above it). Cc: Tyler Hicks <code@tyhicks.com> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210503115736.2104747-50-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
e1436df2 |
|
03-May-2021 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "ecryptfs: replace BUG_ON with error handling code" This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit log for this change was incorrect, no "error handling code" was added, things will blow up just as badly as before if any of these cases ever were true. As this BUG_ON() never fired, and most of these checks are "obviously" never going to be true, let's just revert to the original code for now until this gets unwound to be done correctly in the future. Cc: Aditya Pakki <pakki001@umn.edu> Fixes: 2c2a7552dd64 ("ecryptfs: replace BUG_ON with error handling code") Cc: stable <stable@vger.kernel.org> Acked-by: Tyler Hicks <code@tyhicks.com> Link: https://lore.kernel.org/r/20210503115736.2104747-49-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1abbe110 |
|
23-Feb-2021 |
Sascha Hauer <s.hauer@pengutronix.de> |
ecryptfs: Fix typo in message ecryptfs_decrypt_page() issues a warning "Error encrypting extent". This should be "Error decrypting extent" instead. Fixes: 0216f7f79217 ("eCryptfs: replace encrypt, decrypt, and inode size write") Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
|
#
5da877ea |
|
30-Mar-2021 |
Lee Jones <lee.jones@linaro.org> |
ecryptfs: crypto: Supply some missing param descriptions and demote abuses Fixes the following W=1 kernel build warning(s): fs/ecryptfs/crypto.c:29: warning: expecting prototype for eCryptfs(). Prototype was for DECRYPT() instead fs/ecryptfs/crypto.c:360: warning: Function parameter or member 'crypt_stat' not described in 'lower_offset_for_page' fs/ecryptfs/crypto.c:360: warning: Function parameter or member 'page' not described in 'lower_offset_for_page' fs/ecryptfs/crypto.c:637: warning: Function parameter or member 'crypt_stat' not described in 'ecryptfs_compute_root_iv' fs/ecryptfs/crypto.c:1386: warning: Function parameter or member 'ecryptfs_dentry' not described in 'ecryptfs_read_metadata' fs/ecryptfs/crypto.c:1463: warning: Function parameter or member 'filename' not described in 'ecryptfs_encrypt_filename' fs/ecryptfs/crypto.c:1463: warning: Function parameter or member 'mount_crypt_stat' not described in 'ecryptfs_encrypt_filename' fs/ecryptfs/crypto.c:1897: warning: Function parameter or member 'encoded_name_size' not described in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Function parameter or member 'mount_crypt_stat' not described in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Function parameter or member 'name_size' not described in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Excess function parameter 'crypt_stat' description in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:1897: warning: Excess function parameter 'length' description in 'ecryptfs_encrypt_and_encode_filename' fs/ecryptfs/crypto.c:2006: warning: Function parameter or member 'sb' not described in 'ecryptfs_decode_and_decrypt_filename' fs/ecryptfs/crypto.c:2006: warning: Excess function parameter 'ecryptfs_dir_dentry' description in 'ecryptfs_decode_and_decrypt_filename' Cc: Tyler Hicks <code@tyhicks.com> Cc: Eric Biggers <ebiggers@google.com> Cc: "Michael A. Halcrow" <mahalcro@us.ibm.com> Cc: "Michael C. Thompson" <mcthomps@us.ibm.com> Cc: ecryptfs@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> [tyhicks: Fix typo in ecryptfs_encrypt_and_encode_filename() func docs] Signed-off-by: Tyler Hicks <code@tyhicks.com>
|
#
902af369 |
|
24-Dec-2020 |
Zheng Yongjun <zhengyongjun3@huawei.com> |
ecryptfs: use DEFINE_MUTEX() for mutex lock mutex lock can be initialized automatically with DEFINE_MUTEX() rather than explicitly calling mutex_init(). Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Tyler Hicks <code@tyhicks.com>
|
#
c7c7a1a1 |
|
21-Jan-2021 |
Tycho Andersen <tycho@tycho.pizza> |
xattr: handle idmapped mounts When interacting with extended attributes the vfs verifies that the caller is privileged over the inode with which the extended attribute is associated. For posix access and posix default extended attributes a uid or gid can be stored on-disk. Let the functions handle posix extended attributes on idmapped mounts. If the inode is accessed through an idmapped mount we need to map it according to the mount's user namespace. Afterwards the checks are identical to non-idmapped mounts. This has no effect for e.g. security xattrs since they don't store uids or gids and don't perform permission checks on them like posix acls do. Link: https://lore.kernel.org/r/20210121131959.646623-10-christian.brauner@ubuntu.com Cc: Christoph Hellwig <hch@lst.de> Cc: David Howells <dhowells@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: James Morris <jamorris@linux.microsoft.com> Signed-off-by: Tycho Andersen <tycho@tycho.pizza> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
|
#
19798113 |
|
01-May-2020 |
Eric Biggers <ebiggers@google.com> |
ecryptfs: use crypto_shash_tfm_digest() Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: ecryptfs@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
2c2a7552 |
|
13-Feb-2020 |
Aditya Pakki <pakki001@umn.edu> |
ecryptfs: replace BUG_ON with error handling code In crypt_scatterlist, if the crypt_stat argument is not set up correctly, the kernel crashes. Instead, by returning an error code upstream, the error is handled safely. The issue is detected via a static analysis tool written by us. Fixes: 237fead619984 (ecryptfs: fs/Makefile and fs/Kconfig) Signed-off-by: Aditya Pakki <pakki001@umn.edu> Signed-off-by: Tyler Hicks <code@tyhicks.com>
|
#
9ac0d136 |
|
29-Nov-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: skcipher - remove crypto_skcipher::keysize Due to the removal of the blkcipher and ablkcipher algorithm types, crypto_skcipher::keysize is now redundant since it always equals crypto_skcipher_alg(tfm)->max_keysize. Remove it and update crypto_skcipher_default_keysize() accordingly. Also rename crypto_skcipher_default_keysize() to crypto_skcipher_max_keysize() to clarify that it specifically returns the maximum key size, not some unspecified "default". Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
7451c54a |
|
02-Jul-2019 |
Hariprasad Kelam <hariprasad.kelam@gmail.com> |
ecryptfs: Change return type of ecryptfs_process_flags Change return type of ecryptfs_process_flags from int to void as it never fails. fixes below issue reported by coccicheck s/ecryptfs/crypto.c:870:5-7: Unneeded variable: "rc". Return "0" on line 883 Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com> [tyhicks: Remove the return value line from the function documentation] Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
1a59d1b8 |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156 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 <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
877b5691 |
|
14-Apr-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: shash - remove shash_desc::flags The flags field in 'struct shash_desc' never actually does anything. The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP. However, no shash algorithm ever sleeps, making this flag a no-op. With this being the case, inevitably some users who can't sleep wrongly pass MAY_SLEEP. These would all need to be fixed if any shash algorithm actually started sleeping. For example, the shash_ahash_*() functions, which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP from the ahash API to the shash API. However, the shash functions are called under kmap_atomic(), so actually they're assumed to never sleep. Even if it turns out that some users do need preemption points while hashing large buffers, we could easily provide a helper function crypto_shash_update_large() which divides the data into smaller chunks and calls crypto_shash_update() and cond_resched() for each chunk. It's not necessary to have a flag in 'struct shash_desc', nor is it necessary to make individual shash algorithms aware of this at all. Therefore, remove shash_desc::flags, and document that the crypto_shash_*() functions can be called from any context. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
d43388de |
|
21-Aug-2018 |
Robbie Ko <robbieko@synology.com> |
eCryptfs: fix permission denied with ecryptfs_xattr mount option when create readonly file When the ecryptfs_xattr mount option is turned on, the ecryptfs metadata will be written to xattr via vfs_setxattr, which will check the WRITE permissions. However, this will cause denial of permission when creating a file withoug write permission. So fix this by calling __vfs_setxattr directly to skip permission check. Signed-off-by: Robbie Ko <robbieko@synology.com> [tyhicks: Copy up lower inode attributes when successful] Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
0bdf8a82 |
|
03-Jul-2018 |
Dan Carpenter <dan.carpenter@oracle.com> |
eCryptfs: fix a couple type promotion bugs ECRYPTFS_SIZE_AND_MARKER_BYTES is type size_t, so if "rc" is negative that gets type promoted to a high positive value and treated as success. Fixes: 778aeb42a708 ("eCryptfs: Cleanup and optimize ecryptfs_lookup_interpose()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> [tyhicks: Use "if/else if" rather than "if/if"] Cc: stable@vger.kernel.org Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
231baecd |
|
18-Jan-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: clarify name of WEAK_KEY request flag CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak keys be forbidden (for algorithms that have the notion of "weak keys"; currently only DES and XTS do). Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which it can be easily confused. (This in fact happened in the UX500 driver, though just in some debugging messages.) Therefore, make the intent clear by renaming it to CRYPTO_TFM_REQ_FORBID_WEAK_KEYS. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
e86281e7 |
|
28-Mar-2018 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: don't pass up plaintext names when using filename encryption Both ecryptfs_filldir() and ecryptfs_readlink_lower() use ecryptfs_decode_and_decrypt_filename() to translate lower filenames to upper filenames. The function correctly passes up lower filenames, unchanged, when filename encryption isn't in use. However, it was also passing up lower filenames when the filename wasn't encrypted or when decryption failed. Since 88ae4ab9802e, eCryptfs refuses to lookup lower plaintext names when filename encryption is enabled so this resulted in a situation where userspace would see lower plaintext filenames in calls to getdents(2) but then not be able to lookup those filenames. An example of this can be seen when enabling filename encryption on an eCryptfs mount at the root directory of an Ext4 filesystem: $ ls -1i /lower 12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE-- 11 lost+found $ ls -1i /upper ls: cannot access '/upper/lost+found': No such file or directory ? lost+found 12 test With this change, the lower lost+found dentry is ignored: $ ls -1i /lower 12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE-- 11 lost+found $ ls -1i /upper 12 test Additionally, some potentially noisy error/info messages in the related code paths are turned into debug messages so that the logs can't be easily filled. Fixes: 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext name") Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
02f9876e |
|
01-Oct-2017 |
Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> |
ecryptfs: use ARRAY_SIZE Using the ARRAY_SIZE macro improves the readability of the code. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p /sizeof(T)) ) Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
5032f360 |
|
19-Aug-2017 |
Markus Elfring <elfring@users.sourceforge.net> |
ecryptfs: Adjust four checks for null pointers The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written … Thus fix the affected source code places. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
1a0bba4f |
|
19-Aug-2017 |
Markus Elfring <elfring@users.sourceforge.net> |
ecryptfs: Delete 21 error messages for a failed memory allocation Omit extra messages for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
abbae6d5 |
|
20-Sep-2016 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
ecryptfs: remove private bin2hex implementation Calling sprintf in a loop is not very efficient, and in any case, we already have an implementation of bin-to-hex conversion in lib/ which we might as well use. Note that ecryptfs_to_hex used to nul-terminate the destination (and the kernel doc was wrong about the required output size), while bin2hex doesn't. [All but one user of ecryptfs_to_hex explicitly nul-terminates the result anyway.] Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> [tyhicks: Include <linux/kernel.h> in ecryptfs_kernel.h] Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
40f0fd37 |
|
09-Jun-2016 |
Chris J Arges <chris.j.arges@canonical.com> |
ecryptfs: fix spelling mistakes Noticed some minor spelling errors when looking through the code. Signed-off-by: Chris J Arges <chris.j.arges@canonical.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
5f9f2c2a |
|
16-Feb-2016 |
Wei Yuan <weiyuan.wei@huawei.com> |
eCryptfs: fix typos in comment Signed-off-by: Weiyuan <weiyuan.wei@huawei.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
3767e255 |
|
27-May-2016 |
Al Viro <viro@zeniv.linux.org.uk> |
switch ->setxattr() to passing dentry and inode separately 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 <sw0312.kim@samsung.com> Tested-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
e81f3340 |
|
16-Apr-2016 |
Herbert Xu <herbert@gondor.apana.org.au> |
eCryptfs: Do not allocate hash tfm in NORECLAIM context You cannot allocate crypto tfm objects in NORECLAIM or NOFS contexts. The ecryptfs code currently does exactly that for the MD5 tfm. This patch fixes it by preallocating the MD5 tfm in a safe context. The MD5 tfm is also reentrant so this patch removes the superfluous cs_hash_tfm_mutex. Reported-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
ce23e640 |
|
10-Apr-2016 |
Al Viro <viro@zeniv.linux.org.uk> |
->getxattr(): pass dentry and inode as separate arguments Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
09cbfeaf |
|
01-Apr-2016 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros 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: - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - 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 <kirill.shutemov@linux.intel.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
97c31606 |
|
22-Feb-2016 |
Al Viro <viro@zeniv.linux.org.uk> |
ecryptfs_encrypt_and_encode_filename(): drop unused argument the last time it was getting something other than NULL as crypt_stat had been back in 2009... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
3095e8e3 |
|
24-Jan-2016 |
Herbert Xu <herbert@gondor.apana.org.au> |
eCryptfs: Use skcipher and shash This patch replaces uses of ablkcipher and blkcipher with skcipher, and the long obsolete hash interface with shash. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
0dad87fc |
|
26-Jun-2015 |
Markus Elfring <elfring@users.sourceforge.net> |
eCryptfs: Delete a check before the function call "key_put" The key_put() function tests whether its argument is NULL and then returns immediately. Thus the test around this call might not be needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
2b0143b5 |
|
17-Mar-2015 |
David Howells <dhowells@redhat.com> |
VFS: normal filesystems (and lustre): d_inode() annotations that's the bulk of filesystem drivers dealing with inodes of their own Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
94208064 |
|
26-Nov-2014 |
Michael Halcrow <mhalcrow@google.com> |
eCryptfs: Remove buggy and unnecessary write in file name decode routine Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the end of the allocated buffer during encrypted filename decoding. This fix corrects the issue by getting rid of the unnecessary 0 write when the current bit offset is 2. Signed-off-by: Michael Halcrow <mhalcrow@google.com> Reported-by: Dmitry Chernenkov <dmitryc@google.com> Suggested-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
b583043e |
|
30-Oct-2014 |
Al Viro <viro@zeniv.linux.org.uk> |
kill f_dentry uses Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
16735d02 |
|
14-Nov-2013 |
Wolfram Sang <wsa@kernel.org> |
tree-wide: use reinit_completion instead of INIT_COMPLETION Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. [akpm@linux-foundation.org: linux-next resyncs] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
43b7c6c6 |
|
24-Oct-2013 |
Colin Ian King <colin.king@canonical.com> |
eCryptfs: fix 32 bit corruption issue Shifting page->index on 32 bit systems was overflowing, causing data corruption of > 4GB files. Fix this by casting it first. https://launchpad.net/bugs/1243636 Signed-off-by: Colin Ian King <colin.king@canonical.com> Reported-by: Lars Duesing <lars.duesing@camelotsweb.de> Cc: stable@vger.kernel.org # v3.11+ Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
cb69f36b |
|
13-Aug-2013 |
Kees Cook <keescook@chromium.org> |
ecryptfs: avoid ctx initialization race It might be possible for two callers to race the mutex lock after the NULL ctx check. Instead, move the lock above the check so there isn't the possibility of leaking a crypto ctx. Additionally, report the full algo name when failing. Signed-off-by: Kees Cook <keescook@chromium.org> [tyhicks: remove out label, which is no longer used] Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
e6cbd6a4 |
|
30-Jul-2013 |
Dan Carpenter <dan.carpenter@oracle.com> |
ecryptfs: remove check for if an array is NULL It doesn't make sense to check if an array is NULL. The compiler just removes the check. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
0747fdb2 |
|
16-Jun-2013 |
Al Viro <viro@zeniv.linux.org.uk> |
ecryptfs: switch ecryptfs_decode_and_decrypt_filename() from dentry to sb Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
0df5ed65 |
|
23-May-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Make extent and scatterlist crypt function parameters similar The 'dest' abbreviation is only used in crypt_scatterlist(), while all other functions in crypto.c use 'dst' so dest_sg should be renamed to dst_sg. The crypt_stat parameter is typically the first parameter in internal eCryptfs functions so crypt_stat and dst_page should be swapped in crypt_extent(). Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
406c93df |
|
15-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Collapse crypt_page_offset() into crypt_extent() crypt_page_offset() simply initialized the two scatterlists and called crypt_scatterlist() so it is simple enough to move into the only function that calls it. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
d78de618 |
|
06-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Merge ecryptfs_encrypt_extent() and ecryptfs_decrypt_extent() They are identical except if the src_page or dst_page index is used, so they can be merged safely if page_index is conditionally assigned. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
a8ca90e2 |
|
06-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Combine page_offset crypto functions Combine ecryptfs_encrypt_page_offset() and ecryptfs_decrypt_page_offset(). These two functions are functionally identical so they can be safely merged if the caller can indicate whether an encryption or decryption operation should occur. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
00a69940 |
|
06-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Combine encrypt_scatterlist() and decrypt_scatterlist() These two functions are identical except for a debug printk and whether they call crypto_ablkcipher_encrypt() or crypto_ablkcipher_decrypt(), so they can be safely merged if the caller can indicate if encryption or decryption should occur. The debug printk is useless so it is removed. Two new #define's are created to indicate if an ENCRYPT or DECRYPT operation is desired. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
9c6043f4 |
|
06-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Decrypt pages in-place When reading in a page, eCryptfs would allocate a helper page, fill it with encrypted data from the lower filesytem, and then decrypt the data from the encrypted page and store the result in the eCryptfs page cache page. The crypto API supports in-place crypto operations which means that the allocation of the helper page is unnecessary when decrypting. This patch gets rid of the unneeded page allocation by reading encrypted data from the lower filesystem directly into the page cache page. The page cache page is then decrypted in-place. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
28916d1a |
|
15-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Accept one offset parameter in page offset crypto functions There is no longer a need to accept different offset values for the source and destination pages when encrypting/decrypting an extent in an eCryptfs page. The two offsets can be collapsed into a single parameter. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
24d15266 |
|
15-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Simplify lower file offset calculation Now that lower filesystem IO operations occur for complete PAGE_CACHE_SIZE bytes, the calculation for converting an eCryptfs extent index into a lower file offset can be simplified. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
0f896176 |
|
15-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Read/write entire page during page IO When reading and writing encrypted pages, perform IO using the entire page all at once rather than 4096 bytes at a time. This only affects architectures where PAGE_CACHE_SIZE is larger than 4096 bytes. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
12003e5b |
|
17-Apr-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Use entire helper page during page crypto operations When encrypting eCryptfs pages and decrypting pages from the lower filesystem, utilize the entire helper page rather than only the first 4096 bytes. This only affects architectures where PAGE_CACHE_SIZE is larger than 4096 bytes. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
4dfea4f0 |
|
09-May-2013 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Use the ablkcipher crypto API Make the switch from the blkcipher kernel crypto interface to the ablkcipher interface. encrypt_scatterlist() and decrypt_scatterlist() now use the ablkcipher interface but, from the eCryptfs standpoint, still treat the crypto operation as a synchronous operation. They submit the async request and then wait until the operation is finished before they return. Most of the changes are contained inside those two functions. Despite waiting for the completion of the crypto operation, the ablkcipher interface provides performance increases in most cases when used on AES-NI capable hardware. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Reviewed-by: Zeev Zilberman <zeev@annapurnaLabs.com> Cc: Dustin Kirkland <dustin.kirkland@gazzang.com> Cc: Tim Chen <tim.c.chen@intel.com> Cc: Ying Huang <ying.huang@intel.com> Cc: Thieu Le <thieule@google.com> Cc: Li Wang <dragonylffly@163.com> Cc: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
|
#
a07c48ad |
|
26-Jan-2013 |
Dan Carpenter <dan.carpenter@oracle.com> |
eCryptfs: remove unneeded checks in virt_to_scatterlist() This is always called with a valid "sg" pointer. My static checker complains because the call to sg_init_table() dereferences "sg" before we reach the checks. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
37028758 |
|
07-Dec-2012 |
Cong Ding <dinggnu@gmail.com> |
fs/ecryptfs/crypto.c: make ecryptfs_encode_for_filename() static the function ecryptfs_encode_for_filename() is only used in this file Signed-off-by: Cong Ding <dinggnu@gmail.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
4a26620d |
|
05-Nov-2011 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Improve statfs reporting statfs() calls on eCryptfs files returned the wrong filesystem type and, when using filename encryption, the wrong maximum filename length. If mount-wide filename encryption is enabled, the cipher block size and the lower filesystem's max filename length will determine the max eCryptfs filename length. Pre-tested, known good lengths are used when the lower filesystem's namelen is 255 and a cipher with 8 or 16 byte block sizes is used. In other, less common cases, we fall back to a safe rounded-down estimate when determining the eCryptfs namelen. https://launchpad.net/bugs/885744 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: John Johansen <john.johansen@canonical.com>
|
#
58ded24f |
|
24-Jan-2012 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Fix oops when printing debug info in extent crypto functions If pages passed to the eCryptfs extent-based crypto functions are not mapped and the module parameter ecryptfs_verbosity=1 was specified at loading time, a NULL pointer dereference will occur. Note that this wouldn't happen on a production system, as you wouldn't pass ecryptfs_verbosity=1 on a production system. It leaks private information to the system logs and is for debugging only. The debugging info printed in these messages is no longer very useful and rather than doing a kmap() in these debugging paths, it will be better to simply remove the debugging paths completely. https://launchpad.net/bugs/913651 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Daniel DeFreez Cc: <stable@vger.kernel.org>
|
#
bb450361 |
|
12-Jan-2012 |
Tim Gardner <tim.gardner@canonical.com> |
ecryptfs: Remove unnecessary variable initialization Removes unneeded variable initialization in ecryptfs_read_metadata(). Also adds a small comment to help explain metadata reading logic. [tyhicks@canonical.com: Pulled out of for-stable patch and wrote commit msg] Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
30373dc0 |
|
12-Jan-2012 |
Tim Gardner <tim.gardner@canonical.com> |
ecryptfs: Improve metadata read failure logging Print inode on metadata read failure. The only real way of dealing with metadata read failures is to delete the underlying file system file. Having the inode allows one to 'find . -inum INODE`. [tyhicks@canonical.com: Removed some minor not-for-stable parts] Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
|
#
0f751e64 |
|
23-Nov-2011 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Extend array bounds for all filename chars From mhalcrow's original commit message: Characters with ASCII values greater than the size of filename_rev_map[] are valid filename characters. ecryptfs_decode_from_filename() will access kernel memory beyond that array, and ecryptfs_parse_tag_70_packet() will then decrypt those characters. The attacker, using the FNEK of the crafted file, can then re-encrypt the characters to reveal the kernel memory past the end of the filename_rev_map[] array. I expect low security impact since this array is statically allocated in the text area, and the amount of memory past the array that is accessible is limited by the largest possible ASCII filename character. This patch solves the issue reported by mhalcrow but with an implementation suggested by Linus to simply extend the length of filename_rev_map[] to 256. Characters greater than 0x7A are mapped to 0x00, which is how invalid characters less than 0x7A were previously being handled. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Michael Halcrow <mhalcrow@google.com> Cc: stable@kernel.org
|
#
b59db43a |
|
21-Nov-2011 |
Tyler Hicks <tyhicks@canonical.com> |
eCryptfs: Prevent file create race condition The file creation path prematurely called d_instantiate() and unlock_new_inode() before the eCryptfs inode info was fully allocated and initialized and before the eCryptfs metadata was written to the lower file. This could result in race conditions in subsequent file and inode operations leading to unexpected error conditions or a null pointer dereference while attempting to use the unallocated memory. https://launchpad.net/bugs/813146 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Cc: stable@kernel.org
|
#
30632870 |
|
24-May-2011 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Remove ecryptfs_header_cache_2 Now that ecryptfs_lookup_interpose() is no longer using ecryptfs_header_cache_2 to read in metadata, the kmem_cache can be removed and the ecryptfs_header_cache_1 kmem_cache can be renamed to ecryptfs_header_cache. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
778aeb42 |
|
24-May-2011 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Cleanup and optimize ecryptfs_lookup_interpose() ecryptfs_lookup_interpose() has turned into spaghetti code over the years. This is an effort to clean it up. - Shorten overly descriptive variable names such as ecryptfs_dentry - Simplify gotos and error paths - Create helper function for reading plaintext i_size from metadata It also includes an optimization when reading i_size from the metadata. A complete page-sized kmem_cache_alloc() was being done to read in 16 bytes of metadata. The buffer for that is now statically declared. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
7a86617e |
|
01-May-2011 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Return useful code from contains_ecryptfs_marker Instead of having the calling functions translate the true/false return code to either 0 or -EINVAL, have contains_ecryptfs_marker() return 0 or -EINVAL so that the calling functions can just reuse the return code. Also, rename the function to ecryptfs_validate_marker() to avoid callers mistakenly thinking that it returns true/false codes. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
3b06b3eb |
|
24-May-2011 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Fix new inode race condition Only unlock and d_add() new inodes after the plaintext inode size has been read from the lower filesystem. This fixes a race condition that was sometimes seen during a multi-job kernel build in an eCryptfs mount. https://bugzilla.kernel.org/show_bug.cgi?id=36002 Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Reported-by: David <david@unsolicited.net> Tested-by: David <david@unsolicited.net>
|
#
3aeb86ea |
|
15-Mar-2011 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Handle failed metadata read in lookup When failing to read the lower file's crypto metadata during a lookup, eCryptfs must continue on without throwing an error. For example, there may be a plaintext file in the lower mount point that the user wants to delete through the eCryptfs mount. If an error is encountered while reading the metadata in lookup(), the eCryptfs inode's size could be incorrect. We must be sure to reread the plaintext inode size from the metadata when performing an open() or setattr(). The metadata is already being read in those paths, so this adds minimal performance overhead. This patch introduces a flag which will track whether or not the plaintext inode size has been read so that an incorrect i_size can be fixed in the open() or setattr() paths. https://bugs.launchpad.net/bugs/509180 Cc: <stable@kernel.org> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
cf35ca69 |
|
21-Mar-2011 |
Roberto Sassu <roberto.sassu@polito.it> |
eCryptfs: removed num_global_auth_toks from ecryptfs_mount_crypt_stat This patch removes the 'num_global_auth_toks' field of the ecryptfs_mount_crypt_stat structure, used to count the number of items in the 'global_auth_tok_list' list. This variable is not needed because there are no checks based upon it. Signed-off-by: Roberto Sassu <roberto.sassu@polito.it> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
bd4f0fe8 |
|
22-Feb-2011 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Remove unnecessary grow_file() function When creating a new eCryptfs file, the crypto metadata is written out and then the lower file was being "grown" with 4 kB of encrypted zeroes. I suspect that growing the encrypted file was to prevent an information leak that the unencrypted file was empty. However, the unencrypted file size is stored, in plaintext, in the metadata so growing the file is unnecessary. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
f24b3887 |
|
15-Nov-2010 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
ecryptfs: Fix ecryptfs_printk() size_t warnings Commit cb55d21f6fa19d8c6c2680d90317ce88c1f57269 revealed a number of missing 'z' length modifiers in calls to ecryptfs_printk() when printing variables of type size_t. This patch fixes those compiler warnings. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
888d57bb |
|
10-Nov-2010 |
Joe Perches <joe@perches.com> |
fs/ecryptfs: Add printf format/argument verification and fix fallout Add __attribute__((format... to __ecryptfs_printk Make formats and arguments match. Add casts to (unsigned long long) for %llu. Signed-off-by: Joe Perches <joe@perches.com> [tyhicks: 80 columns cleanup and fixed typo] Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
93c3fe40 |
|
25-Aug-2010 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Fix encrypted file name lookup regression Fixes a regression caused by 21edad32205e97dc7ccb81a85234c77e760364c8 When file name encryption was enabled, ecryptfs_lookup() failed to use the encrypted and encoded version of the upper, plaintext, file name when performing a lookup in the lower file system. This made it impossible to lookup existing encrypted file names and any newly created files would have plaintext file names in the lower file system. https://bugs.launchpad.net/ecryptfs/+bug/623087 Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
7371a382 |
|
17-Aug-2010 |
Jerome Marchand <jmarchan@redhat.com> |
ecryptfs: properly mark init functions Some ecryptfs init functions are not prefixed by __init and thus not freed after initialization. This patch saved about 1kB in ecryptfs module. Signed-off-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
421f91d2 |
|
10-Jun-2010 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
fix typos concerning "initiali[zs]e" Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit 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>
|
#
f4e60e6b |
|
10-Feb-2010 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Strip metadata in xattr flag in encrypted view 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 <sandeen@redhat.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
1984c23f |
|
10-Feb-2010 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Clear buffer before reading in metadata xattr We initially read in the first PAGE_CACHE_SIZE of a file to if the eCryptfs header marker can be found. If it isn't found and ecryptfs_xattr_metadata was given as a mount option, then the user.ecryptfs xattr is read into the same buffer. Since the data from the first page of the file wasn't cleared, it is possible that we think we've found a second tag 3 or tag 1 packet and then error out after the packet contents aren't as expected. This patch clears the buffer before filling it with metadata from the user.ecryptfs xattr. Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
fa3ef1cb |
|
11-Feb-2010 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Rename ecryptfs_crypt_stat.num_header_bytes_at_front 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 <sandeen@redhat.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
157f1071 |
|
11-Feb-2010 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Fix metadata in xattr feature regression 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 <sandeen@redhat.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
ece550f5 |
|
18-Jan-2010 |
Dan Carpenter <error27@gmail.com> |
ecryptfs: use after free The "full_alg_name" variable is used on a couple error paths, so we shouldn't free it until the end. Signed-off-by: Dan Carpenter <error27@gmail.com> Cc: stable@kernel.org Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
96a7b9c2 |
|
16-Sep-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Propagate vfs_read and vfs_write return codes 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 <esandeen@redhat.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Cc: ecryptfs-devel@lists.launchpad.net Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
df6ad33b |
|
21-Aug-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Filename encryption only supports password auth tokens Returns -ENOTSUPP when attempting to use filename encryption with something other than a password authentication token, such as a private token from openssl. Using filename encryption with a userspace eCryptfs key module is a future goal. Until then, this patch handles the situation a little better than simply using a BUG_ON(). Acked-by: Serge Hallyn <serue@us.ibm.com> Cc: ecryptfs-devel@lists.launchpad.net Cc: stable <stable@kernel.org> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
b0105eae |
|
10-Aug-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Handle unrecognized tag 3 cipher codes Returns an error when an unrecognized cipher code is present in a tag 3 packet or an ecryptfs_crypt_stat cannot be initialized. Also sets an crypt_stat->tfm error pointer to NULL to ensure that it will not be incorrectly freed in ecryptfs_destroy_crypt_stat(). Acked-by: Serge Hallyn <serue@us.ibm.com> Cc: ecryptfs-devel@lists.launchpad.net Cc: stable <stable@kernel.org> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
38268498 |
|
27-Aug-2009 |
Dave Hansen <dave@linux.vnet.ibm.com> |
ecryptfs: improved dependency checking and reporting So, I compiled a 2.6.31-rc5 kernel with ecryptfs and loaded its module. When it came time to mount my filesystem, I got this in dmesg, and it refused to mount: [93577.776637] Unable to allocate crypto cipher with name [aes]; rc = [-2] [93577.783280] Error attempting to initialize key TFM cipher with name = [aes]; rc = [-2] [93577.791183] Error attempting to initialize cipher with name = [aes] and key size = [32]; rc = [-2] [93577.800113] Error parsing options; rc = [-22] I figured from the error message that I'd either forgotten to load "aes" or that my key size was bogus. Neither one of those was the case. In fact, I was missing the CRYPTO_ECB config option and the 'ecb' module. Unfortunately, there's no trace of 'ecb' in that error message. I've done two things to fix this. First, I've modified ecryptfs's Kconfig entry to select CRYPTO_ECB and CRYPTO_CBC. I also took CRYPTO out of the dependencies since the 'select' will take care of it for us. I've also modified the error messages to print a string that should contain both 'ecb' and 'aes' in my error case. That will give any future users a chance of finding the right modules and Kconfig options. I also wonder if we should: select CRYPTO_AES if !EMBEDDED since I think most ecryptfs users are using AES like me. Cc: ecryptfs-devel@lists.launchpad.net Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Dustin Kirkland <kirkland@canonical.com> Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com> [tyhicks@linux.vnet.ibm.com: Removed extra newline, 80-char violation] Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
aa06117f |
|
01-Jul-2009 |
Roland Dreier <rdreier@cisco.com> |
eCryptfs: Fix lockdep-reported AB-BA mutex issue Lockdep reports the following valid-looking possible AB-BA deadlock with global_auth_tok_list_mutex and keysig_list_mutex: ecryptfs_new_file_context() -> ecryptfs_copy_mount_wide_sigs_to_inode_sigs() -> mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex); -> ecryptfs_add_keysig() -> mutex_lock(&crypt_stat->keysig_list_mutex); vs ecryptfs_generate_key_packet_set() -> mutex_lock(&crypt_stat->keysig_list_mutex); -> ecryptfs_find_global_auth_tok_for_sig() -> mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex); ie the two mutexes are taken in opposite orders in the two different code paths. I'm not sure if this is a real bug where two threads could actually hit the two paths in parallel and deadlock, but it at least makes lockdep impossible to use with ecryptfs since this report triggers every time and disables future lockdep reporting. Since ecryptfs_add_keysig() is called only from the single callsite in ecryptfs_copy_mount_wide_sigs_to_inode_sigs(), the simplest fix seems to be to move the lock of keysig_list_mutex back up outside of the where global_auth_tok_list_mutex is taken. This patch does that, and fixes the lockdep report on my system (and ecryptfs still works OK). The full output of lockdep fixed by this patch is: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.31-2-generic #14~rbd2 ------------------------------------------------------- gdm/2640 is trying to acquire lock: (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}, at: [<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90 but task is already holding lock: (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [<ffffffff81217728>] ecryptfs_generate_key_packet_set+0x58/0x2b0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&crypt_stat->keysig_list_mutex){+.+.+.}: [<ffffffff8108c897>] check_prev_add+0x2a7/0x370 [<ffffffff8108cfc1>] validate_chain+0x661/0x750 [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430 [<ffffffff8108d585>] lock_acquire+0xa5/0x150 [<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0 [<ffffffff81552b56>] mutex_lock_nested+0x46/0x60 [<ffffffff8121526a>] ecryptfs_add_keysig+0x5a/0xb0 [<ffffffff81213299>] ecryptfs_copy_mount_wide_sigs_to_inode_sigs+0x59/0xb0 [<ffffffff81214b06>] ecryptfs_new_file_context+0xa6/0x1a0 [<ffffffff8120e42a>] ecryptfs_initialize_file+0x4a/0x140 [<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60 [<ffffffff8113a7d4>] vfs_create+0xb4/0xe0 [<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110 [<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0 [<ffffffff8112d8d9>] do_sys_open+0x69/0x140 [<ffffffff8112d9f0>] sys_open+0x20/0x30 [<ffffffff81013132>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff -> #0 (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}: [<ffffffff8108c675>] check_prev_add+0x85/0x370 [<ffffffff8108cfc1>] validate_chain+0x661/0x750 [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430 [<ffffffff8108d585>] lock_acquire+0xa5/0x150 [<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0 [<ffffffff81552b56>] mutex_lock_nested+0x46/0x60 [<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90 [<ffffffff812177d5>] ecryptfs_generate_key_packet_set+0x105/0x2b0 [<ffffffff81212f49>] ecryptfs_write_headers_virt+0xc9/0x120 [<ffffffff8121306d>] ecryptfs_write_metadata+0xcd/0x200 [<ffffffff8120e44b>] ecryptfs_initialize_file+0x6b/0x140 [<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60 [<ffffffff8113a7d4>] vfs_create+0xb4/0xe0 [<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110 [<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0 [<ffffffff8112d8d9>] do_sys_open+0x69/0x140 [<ffffffff8112d9f0>] sys_open+0x20/0x30 [<ffffffff81013132>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff other info that might help us debug this: 2 locks held by gdm/2640: #0: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8113cb8b>] do_filp_open+0x3cb/0xae0 #1: (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [<ffffffff81217728>] ecryptfs_generate_key_packet_set+0x58/0x2b0 stack backtrace: Pid: 2640, comm: gdm Tainted: G C 2.6.31-2-generic #14~rbd2 Call Trace: [<ffffffff8108b988>] print_circular_bug_tail+0xa8/0xf0 [<ffffffff8108c675>] check_prev_add+0x85/0x370 [<ffffffff81094912>] ? __module_text_address+0x12/0x60 [<ffffffff8108cfc1>] validate_chain+0x661/0x750 [<ffffffff81017275>] ? print_context_stack+0x85/0x140 [<ffffffff81089c68>] ? find_usage_backwards+0x38/0x160 [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430 [<ffffffff8108d585>] lock_acquire+0xa5/0x150 [<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90 [<ffffffff8108b0b0>] ? check_usage_backwards+0x0/0xb0 [<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0 [<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90 [<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90 [<ffffffff8108c02c>] ? mark_held_locks+0x6c/0xa0 [<ffffffff81125b0d>] ? kmem_cache_alloc+0xfd/0x1a0 [<ffffffff8108c34d>] ? trace_hardirqs_on_caller+0x14d/0x190 [<ffffffff81552b56>] mutex_lock_nested+0x46/0x60 [<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90 [<ffffffff812177d5>] ecryptfs_generate_key_packet_set+0x105/0x2b0 [<ffffffff81212f49>] ecryptfs_write_headers_virt+0xc9/0x120 [<ffffffff8121306d>] ecryptfs_write_metadata+0xcd/0x200 [<ffffffff81210240>] ? ecryptfs_init_persistent_file+0x60/0xe0 [<ffffffff8120e44b>] ecryptfs_initialize_file+0x6b/0x140 [<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60 [<ffffffff8113a7d4>] vfs_create+0xb4/0xe0 [<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110 [<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0 [<ffffffff8129a93e>] ? _raw_spin_unlock+0x5e/0xb0 [<ffffffff8155410b>] ? _spin_unlock+0x2b/0x40 [<ffffffff81139e9b>] ? getname+0x3b/0x240 [<ffffffff81148a5a>] ? alloc_fd+0xfa/0x140 [<ffffffff8112d8d9>] do_sys_open+0x69/0x140 [<ffffffff81553b8f>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8112d9f0>] sys_open+0x20/0x30 [<ffffffff81013132>] system_call_fastpath+0x16/0x1b Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
05dafedb |
|
14-Jul-2009 |
Roland Dreier <roland@digitalvampire.org> |
ecryptfs: Remove unneeded locking that triggers lockdep false positives In ecryptfs_destroy_inode(), inode_info->lower_file_mutex is locked, and just after the mutex is unlocked, the code does: kmem_cache_free(ecryptfs_inode_info_cache, inode_info); This means that if another context could possibly try to take the same mutex as ecryptfs_destroy_inode(), then it could end up getting the mutex just before the data structure containing the mutex is freed. So any such use would be an obvious use-after-free bug (catchable with slab poisoning or mutex debugging), and therefore the locking in ecryptfs_destroy_inode() is not needed and can be dropped. Similarly, in ecryptfs_destroy_crypt_stat(), crypt_stat->keysig_list_mutex is locked, and then the mutex is unlocked just before the code does: memset(crypt_stat, 0, sizeof(struct ecryptfs_crypt_stat)); Therefore taking this mutex is similarly not necessary. Removing this locking fixes false-positive lockdep reports such as the following (and they are false-positives for exactly the same reason that the locking is not needed): ================================= [ INFO: inconsistent lock state ] 2.6.31-2-generic #14~rbd3 --------------------------------- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd0/323 [HC0[0]:SC0[0]:HE1:SE1] takes: (&inode_info->lower_file_mutex){+.+.?.}, at: [<ffffffff81210d34>] ecryptfs_destroy_inode+0x34/0x100 {RECLAIM_FS-ON-W} state was registered at: [<ffffffff8108c02c>] mark_held_locks+0x6c/0xa0 [<ffffffff8108c10f>] lockdep_trace_alloc+0xaf/0xe0 [<ffffffff81125a51>] kmem_cache_alloc+0x41/0x1a0 [<ffffffff8113117a>] get_empty_filp+0x7a/0x1a0 [<ffffffff8112dd46>] dentry_open+0x36/0xc0 [<ffffffff8121a36c>] ecryptfs_privileged_open+0x5c/0x2e0 [<ffffffff81210283>] ecryptfs_init_persistent_file+0xa3/0xe0 [<ffffffff8120e838>] ecryptfs_lookup_and_interpose_lower+0x278/0x380 [<ffffffff8120f97a>] ecryptfs_lookup+0x12a/0x250 [<ffffffff8113930a>] real_lookup+0xea/0x160 [<ffffffff8113afc8>] do_lookup+0xb8/0xf0 [<ffffffff8113b518>] __link_path_walk+0x518/0x870 [<ffffffff8113bd9c>] path_walk+0x5c/0xc0 [<ffffffff8113be5b>] do_path_lookup+0x5b/0xa0 [<ffffffff8113bfe7>] user_path_at+0x57/0xa0 [<ffffffff811340dc>] vfs_fstatat+0x3c/0x80 [<ffffffff8113424b>] vfs_stat+0x1b/0x20 [<ffffffff81134274>] sys_newstat+0x24/0x50 [<ffffffff81013132>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff irq event stamp: 7811 hardirqs last enabled at (7811): [<ffffffff810c037f>] call_rcu+0x5f/0x90 hardirqs last disabled at (7810): [<ffffffff810c0353>] call_rcu+0x33/0x90 softirqs last enabled at (3764): [<ffffffff810631da>] __do_softirq+0x14a/0x220 softirqs last disabled at (3751): [<ffffffff8101440c>] call_softirq+0x1c/0x30 other info that might help us debug this: 2 locks held by kswapd0/323: #0: (shrinker_rwsem){++++..}, at: [<ffffffff810f67ed>] shrink_slab+0x3d/0x190 #1: (&type->s_umount_key#35){.+.+..}, at: [<ffffffff811429a1>] prune_dcache+0xd1/0x1b0 stack backtrace: Pid: 323, comm: kswapd0 Tainted: G C 2.6.31-2-generic #14~rbd3 Call Trace: [<ffffffff8108ad6c>] print_usage_bug+0x18c/0x1a0 [<ffffffff8108aff0>] ? check_usage_forwards+0x0/0xc0 [<ffffffff8108bac2>] mark_lock_irq+0xf2/0x280 [<ffffffff8108bd87>] mark_lock+0x137/0x1d0 [<ffffffff81164710>] ? fsnotify_clear_marks_by_inode+0x30/0xf0 [<ffffffff8108bee6>] mark_irqflags+0xc6/0x1a0 [<ffffffff8108d337>] __lock_acquire+0x287/0x430 [<ffffffff8108d585>] lock_acquire+0xa5/0x150 [<ffffffff81210d34>] ? ecryptfs_destroy_inode+0x34/0x100 [<ffffffff8108d2e7>] ? __lock_acquire+0x237/0x430 [<ffffffff815526ad>] __mutex_lock_common+0x4d/0x3d0 [<ffffffff81210d34>] ? ecryptfs_destroy_inode+0x34/0x100 [<ffffffff81164710>] ? fsnotify_clear_marks_by_inode+0x30/0xf0 [<ffffffff81210d34>] ? ecryptfs_destroy_inode+0x34/0x100 [<ffffffff8129a91e>] ? _raw_spin_unlock+0x5e/0xb0 [<ffffffff81552b36>] mutex_lock_nested+0x46/0x60 [<ffffffff81210d34>] ecryptfs_destroy_inode+0x34/0x100 [<ffffffff81145d27>] destroy_inode+0x87/0xd0 [<ffffffff81146b4c>] generic_delete_inode+0x12c/0x1a0 [<ffffffff81145832>] iput+0x62/0x70 [<ffffffff811423c8>] dentry_iput+0x98/0x110 [<ffffffff81142550>] d_kill+0x50/0x80 [<ffffffff81142623>] prune_one_dentry+0xa3/0xc0 [<ffffffff811428b1>] __shrink_dcache_sb+0x271/0x290 [<ffffffff811429d9>] prune_dcache+0x109/0x1b0 [<ffffffff81142abf>] shrink_dcache_memory+0x3f/0x50 [<ffffffff810f68dd>] shrink_slab+0x12d/0x190 [<ffffffff810f9377>] balance_pgdat+0x4d7/0x640 [<ffffffff8104c4c0>] ? finish_task_switch+0x40/0x150 [<ffffffff810f63c0>] ? isolate_pages_global+0x0/0x60 [<ffffffff810f95f7>] kswapd+0x117/0x170 [<ffffffff810777a0>] ? autoremove_wake_function+0x0/0x40 [<ffffffff810f94e0>] ? kswapd+0x0/0x170 [<ffffffff810773be>] kthread+0x9e/0xb0 [<ffffffff8101430a>] child_rip+0xa/0x20 [<ffffffff81013c90>] ? restore_args+0x0/0x30 [<ffffffff81077320>] ? kthread+0x0/0xb0 [<ffffffff81014300>] ? child_rip+0x0/0x20 Signed-off-by: Roland Dreier <roland@digitalvampire.org> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
|
#
13a791b4 |
|
13-Apr-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Fix data corruption when using ecryptfs_passthrough 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 <tyhicks@linux.vnet.ibm.com>
|
#
2aac0cf8 |
|
20-Mar-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: NULL crypt_stat dereference during lookup If ecryptfs_encrypted_view or ecryptfs_xattr_metadata were being specified as mount options, a NULL pointer dereference of crypt_stat was possible during lookup. This patch moves the crypt_stat assignment into ecryptfs_lookup_and_interpose_lower(), ensuring that crypt_stat will not be NULL before we attempt to dereference it. Thanks to Dan Carpenter and his static analysis tool, smatch, for finding this bug. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Acked-by: Dustin Kirkland <kirkland@canonical.com> Cc: Dan Carpenter <error27@gmail.com> Cc: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8faece5f |
|
20-Mar-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Allocate a variable number of pages for file headers When allocating the memory used to store the eCryptfs header contents, a single, zeroed page was being allocated with get_zeroed_page(). However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is stored in the file's private_data->crypt_stat->num_header_bytes_at_front field. ecryptfs_write_metadata_to_contents() was using num_header_bytes_at_front to decide how many bytes should be written to the lower filesystem for the file header. Unfortunately, at least 8K was being written from the page, despite the chance of the single, zeroed page being smaller than 8K. This resulted in random areas of kernel memory being written between the 0x1000 and 0x1FFF bytes offsets in the eCryptfs file headers if PAGE_SIZE was 4K. This patch allocates a variable number of pages, calculated with num_header_bytes_at_front, and passes the number of allocated pages along to ecryptfs_write_metadata_to_contents(). Thanks to Florian Streibelt for reporting the data leak and working with me to find the problem. 2.6.28 is the only kernel release with this vulnerability. Corresponds to CVE-2009-0787 Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Acked-by: Dustin Kirkland <kirkland@canonical.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Eugene Teo <eugeneteo@kernel.sg> Cc: Greg KH <greg@kroah.com> Cc: dann frazier <dannf@dannf.org> Cc: Serge E. Hallyn <serue@us.ibm.com> Cc: Florian Streibelt <florian@f-streibelt.de> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
84814d64 |
|
13-Mar-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: don't encrypt file key with filename key eCryptfs has file encryption keys (FEK), file encryption key encryption keys (FEKEK), and filename encryption keys (FNEK). The per-file FEK is encrypted with one or more FEKEKs and stored in the header of the encrypted file. I noticed that the FEK is also being encrypted by the FNEK. This is a problem if a user wants to use a different FNEK than their FEKEK, as their file contents will still be accessible with the FNEK. This is a minimalistic patch which prevents the FNEKs signatures from being copied to the inode signatures list. Ultimately, it keeps the FEK from being encrypted with a FNEK. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Acked-by: Dustin Kirkland <kirkland@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
fd9fc842 |
|
06-Feb-2009 |
Tyler Hicks <tyhicks@linux.vnet.ibm.com> |
eCryptfs: Regression in unencrypted filename symlinks The addition of filename encryption caused a regression in unencrypted filename symlink support. ecryptfs_copy_filename() is used when dealing with unencrypted filenames and it reported that the new, copied filename was a character longer than it should have been. This caused the return value of readlink() to count the NULL byte of the symlink target. Most applications don't care about the extra NULL byte, but a version control system (bzr) helped in discovering the bug. Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
71c11c37 |
|
06-Jan-2009 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: Clean up ecryptfs_decode_from_filename() Flesh out the comments for ecryptfs_decode_from_filename(). Remove the return condition, since it is always 0. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a8f12864 |
|
06-Jan-2009 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: Fix data types (int/size_t) Correct several format string data type specifiers. Correct filename size data types; they should be size_t rather than int when passed as parameters to some other functions (although note that the filenames will never be larger than int). Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
df261c52 |
|
06-Jan-2009 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: Replace %Z with %z %Z is a gcc-ism. Using %z instead. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
addd65ad |
|
06-Jan-2009 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: Filename Encryption: filldir, lookup, and readlink Make the requisite modifications to ecryptfs_filldir(), ecryptfs_lookup(), and ecryptfs_readlink() to call out to filename encryption functions. Propagate filename encryption policy flags from mount-wide crypt_stat to inode crypt_stat. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
51ca58dc |
|
06-Jan-2009 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: Filename Encryption: Encoding and encryption functions These functions support encrypting and encoding the filename contents. The encrypted filename contents may consist of any ASCII characters. This patch includes a custom encoding mechanism to map the ASCII characters to a reduced character set that is appropriate for filenames. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a34f60f7 |
|
06-Jan-2009 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: Filename Encryption: Header updates Extensions to the header file to support filename encryption. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9c79f34f |
|
06-Jan-2009 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: Filename Encryption: Tag 70 packets This patchset implements filename encryption via a passphrase-derived mount-wide Filename Encryption Key (FNEK) specified as a mount parameter. Each encrypted filename has a fixed prefix indicating that eCryptfs should try to decrypt the filename. When eCryptfs encounters this prefix, it decodes the filename into a tag 70 packet and then decrypts the packet contents using the FNEK, setting the filename to the decrypted filename. Both unencrypted and encrypted filenames can reside in the same lower filesystem. Because filename encryption expands the length of the filename during the encoding stage, eCryptfs will not properly handle filenames that are already near the maximum filename length. In the present implementation, eCryptfs must be able to produce a match against the lower encrypted and encoded filename representation when given a plaintext filename. Therefore, two files having the same plaintext name will encrypt and encode into the same lower filename if they are both encrypted using the same FNEK. This can be changed by finding a way to replace the prepended bytes in the blocked-aligned filename with random characters; they are hashes of the FNEK right now, so that it is possible to deterministically map from a plaintext filename to an encrypted and encoded filename in the lower filesystem. An implementation using random characters will have to decode and decrypt every single directory entry in any given directory any time an event occurs wherein the VFS needs to determine whether a particular file exists in the lower directory and the decrypted and decoded filenames have not yet been extracted for that directory. Thanks to Tyler Hicks and David Kleikamp for assistance in the development of this patchset. This patch: A tag 70 packet contains a filename encrypted with a Filename Encryption Key (FNEK). This patch implements functions for writing and parsing tag 70 packets. This patch also adds definitions and extends structures to support filename encryption. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
87b811c3 |
|
29-Oct-2008 |
Eric Sandeen <sandeen@redhat.com> |
ecryptfs: fix memory corruption when storing crypto info in xattrs When ecryptfs allocates space to write crypto headers into, before copying it out to file headers or to xattrs, it looks at the value of crypt_stat->num_header_bytes_at_front to determine how much space it needs. This is also used as the file offset to the actual encrypted data, so for xattr-stored crypto info, the value was zero. So, we kzalloc'd 0 bytes, and then ran off to write to that memory. (Which returned as ZERO_SIZE_PTR, so we explode quickly). The right answer is to always allocate a page to write into; the current code won't ever write more than that (this is enforced by the (PAGE_CACHE_SIZE - offset) length in the call to ecryptfs_generate_key_packet_set). To be explicit about this, we now send in a "max" parameter, rather than magically using PAGE_CACHE_SIZE there. Also, since the pointer we pass down the callchain eventually gets the virt_to_page() treatment, we should be using a alloc_page variant, not kzalloc (see also 7fcba054373d5dfc43d26e243a5c9b92069972ee) Signed-off-by: Eric Sandeen <sandeen@redhat.com> Acked-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7fcba054 |
|
28-Jul-2008 |
Eric Sandeen <sandeen@redhat.com> |
eCryptfs: use page_alloc not kmalloc to get a page of memory With SLUB debugging turned on in 2.6.26, I was getting memory corruption when testing eCryptfs. The root cause turned out to be that eCryptfs was doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice page-aligned chunk of memory. But at least with SLUB debugging on, this is not always true, and the page we get from virt_to_page does not necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc. My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2 different multi-megabyte files. With this change I no longer see the corruption. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Acked-by: Michael Halcrow <mhalcrow@us.ibm.com> Acked-by: Rik van Riel <riel@redhat.com> Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
29335c6a |
|
23-Jul-2008 |
Harvey Harrison <harvey.harrison@gmail.com> |
ecryptfs: crypto.c use unaligned byteorder helpers Fixes the following sparse warnings: fs/ecryptfs/crypto.c:1036:8: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1038:8: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1077:10: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1103:6: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1105:6: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1124:8: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1241:21: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1244:30: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1414:23: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1417:32: warning: cast to restricted __be16 Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
71fd5179 |
|
23-May-2008 |
Cyrill Gorcunov <gorcunov@gmail.com> |
ecryptfs: fix missed mutex_unlock Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
18d1dbf1 |
|
29-Apr-2008 |
Harvey Harrison <harvey.harrison@gmail.com> |
ecryptfs: replace remaining __FUNCTION__ occurrences __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
05db67a4 |
|
29-Apr-2008 |
Adrian Bunk <bunk@kernel.org> |
remove ecryptfs_header_cache_0 Remove the no longer used ecryptfs_header_cache_0. Signed-off-by: Adrian Bunk <bunk@kernel.org> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
af440f52 |
|
06-Feb-2008 |
Eric Sandeen <sandeen@redhat.com> |
ecryptfs: check for existing key_tfm at mount time Jeff Moyer pointed out that a mount; umount loop of ecryptfs, with the same cipher & other mount options, created a new ecryptfs_key_tfm_cache item each time, and the cache could grow quite large this way. Looking at this with mhalcrow, we saw that ecryptfs_parse_options() unconditionally called ecryptfs_add_new_key_tfm(), which is what was adding these items. Refactor ecryptfs_get_tfm_and_mutex_for_cipher_name() to create a new helper function, ecryptfs_tfm_exists(), which checks for the cipher on the cached key_tfm_list, and sets a pointer to it if it exists. This can then be called from ecryptfs_parse_options(), and new key_tfm's can be added only when a cached one is not found. With list locking changes suggested by akpm. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Jeff Moyer <jmoyer@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
19e66a67 |
|
06-Feb-2008 |
Trevor Highland <thighlan@gmail.com> |
eCryptfs: change the type of cipher_code from u16 to u8 Only the lower byte of cipher_code is ever used, so it makes sense for its type to be u8. Signed-off-by: Trevor Highland <trevor.highland@gmail.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
25bd8174 |
|
06-Feb-2008 |
Michael Halcrow <mike@halcrow.us> |
eCryptfs: Minor fixes to printk messages The printk statements that result when the user does not have the proper key available could use some refining. Signed-off-by: Mike Halcrow <mhalcrow@us.ibm.com> Cc: Mike Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8e3a6f16 |
|
06-Feb-2008 |
Trevor Highland <trevor.highland@gmail.com> |
eCryptfs: set inode key only once per crypto operation There is no need to keep re-setting the same key for any given eCryptfs inode. This patch optimizes the use of the crypto API and helps performance a bit. Signed-off-by: Trevor Highland <trevor.highland@gmail.com> Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
cc11beff |
|
06-Feb-2008 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: track header bytes rather than extents 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 <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7896b631 |
|
06-Feb-2008 |
Adrian Bunk <bunk@kernel.org> |
fs/ecryptfs/: possible cleanups - 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 <bunk@kernel.org> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
c8161f64 |
|
22-Dec-2007 |
Eric Sandeen <sandeen@redhat.com> |
ecryptfs: fix unlocking in error paths Thanks to Josef Bacik for finding these. A couple of ecryptfs error paths don't properly unlock things they locked. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Cc: Josef Bacik <jbacik@redhat.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b8862906 |
|
22-Dec-2007 |
Eric Sandeen <sandeen@redhat.com> |
ecryptfs: fix string overflow on long cipher names Passing a cipher name > 32 chars on mount results in an overflow when the cipher name is printed, because the last character in the struct ecryptfs_key_tfm's cipher_name string was never zeroed. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Acked-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8a29f2b0 |
|
05-Nov-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: release mutex on hash error path Release the crypt_stat hash mutex on allocation error. Check for error conditions when doing crypto hash calls. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Reported-by: Kazuki Ohta <kazuki.ohta@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
778d1a2b |
|
05-Nov-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: increment extent_offset once per loop interation The extent_offset is getting incremented twice per loop iteration through any given page. It should only be getting incremented once. This bug should only impact hosts with >4K page sizes. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
68e3f5dd |
|
27-Oct-2007 |
Herbert Xu <herbert@gondor.apana.org.au> |
[CRYPTO] users: Fix up scatterlist conversion errors This patch fixes the errors made in the users of the crypto layer during the sg_init_table conversion. It also adds a few conversions that were missing altogether. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
642f14903 |
|
24-Oct-2007 |
Jens Axboe <jens.axboe@oracle.com> |
SG: Change sg_set_page() to take length and offset argument Most drivers need to set length and offset as well, so may as well fold those three lines into one. Add sg_assign_page() for those two locations that only needed to set the page, where the offset/length is set outside of the function context. Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
#
60c74f81 |
|
22-Oct-2007 |
Jens Axboe <jens.axboe@oracle.com> |
Update fs/ to use sg helpers Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
#
16a72c45 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
ecryptfs: clean up page flag handling The functions that eventually call down to ecryptfs_read_lower(), ecryptfs_decrypt_page(), and ecryptfs_copy_up_encrypted_with_header() should have the responsibility of managing the page Uptodate status. This patch gets rid of some of the ugliness that resulted from trying to push some of the page flag setting too far down the stack. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ecbdc936 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: replace magic numbers Replace some magic numbers with sizeof() equivalents. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b6c1d8fc |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: remove unused functions and kmem_cache The switch to read_write.c routines and the persistent file make a number of functions unnecessary. This patch removes them. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d6a13c17 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: fix data types Update data types and add casts in order to avoid potential overflow issues. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
2ed92554 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: make open, truncate, and setattr use persistent file Rather than open a new lower file for every eCryptfs file that is opened, truncated, or setattr'd, instead use the existing lower persistent file for the eCryptfs inode. Change truncate to use read_write.c functions. Change ecryptfs_getxattr() to use the common ecryptfs_getxattr_lower() function. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d7cdc5fe |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: update metadata read/write functions Update the metadata read/write functions and grow_file() to use the read_write.c routines. Do not open another lower file; use the persistent lower file instead. Provide a separate function for crypto.c::ecryptfs_read_xattr_region() to get to the lower xattr without having to go through the eCryptfs getxattr. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0216f7f7 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: replace encrypt, decrypt, and inode size write Replace page encryption and decryption routines and inode size write routine with versions that utilize the read_write.c functions. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
5dda6992 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: remove assignments in if-statements Remove assignments in if-statements. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
45eaab79 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: remove header_extent_size There is no point to keeping a separate header_extent_size and an extent_size. The total size of the header can always be represented as some multiple of the regular data extent size. [randy.dunlap@oracle.com: ecryptfs: fix printk format warning] Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
cd9d67df |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: make needlessly global symbols static Andrew Morton wrote: > Please check that all the newly-added global symbols do indeed need > to be global. Change symbols in keystore.c and crypto.o to static if they do not need to be global. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
22e78faf |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: kerneldoc fixes for crypto.c and keystore.c Andrew Morton wrote: From: mhalcrow@us.ibm.com <mhalcrow@halcrow.austin.ibm.com> > > +/** > > + * decrypt_passphrase_encrypted_session_key - Decrypt the session key > > + * with the given auth_tok. > > * > > * Returns Zero on success; non-zero error otherwise. > > */ > > That comment purports to be a kerneldoc-style comment. But > > - kerneldoc doesn't support multiple lines on the introductory line > which identifies the name of the function (alas). So you'll need to > overflow 80 cols here. > > - the function args weren't documented > > But the return value is! People regularly forget to do that. And > they frequently forget to document the locking prerequisites and the > permissible calling contexts (process/might_sleep/hardirq, etc) > > (please check all ecryptfs kerneldoc for this stuff sometime) This patch cleans up some of the existing comments and makes a couple of line break tweaks. There is more work to do to bring eCryptfs into full kerneldoc-compliance. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
fcd12835 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: grammatical fix (destruct to destroy) Andrew Morton wrote: > > +int ecryptfs_destruct_crypto(void) > > ecryptfs_destroy_crypto would be more grammatically correct ;) Grammatical fix for some function names. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
af655dc6 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: collapse flag set into one statement Andrew Morton wrote: > > + crypt_stat->flags |= ECRYPTFS_ENCRYPTED; > > + crypt_stat->flags |= ECRYPTFS_KEY_VALID; > > Maybe the compiler can optimise those two statements, but we'd > normally provide it with some manual help. This patch provides the compiler with some manual help for optimizing the setting of some flags. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
c59c2eb5 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: remove unnecessary BUG_ON Andrew Morton wrote: > > + mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex); > > + BUG_ON(mount_crypt_stat->num_global_auth_toks == 0); > > + mutex_unlock(&mount_crypt_stat->global_auth_tok_list_mutex); > > That's odd-looking. If it was a bug for num_global_auth_toks to be > zero, and if that mutex protects num_global_auth_toks then as soon > as the lock gets dropped, another thread can make > num_global_auth_toks zero, hence the bug is present. Perhaps? That was serving as an internal sanity check that should not have made it into the final patch set in the first place. This patch removes it. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ca939e79 |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: update comment and debug statement Trivial updates to comment and debug statement. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f4aad16a |
|
16-Oct-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
eCryptfs: add key list structure; search keyring Add support structures for handling multiple keys. The list in crypt_stat contains the key identifiers for all of the keys that should be used for encrypting each file's File Encryption Key (FEK). For now, each inode inherits this list from the mount-wide crypt_stat struct, via the ecryptfs_copy_mount_wide_sigs_to_inode_sigs() function. This patch also removes the global key tfm from the mount-wide crypt_stat struct, instead keeping a list of tfm's meant for dealing with the various inode FEK's. eCryptfs will now search the user's keyring for FEK's parsed from the existing file metadata, so the user can make keys available at any time before or after mounting. Now that multiple FEK packets can be written to the file metadata, we need to be more meticulous about size limits. The updates to the code for writing out packets to the file metadata makes sizes and limits more explicit, uniformly expressed, and (hopefully) easier to follow. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
e2bd99ec |
|
12-Feb-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: open-code flag checking and manipulation Open-code flag checking and manipulation. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Trevor Highland <tshighla@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9d8b8ce5 |
|
12-Feb-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: convert kmap() to kmap_atomic() Replace kmap() with kmap_atomic(). Reduce the amount of time that mappings are held. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Trevor Highland <tshighla@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
70456600 |
|
12-Feb-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: convert f_op->write() to vfs_write() sys_write() takes a local copy of f_pos and writes that back into the struct file. It does this so that two concurrent write() callers don't make a mess of f_pos, and of the file contents. ecryptfs should be calling vfs_write(). That way we also get the fsnotify notifications, which ecryptfs presently appears to have subverted. Convert direct calls to f_op->write() into calls to vfs_write(). Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
e77a56dd |
|
12-Feb-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: Encrypted passthrough Provide an option to provide a view of the encrypted files such that the metadata is always in the header of the files, regardless of whether the metadata is actually in the header or in the extended attribute. This mode of operation is useful for applications like incremental backup utilities that do not preserve the extended attributes when directly accessing the lower files. With this option enabled, the files under the eCryptfs mount point will be read-only. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
dd2a3b7a |
|
12-Feb-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: Generalize metadata read/write Generalize the metadata reading and writing mechanisms, with two targets for now: metadata in file header and metadata in the user.ecryptfs xattr of the lower file. [akpm@osdl.org: printk warning fix] [bunk@stusta.de: make some needlessly global code static] Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
17398957 |
|
12-Feb-2007 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: xattr flags and mount options This patch set introduces the ability to store cryptographic metadata into an lower file extended attribute rather than the lower file header region. This patch set implements two new mount options: ecryptfs_xattr_metadata - When set, newly created files will have their cryptographic metadata stored in the extended attribute region of the file rather than the header. When storing the data in the file header, there is a minimum of 8KB reserved for the header information for each file, making each file at least 12KB in size. This can take up a lot of extra disk space if the user creates a lot of small files. By storing the data in the extended attribute, each file will only occupy at least of 4KB of space. As the eCryptfs metadata set becomes larger with new features such as multi-key associations, most popular filesystems will not be able to store all of the information in the xattr region in some cases due to space constraints. However, the majority of users will only ever associate one key per file, so most users will be okay with storing their data in the xattr region. This option should be used with caution. I want to emphasize that the xattr must be maintained under all circumstances, or the file will be rendered permanently unrecoverable. The last thing I want is for a user to forget to set an xattr flag in a backup utility, only to later discover that their backups are worthless. ecryptfs_encrypted_view - When set, this option causes eCryptfs to present applications a view of encrypted files as if the cryptographic metadata were stored in the file header, whether the metadata is actually stored in the header or in the extended attributes. No matter what eCryptfs winds up doing in the lower filesystem, I want to preserve a baseline format compatibility for the encrypted files. As of right now, the metadata may be in the file header or in an xattr. There is no reason why the metadata could not be put in a separate file in future versions. Without the compatibility mode, backup utilities would have to know to back up the metadata file along with the files. The semantics of eCryptfs have always been that the lower files are self-contained units of encrypted data, and the only additional information required to decrypt any given eCryptfs file is the key. That is what has always been emphasized about eCryptfs lower files, and that is what users expect. Providing the encrypted view option will provide a way to userspace applications wherein they can always get to the same old familiar eCryptfs encrypted files, regardless of what eCryptfs winds up doing with the metadata behind the scenes. This patch: Add extended attribute support to version bit vector, flags to indicate when xattr or encrypted view modes are enabled, and support for the new mount options. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
c3762229 |
|
10-Feb-2007 |
Robert P. J. Day <rpjday@mindspring.com> |
[PATCH] Transform kmem_cache_alloc()+memset(0) -> kmem_cache_zalloc(). Replace appropriate pairs of "kmem_cache_alloc()" + "memset(0)" with the corresponding "kmem_cache_zalloc()" call. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: Roland McGrath <roland@redhat.com> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Greg KH <greg@kroah.com> Acked-by: Joel Becker <Joel.Becker@oracle.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Jan Kara <jack@ucw.cz> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: James Morris <jmorris@namei.org> Cc: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f1ddcaf3 |
|
26-Jan-2007 |
Herbert Xu <herbert@gondor.apana.org.au> |
[CRYPTO] api: Remove deprecated interface This patch removes the old cipher interface and related code. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
e94b1766 |
|
06-Dec-2006 |
Christoph Lameter <clameter@sgi.com> |
[PATCH] slab: remove SLAB_KERNEL SLAB_KERNEL is an alias of GFP_KERNEL. Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
f7267c0c |
|
06-Dec-2006 |
Christoph Lameter <clameter@sgi.com> |
[PATCH] slab: remove SLAB_USER SLAB_USER is an alias of GFP_USER Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
de88777e |
|
28-Nov-2006 |
Akinobu Mita <akinobu.mita@gmail.com> |
[PATCH] ecryptfs: fix crypto_alloc_blkcipher() error check The return value of crypto_alloc_blkcipher() should be checked by IS_ERR(). Cc: Mike Halcrow <mhalcrow@us.ibm.com> Cc: Phillip Hellewell <phillip@hellewell.homeip.net> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
7bd473fc |
|
02-Nov-2006 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: Fix pointer deref I missed a pointer dereference in this kmalloc result check. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
7ff1d74f |
|
30-Oct-2006 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: Consolidate lower dentry_open's Opens on lower dentry objects happen in several places in eCryptfs, and they all involve the same steps (dget, mntget, dentry_open). This patch consolidates the lower open events into a single function call. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
8bba066f |
|
30-Oct-2006 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: Cipher code to new crypto API Update cipher block encryption code to the new crypto API. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
565d9724 |
|
30-Oct-2006 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: Hash code to new crypto API Update eCryptfs hash code to the new kernel crypto API. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
e5d9cbde |
|
30-Oct-2006 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] eCryptfs: Clean up crypto initialization Clean up the crypto initialization code; let the crypto API take care of the key size checks. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
237fead6 |
|
04-Oct-2006 |
Michael Halcrow <mhalcrow@us.ibm.com> |
[PATCH] ecryptfs: fs/Makefile and fs/Kconfig eCryptfs is a stacked cryptographic filesystem for Linux. It is derived from Erez Zadok's Cryptfs, implemented through the FiST framework for generating stacked filesystems. eCryptfs extends Cryptfs to provide advanced key management and policy features. eCryptfs stores cryptographic metadata in the header of each file written, so that encrypted files can be copied between hosts; the file will be decryptable with the proper key, and there is no need to keep track of any additional information aside from what is already in the encrypted file itself. [akpm@osdl.org: updates for ongoing API changes] [bunk@stusta.de: cleanups] [akpm@osdl.org: alpha build fix] [akpm@osdl.org: cleanups] [tytso@mit.edu: inode-diet updates] [pbadari@us.ibm.com: generic_file_*_read/write() interface updates] [rdunlap@xenotime.net: printk format fixes] [akpm@osdl.org: make slab creation and teardown table-driven] Signed-off-by: Phillip Hellewell <phillip@hellewell.homeip.net> Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|