On Thu, 2007-09-27 at 15:00 +0100, Christoph Hellwig wrote:
> On Thu, Sep 27, 2007 at 03:51:07PM +0200, Peter Zijlstra wrote:
> > Christoph,
> >
> > does Steve's story make sense?
>
> Yes.
>
> > All that would need to be done is add an extra lock_class_key to
> > file_system_type for i_mutex_di
On Thu, Sep 27, 2007 at 03:51:07PM +0200, Peter Zijlstra wrote:
> Christoph,
>
> does Steve's story make sense?
Yes.
> All that would need to be done is add an extra lock_class_key to
> file_system_type for i_mutex_dir_key, and extend alloc_inode to say
> something like:
>
> if (dir)
> l
On Mon, 2007-09-24 at 22:13 -0400, Steven Rostedt wrote:
> On Mon, Sep 24, 2007 at 06:07:38PM -0400, Trond Myklebust wrote:
> > I'm seeing lockdep warning about a potential lock inversion between
> > &mm->mmap_sem and &inode->i_mutex in NFS (see attachment).
> >
> > Unfortunately the basis for the
On Mon, Sep 24, 2007 at 06:07:38PM -0400, Trond Myklebust wrote:
> I'm seeing lockdep warning about a potential lock inversion between
> &mm->mmap_sem and &inode->i_mutex in NFS (see attachment).
>
> Unfortunately the basis for the warning appears to be the behaviour in
> ext3(???). AFAICS there i
I'm seeing lockdep warning about a potential lock inversion between
&mm->mmap_sem and &inode->i_mutex in NFS (see attachment).
Unfortunately the basis for the warning appears to be the behaviour in
ext3(???). AFAICS there is no way for NFS to share an inode->i_mutex
with ext3. What to do?
Trond
=
5 matches
Mail list logo
