mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: deadlocks caused by ext3/reiser dirty_inode calls during do_mmap_pgoff
Date: Tue, 22 Jun 2004 10:13:18 -0400	[thread overview]
Message-ID: <1087913598.1512.264.camel@watt.suse.com> (raw)
In-Reply-To: <20040621171337.44d1b636.akpm@osdl.org>

On Mon, 2004-06-21 at 20:13, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > do_mmap_pgoff is called with a write lock on mmap_sem, and can trigger
> > calls to generic_file_mmap, which calls file_accessed to update the
> > atime on the file.
> > 
> > For reiserfs, this might start a transaction, which might have to wait
> > for the currently running transaction to finish.  It looks like ext3 may
> > do the same thing, but I'm not 100% sure on that.
> > 
> > If the currently running transaction happens to by running
> > copy_from_user, like we do during write calls, it might be trying to get
> > a hold of a read lock on the mmap sem while trying to hand page faults.
> 
> heh, good luck writing a testcase.

Hmmm, reiserfs_file_write does fault_in_pages_readable after the
transaction is started.  I can at least make the window smaller for now
by moving that before the transaction is started.  The test case looks
like this, they haven't tried yet on ext3, only reiser3

1. in ltp, create runtest/vmmstress1:
mmstress mmstress
mmap1 mmap1
mmap2 mmap2
mmap3 mmap3
mallocstress mallocstress

create runtest/vmmstress2:
mtest01 mtest01 -p85 -w

create dovmmstress.sh:
sar -o /root/results/vmmstress.sar 300 0&
./runalltests.sh -f /home/plars/test/ltp/runtest/vmmstress2 -t72h -l
/root/results/vmmstress2.log -p -q > /root/results/vmmstress2.out&
./runalltests.sh -f /home/plars/test/ltp/runtest/vmmstress1 -t72h -l
/root/results/vmmstress1.log -p -q |tee /root/results/vmmstress1.out
killall -9 sar
killall -9 sadc

2. run dovmmstress.sh

> I think we can fix both problems by changing filemap_copy_from_user() and
> filemap_copy_from_user_iovec() to not fall back to kmap() - just fail the
> copy in some way if the atomic copy failed.  Then, in
> generic_file_aio_write_nolock(), do a zero-length ->commit_write(),
> put_page(), then go back and retry the whole thing, starting with
> fault_in_pages_readable().

Ugh, ok.  I'm going to start with the smaller reiser patch to move the
prefaulting earlier.

-chris



  reply	other threads:[~2004-06-22 14:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-21 16:59 Chris Mason
2004-06-22  0:13 ` Andrew Morton
2004-06-22 14:13   ` Chris Mason [this message]
2004-06-22 18:57     ` Andrew Morton
2004-06-22 20:32       ` Chris Mason
2004-06-22 14:43   ` Chris Mason
2004-06-22 19:05     ` Andrew Morton
2004-06-22 20:41       ` Chris Mason
2004-06-25 17:59       ` Chris Mason

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=1087913598.1512.264.camel@watt.suse.com \
    --to=mason@suse.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome