From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Michael Halcrow <mhalcrow@us.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] eCryptfs: Remove unnecessary mux from ecryptfs_init_ecryptfs_miscdev()
Date: Thu, 26 Jun 2008 20:04:48 +0400 [thread overview]
Message-ID: <20080626160448.GD7018@cvg> (raw)
In-Reply-To: <20080626160320.GA7408@halcrowt61p.austin.ibm.com>
[Michael Halcrow - Thu, Jun 26, 2008 at 11:03:20AM -0500]
| On Thu, Jun 26, 2008 at 05:59:04PM +0400, Cyrill Gorcunov wrote:
| > Some analisys shows the following interesting things -
| >
| > Call chain (if being compiled into the kernel)
| > ----------------------------------------------
| >
| > ecryptfs_init
| > ecryptfs_init_messaging
| > ecryptfs_init_ecryptfs_miscdev
| > mutex_lock(&ecryptfs_daemon_hash_mux);
| > misc_register(&ecryptfs_miscdev);
| > mutex_lock(&misc_mtx);
| > mutex_unlock(&misc_mtx);
| > 1 --->
| > mutex_unlock(&ecryptfs_daemon_hash_mux);
| >
| > As only we have misc device registered it is valid to open it.
| > And that is happened by another proccess
| >
| > chrdev_open
| > misc_open
| > mutex_lock(&misc_mtx);
| > ecryptfs_miscdev_open
| > mutex_lock(&ecryptfs_daemon_hash_mux);
| >
| >
| > If this happens at point (1) /ie chrdev_open called at this point/
| > we are getting to circular warning as on top.
|
| It appears to be only a warning and that deadlock cannot occur due to
| the fact that ecryptfs_miscdev_open() cannot be called until after
| mutex_unlock(&misc_mtx) occurs while under
| ecryptfs_init_ecryptfs_miscdev(). However, on second glance, given the
| call sequence detail you provided here, I think I am being
| over-zealous in my hash table locking with ecryptfs_daemon_hash_mux in
| ecryptfs_init_ecryptfs_miscdev(). The misc_mtx should provide all the
| protection required to keep the daemon hash table sane during miscdev
| registration.
|
| ---
|
| The misc_mtx should provide all the protection required to keep the
| daemon hash table sane during miscdev registration. Since this mutex
| is causing gratuitous lockdep warnings, this patch removes it.
|
| Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
| ---
| fs/ecryptfs/miscdev.c | 2 --
| 1 files changed, 0 insertions(+), 2 deletions(-)
|
| diff --git a/fs/ecryptfs/miscdev.c b/fs/ecryptfs/miscdev.c
| index 6560da1..a9926a4 100644
| --- a/fs/ecryptfs/miscdev.c
| +++ b/fs/ecryptfs/miscdev.c
| @@ -577,13 +577,11 @@ int ecryptfs_init_ecryptfs_miscdev(void)
| int rc;
|
| atomic_set(&ecryptfs_num_miscdev_opens, 0);
| - mutex_lock(&ecryptfs_daemon_hash_mux);
| rc = misc_register(&ecryptfs_miscdev);
| if (rc)
| printk(KERN_ERR "%s: Failed to register miscellaneous device "
| "for communications with userspace daemons; rc = [%d]\n",
| __func__, rc);
| - mutex_unlock(&ecryptfs_daemon_hash_mux);
| return rc;
| }
|
| --
| 1.5.3.7
|
Yes, it was only warning, but it was a bit annoying you know :)
Thanks a lot, Michael!
- Cyrill -
prev parent reply other threads:[~2008-06-26 16:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 13:59 eCryptFS possible circular locking Cyrill Gorcunov
2008-06-26 16:03 ` [PATCH] eCryptfs: Remove unnecessary mux from ecryptfs_init_ecryptfs_miscdev() Michael Halcrow
2008-06-26 16:04 ` Cyrill Gorcunov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080626160448.GD7018@cvg \
--to=gorcunov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@us.ibm.com \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.