From: Andrea Arcangeli <andrea@suse.de>
To: Andrey Savochkin <saw@saw.sw.com.sg>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Chris Mason <mason@suse.com>
Subject: Re: EXT3: problem with copy_from_user inside a transaction
Date: Fri, 3 Sep 2004 14:35:41 +0200 [thread overview]
Message-ID: <20040903123541.GB8557@x30.random> (raw)
In-Reply-To: <20040903150521.B1834@castle.nmd.msu.ru>
On Fri, Sep 03, 2004 at 03:05:21PM +0400, Andrey Savochkin wrote:
> Hi Andrew,
>
> filemap_copy_from_user() between prepare_write() and commit_write()
> appears to be a problem for ext3.
>
> prepare_write() starts a transaction, and if filemap_copy_from_user() causes
> a page fault, we'll have
> - order violation with mmap_sem taken inside a transaction (possible
> deadlocks),
> - __GFP_FS memory allocation with all re-entrancy problems (e.g.,
> current->journal_info corruption).
>
> Am I missing something?
>
> If this observation is correct, the possible solution is to call
> get_user_pages() or somehow pin the user pages before prepare_write(),
> although it will hurt performance...
yes, Chris is working on it for a few months.
just for the mmap_sem the easiest fix I proposed him, was to take the
mmap_sem in read mode before starting the transaction in prepare_write,
then the mmap_sem has to become recursive but that's trivial (my 2.4
rw semaphores are much simpler, they don't crash with million of
waiters, and they can support recursion).
however it seems the mmap_sem is not the only issue, he found another
issue with the page lock, maybe Chris you want to elaborate (the above
deadlock is absolutely clear, the one with the page lock less, btw, I
don't care much with reading the same page from disk that we're writing
to in the write syscall, that's a case we may just want to forbidden
since it makes no sense and currently it's racey even in 2.4, no pin
happens, but the prefaulting hides it).
We also hidden the above deadlock with prefaulting (but it's far from
fixed), prefaulting is a good idea anyways.
next prev parent reply other threads:[~2004-09-03 12:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-03 11:05 EXT3: problem with copy_from_user inside a transaction Andrey Savochkin
2004-09-03 12:35 ` Andrea Arcangeli [this message]
2004-09-03 12:06 ` Chris Mason
2004-09-03 13:03 ` Andrea Arcangeli
2004-09-03 13:57 ` Andrey Savochkin
2004-09-04 7:47 ` Chris Mason
2004-09-04 14:33 ` Andrey Savochkin
2004-09-04 20:12 ` Andrey Savochkin
2004-09-07 11:55 ` [RFC][PATCH] " Andrey Savochkin
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=20040903123541.GB8557@x30.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=saw@saw.sw.com.sg \
/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.