summaryrefslogtreecommitdiffstats
path: root/fs/hfs/Makefile
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2008-02-06 10:38:37 +0100
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2008-02-06 19:41:13 +0100
commitaf440f52927e4b6941aa94e3cfc698adb0f22663 (patch)
tree00a7fdc2b09e8e6146f0fd0bc055688d58eea939 /fs/hfs/Makefile
parenteCryptfs: change the type of cipher_code from u16 to u8 (diff)
downloadlinux-af440f52927e4b6941aa94e3cfc698adb0f22663.tar.xz
linux-af440f52927e4b6941aa94e3cfc698adb0f22663.zip
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>
Diffstat (limited to 'fs/hfs/Makefile')
0 files changed, 0 insertions, 0 deletions