All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: kirkland@canonical.com, ecryptfs-devel@lists.launchpad.net,
	linux-fsdevel@vger.kernel.org,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	xatrix101@gmail.com
Subject: Re: ecryptfs lock loop
Date: Wed, 15 Apr 2009 10:40:03 -0500	[thread overview]
Message-ID: <49E5FFD3.6090309@linux.vnet.ibm.com> (raw)
In-Reply-To: <49E4E5A4.80109@gmail.com>

Jiri Slaby wrote:
> Hi,
> 
> one student (in CC) found out a suspicioous locking dependence in
> ecryptfs code while debugging/running a static lockdep analyzer.
> 
> I'm unable to say whether it is only a theoretical issue or a real bug,
> any ideas?

Hi Jiri - This looks to be a real bug.  Thanks for pointing it out!

> 
> Here it comes:
> 
> function ecryptfs_send_message:
> ------------------------------
> ecryptfs_daemon_hash_mux <- ecryptfs_msg_ctx_lists_mux
> (in function ecryptfs_send_message_locked)

It would be nice if we could keep from having to hold the
ecryptfs_daemon_hash_mux for the entire execution of
ecryptfs_send_message_locked().  Maybe we could just hold it in
ecryptfs_send_message(), while it calls ecryptfs_find_daemon_by_euid().
 I think we would need to grab the daemon->mux before releasing the
ecryptfs_daemon_hash_mux to make sure that a QUIT message wasn't
received and the daemon freed before we add the msg_ctx to the
daemon->msg_ctx_out_queue in ecryptfs_send_miscdev().

It would remove the first lock dependency you pointed out, but I'll need
some more time to determine if it creates another bad lock loop.  Thanks
again!

Tyler

> 
> function ecryptfs_wait_for_response:
> -----------------------------------
> cryptfs_msg_ctx_lists_mux <- msg_ctx->mux
> 
> function ecryptfs_process_response:
> ----------------------------------
> msg_ctx->mux <- ecryptfs_daemon_hash_mux
> 
> 
> <- means lock dependency


      reply	other threads:[~2009-04-15 15:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 19:36 ecryptfs lock loop Jiri Slaby
2009-04-15 15:40 ` Tyler Hicks [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=49E5FFD3.6090309@linux.vnet.ibm.com \
    --to=tyhicks@linux.vnet.ibm.com \
    --cc=ecryptfs-devel@lists.launchpad.net \
    --cc=jirislaby@gmail.com \
    --cc=kirkland@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xatrix101@gmail.com \
    /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.