From: Andrew Morton <akpm@osdl.org>
To: Hugh Dickins <hugh@veritas.com>
Cc: pbadari@us.ibm.com, linux-kernel@vger.kernel.org,
Chris Mason <mason@suse.com>
Subject: Re: 2.6.9-rc2-mm4 ps hang ?
Date: Fri, 1 Oct 2004 13:59:27 -0700 [thread overview]
Message-ID: <20041001135927.11527420.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0410012102510.9068-100000@localhost.localdomain>
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.
next prev parent reply other threads:[~2004-10-01 21:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 16:08 2.6.9-rc2-mm4 ps hang ? Badari Pulavarty
2004-10-01 19:09 ` Andrew Morton
2004-10-01 20:06 ` Hugh Dickins
2004-10-01 20:59 ` Andrew Morton [this message]
2004-10-01 21:29 ` Badari Pulavarty
2004-10-01 21:55 ` Andrew Morton
2004-10-01 23:06 ` Badari Pulavarty
2004-10-01 23:49 ` Andrew Morton
2004-10-02 0:13 ` Peter Williams
2004-10-02 0:19 ` Badari Pulavarty
2004-10-02 0:44 ` Andrew Morton
2004-10-04 15:43 ` Badari Pulavarty
2004-10-02 0:29 ` Badari Pulavarty
2004-10-02 0:42 ` Andrew Morton
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=20041001135927.11527420.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=pbadari@us.ibm.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.