From: Arnd Bergmann <arnd@arndb•de>
To: Al Viro <viro@zeniv•linux.org.uk>
Cc: linuxppc-dev@lists•ozlabs.org, masterzorag <masterzorag@gmail•com>
Subject: Re: [PATCH] spufs raises two exceptions
Date: Wed, 7 Mar 2012 22:32:47 +0000 [thread overview]
Message-ID: <201203072232.47895.arnd@arndb.de> (raw)
In-Reply-To: <20120307212330.GT23916@ZenIV.linux.org.uk>
On Wednesday 07 March 2012, Al Viro wrote:
> > No it's not, it all goes together. spufs_create_context() always
> > unlocked & dropped the dentry before returning, so I assumed the
> > lock had to be dropped before fsnotify.
> >
> > Note that if the problem is that the lock has to be dropped before
> > spu_forget(), then we should indeed move it back into the leaf functions
> > and just remove all the unlock path from the top ones. It's a bit nasty
> > how we drop the mutex first, then do spu_forget, then drop the dentry
> > but we could go back to doing that.
> >
> > What I want is consistent semantics. It's just silly to have 3 different
> > stacking levels which all 3 may or may not be responsible to dropping
> > the lock & dentry depending on circumstances.
>
> Why not leave unlock/dput to the caller? Details of deadlocks caused
> by that approach, please...
If only I could remember that part exactly. I think I was remembering
0309f02d8 "spufs: fix deadlock in spu_create error path", which had a
double lock problem in this path. Please bear with me here because it's
been six years since I debugged that particular problem.
A lot of the nastyness of spu_forget() is about the problem of having
to give up a reference on current->mm that is held by an spu context,
while the mm contains a vma that maps this context and holds a refence
on the inode, in particular in case of calling exit().
However, I don't see now how either of these two issues requires that
we call spu_forget without the i_mutex held during a context creation
failure.
Arnd
prev parent reply other threads:[~2012-03-07 22:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-06 9:26 [PATCH] spufs raises two exceptions masterzorag
2012-03-07 3:49 ` Benjamin Herrenschmidt
2012-03-07 3:51 ` Benjamin Herrenschmidt
2012-03-07 12:48 ` Arnd Bergmann
2012-03-07 21:01 ` Benjamin Herrenschmidt
2012-03-07 21:23 ` Al Viro
2012-03-07 22:32 ` Arnd Bergmann [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=201203072232.47895.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=masterzorag@gmail$(echo .)com \
--cc=viro@zeniv$(echo .)linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox