Re: [PATCH] (UPDATED) ecryptfs: check for existing key_tfm at mount time
Andrew Morton wrote: > On Sat, 22 Dec 2007 11:42:37 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote: > >> Andrew Morton wrote: >> >>> It would all look a lot more solid if this locking was retained and both >>> ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be >>> called under key_tfm_list_mutex. >> Hmm good point, sorry for missing that. How's this look? > > key_tfm_list_mutex gets used in fs/ecryptfs/main.c but it is static in > fs/ecryptfs/crypto.c > Ah crud that was a bunk-ism in -mm that I missed. I'll send another updated patch soon. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] (UPDATED) ecryptfs: check for existing key_tfm at mount time
On Sat, 22 Dec 2007 11:42:37 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > > It would all look a lot more solid if this locking was retained and both > > ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be > > called under key_tfm_list_mutex. > > Hmm good point, sorry for missing that. How's this look? key_tfm_list_mutex gets used in fs/ecryptfs/main.c but it is static in fs/ecryptfs/crypto.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] (UPDATED) ecryptfs: check for existing key_tfm at mount time
Andrew Morton wrote:
> It would all look a lot more solid if this locking was retained and both
> ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be
> called under key_tfm_list_mutex.
Hmm good point, sorry for missing that. How's this look?
===
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 <[EMAIL PROTECTED]>
---
Index: linux-2.6.24-rc3/fs/ecryptfs/crypto.c
===
--- linux-2.6.24-rc3.orig/fs/ecryptfs/crypto.c
+++ linux-2.6.24-rc3/fs/ecryptfs/crypto.c
@@ -1812,6 +1812,11 @@ int ecryptfs_init_crypto(void)
return 0;
}
+/**
+ * ecryptfs_destroy_crypto - free all cached key_tfms on key_tfm_list
+ *
+ * Called only at module unload time
+ */
int ecryptfs_destroy_crypto(void)
{
struct ecryptfs_key_tfm *key_tfm, *key_tfm_tmp;
@@ -1835,6 +1840,8 @@ ecryptfs_add_new_key_tfm(struct ecryptfs
struct ecryptfs_key_tfm *tmp_tfm;
int rc = 0;
+ BUG_ON(!mutex_is_locked(_tfm_list_mutex));
+
tmp_tfm = kmem_cache_alloc(ecryptfs_key_tfm_cache, GFP_KERNEL);
if (key_tfm != NULL)
(*key_tfm) = tmp_tfm;
@@ -1861,13 +1868,51 @@ ecryptfs_add_new_key_tfm(struct ecryptfs
(*key_tfm) = NULL;
goto out;
}
- mutex_lock(_tfm_list_mutex);
list_add(_tfm->key_tfm_list, _tfm_list);
- mutex_unlock(_tfm_list_mutex);
out:
return rc;
}
+/**
+ * ecryptfs_tfm_exists - Search for existing tfm for cipher_name.
+ * @cipher_name: the name of the cipher to search for
+ * @key_tfm: set to corresponding tfm if found
+ *
+ * Searches for cached key_tfm matching @cipher_name
+ * Must be called with _tfm_list_mutex held
+ * Returns 1 if found, with @key_tfm set
+ * Returns 0 if not found, with @key_tfm set to NULL
+ */
+int ecryptfs_tfm_exists(char *cipher_name, struct ecryptfs_key_tfm **key_tfm)
+{
+ struct ecryptfs_key_tfm *tmp_key_tfm;
+
+ BUG_ON(!mutex_is_locked(_tfm_list_mutex));
+
+ list_for_each_entry(tmp_key_tfm, _tfm_list, key_tfm_list) {
+ if (strcmp(tmp_key_tfm->cipher_name, cipher_name) == 0) {
+ mutex_unlock(_tfm_list_mutex);
+ if (key_tfm)
+ (*key_tfm) = tmp_key_tfm;
+ return 1;
+ }
+ }
+ if (key_tfm)
+ (*key_tfm) = NULL;
+ return 0;
+}
+
+/**
+ * ecryptfs_get_tfm_and_mutex_for_cipher_name
+ *
+ * @tfm: set to cached tfm found, or new tfm created
+ * @tfm_mutex: set to mutex for cached tfm found, or new tfm created
+ * @cipher_name: the name of the cipher to search for and/or add
+ *
+ * Sets pointers to @tfm & @tfm_mutex matching @cipher_name.
+ * Searches for cached item first, and creates new if not found.
+ * Returns 0 on success, non-zero if adding new cipher failed
+ */
int ecryptfs_get_tfm_and_mutex_for_cipher_name(struct crypto_blkcipher **tfm,
struct mutex **tfm_mutex,
char *cipher_name)
@@ -1877,22 +1922,17 @@ int ecryptfs_get_tfm_and_mutex_for_ciphe
(*tfm) = NULL;
(*tfm_mutex) = NULL;
+
mutex_lock(_tfm_list_mutex);
- list_for_each_entry(key_tfm, _tfm_list, key_tfm_list) {
- if (strcmp(key_tfm->cipher_name, cipher_name) == 0) {
- (*tfm) = key_tfm->key_tfm;
- (*tfm_mutex) = _tfm->key_tfm_mutex;
- mutex_unlock(_tfm_list_mutex);
+ if (!ecryptfs_tfm_exists(cipher_name, _tfm)) {
+ rc = ecryptfs_add_new_key_tfm(_tfm, cipher_name, 0);
+ if (rc) {
+ printk(KERN_ERR "Error adding new key_tfm to list; "
+ "rc = [%d]\n", rc);
goto out;
}
}
mutex_unlock(_tfm_list_mutex);
- rc = ecryptfs_add_new_key_tfm(_tfm, cipher_name, 0);
- if (rc) {
- printk(KERN_ERR "Error adding new key_tfm to list; rc = [%d]\n",
- rc);
- goto out;
- }
(*tfm) = key_tfm->key_tfm;
(*tfm_mutex) =
[PATCH] (UPDATED) ecryptfs: check for existing key_tfm at mount time
Andrew Morton wrote:
It would all look a lot more solid if this locking was retained and both
ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be
called under key_tfm_list_mutex.
Hmm good point, sorry for missing that. How's this look?
===
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 [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/ecryptfs/crypto.c
===
--- linux-2.6.24-rc3.orig/fs/ecryptfs/crypto.c
+++ linux-2.6.24-rc3/fs/ecryptfs/crypto.c
@@ -1812,6 +1812,11 @@ int ecryptfs_init_crypto(void)
return 0;
}
+/**
+ * ecryptfs_destroy_crypto - free all cached key_tfms on key_tfm_list
+ *
+ * Called only at module unload time
+ */
int ecryptfs_destroy_crypto(void)
{
struct ecryptfs_key_tfm *key_tfm, *key_tfm_tmp;
@@ -1835,6 +1840,8 @@ ecryptfs_add_new_key_tfm(struct ecryptfs
struct ecryptfs_key_tfm *tmp_tfm;
int rc = 0;
+ BUG_ON(!mutex_is_locked(key_tfm_list_mutex));
+
tmp_tfm = kmem_cache_alloc(ecryptfs_key_tfm_cache, GFP_KERNEL);
if (key_tfm != NULL)
(*key_tfm) = tmp_tfm;
@@ -1861,13 +1868,51 @@ ecryptfs_add_new_key_tfm(struct ecryptfs
(*key_tfm) = NULL;
goto out;
}
- mutex_lock(key_tfm_list_mutex);
list_add(tmp_tfm-key_tfm_list, key_tfm_list);
- mutex_unlock(key_tfm_list_mutex);
out:
return rc;
}
+/**
+ * ecryptfs_tfm_exists - Search for existing tfm for cipher_name.
+ * @cipher_name: the name of the cipher to search for
+ * @key_tfm: set to corresponding tfm if found
+ *
+ * Searches for cached key_tfm matching @cipher_name
+ * Must be called with key_tfm_list_mutex held
+ * Returns 1 if found, with @key_tfm set
+ * Returns 0 if not found, with @key_tfm set to NULL
+ */
+int ecryptfs_tfm_exists(char *cipher_name, struct ecryptfs_key_tfm **key_tfm)
+{
+ struct ecryptfs_key_tfm *tmp_key_tfm;
+
+ BUG_ON(!mutex_is_locked(key_tfm_list_mutex));
+
+ list_for_each_entry(tmp_key_tfm, key_tfm_list, key_tfm_list) {
+ if (strcmp(tmp_key_tfm-cipher_name, cipher_name) == 0) {
+ mutex_unlock(key_tfm_list_mutex);
+ if (key_tfm)
+ (*key_tfm) = tmp_key_tfm;
+ return 1;
+ }
+ }
+ if (key_tfm)
+ (*key_tfm) = NULL;
+ return 0;
+}
+
+/**
+ * ecryptfs_get_tfm_and_mutex_for_cipher_name
+ *
+ * @tfm: set to cached tfm found, or new tfm created
+ * @tfm_mutex: set to mutex for cached tfm found, or new tfm created
+ * @cipher_name: the name of the cipher to search for and/or add
+ *
+ * Sets pointers to @tfm @tfm_mutex matching @cipher_name.
+ * Searches for cached item first, and creates new if not found.
+ * Returns 0 on success, non-zero if adding new cipher failed
+ */
int ecryptfs_get_tfm_and_mutex_for_cipher_name(struct crypto_blkcipher **tfm,
struct mutex **tfm_mutex,
char *cipher_name)
@@ -1877,22 +1922,17 @@ int ecryptfs_get_tfm_and_mutex_for_ciphe
(*tfm) = NULL;
(*tfm_mutex) = NULL;
+
mutex_lock(key_tfm_list_mutex);
- list_for_each_entry(key_tfm, key_tfm_list, key_tfm_list) {
- if (strcmp(key_tfm-cipher_name, cipher_name) == 0) {
- (*tfm) = key_tfm-key_tfm;
- (*tfm_mutex) = key_tfm-key_tfm_mutex;
- mutex_unlock(key_tfm_list_mutex);
+ if (!ecryptfs_tfm_exists(cipher_name, key_tfm)) {
+ rc = ecryptfs_add_new_key_tfm(key_tfm, cipher_name, 0);
+ if (rc) {
+ printk(KERN_ERR Error adding new key_tfm to list;
+ rc = [%d]\n, rc);
goto out;
}
}
mutex_unlock(key_tfm_list_mutex);
- rc = ecryptfs_add_new_key_tfm(key_tfm, cipher_name, 0);
- if (rc) {
- printk(KERN_ERR Error adding new key_tfm to list; rc = [%d]\n,
- rc);
- goto out;
- }
(*tfm) = key_tfm-key_tfm;
Re: [PATCH] (UPDATED) ecryptfs: check for existing key_tfm at mount time
On Sat, 22 Dec 2007 11:42:37 -0600 Eric Sandeen [EMAIL PROTECTED] wrote: Andrew Morton wrote: It would all look a lot more solid if this locking was retained and both ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be called under key_tfm_list_mutex. Hmm good point, sorry for missing that. How's this look? key_tfm_list_mutex gets used in fs/ecryptfs/main.c but it is static in fs/ecryptfs/crypto.c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] (UPDATED) ecryptfs: check for existing key_tfm at mount time
Andrew Morton wrote: On Sat, 22 Dec 2007 11:42:37 -0600 Eric Sandeen [EMAIL PROTECTED] wrote: Andrew Morton wrote: It would all look a lot more solid if this locking was retained and both ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be called under key_tfm_list_mutex. Hmm good point, sorry for missing that. How's this look? key_tfm_list_mutex gets used in fs/ecryptfs/main.c but it is static in fs/ecryptfs/crypto.c Ah crud that was a bunk-ism in -mm that I missed. I'll send another updated patch soon. -Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
