lkml.org 
[lkml]   [2004]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.9-rc2-mm4 ps hang ?
Hugh Dickins <hugh@veritas.com> wrote:
>
> lock_page inside mmap_sem a ranking bug? Please recant!

generic_file_buffered_write() can take mmap_sem for reading while holding a
page lock. In that rare case where the page gets unmapped even though we
manually faulted it in.

Now, that's lock_page->down_read versus down_read->lock_page which I
_think_ is safe, due to down_read semantics. Even if a third thread is
waiting for a down_write.

Except filemap_nopage() does lock_page too, so we have

lock_page->down_read->lock_page

as well.

All this does mean that down_write cannot nest either inside or outside
lock_page.

The bigger problem is ext3 and reiser3 transaction start/stop. It is
equivalent to a down()/up() operation and we get the ranking for that
inconsistent too. Both wrt lock_page and wrt, I think, down_read(mmap_sem).

generic_file_buffered_write() does, effectively

lock_page
->transaction_start
->fault
->down_read(mmap_sem)
->lock_page

and over in do_mmap_pgoff() we nest transaction start inside
down_write(mmap_sem):

do_mmap_pgoff
->down_write(mmap_sem)
->generic_file_mmap
->file_accessed
->mark_inode_dirty
->transaction start

It's all a bit of a mess. Chris Mason and I have discussed it on and off.
I think Chris has a workload which actually does trigger a deadlock.

Maybe dropping and retaking mmap_sem in generic_file_mmap would be a
sufficient stopgap.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2011 Jasper Spaans