From: Nick Piggin <npiggin@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: [patch] splice mmap_sem deadlock
Date: Fri, 28 Sep 2007 18:00:35 +0200 [thread overview]
Message-ID: <20070928160035.GD12538@wotan.suse.de> (raw)
I'm fairly sure this is the right patch... but the explicit comment has me
thinking I missed something? (there is also a down_write->fault deadlock
in the splice code in -mm, however when talking with Jens about that code,
we might have an idea for a different approach using preexisting vmas
rather than setting them up with splice -- so this patch is just for mainline)
mmap_sem cannot be taken recursively for read, due to the FIFO nature of the
rwsem, and the presence of possible write lockers.
process A process B
down_read(mmap_sem); [1]
get_user(); down_write(mmap_sem); [2]
-> page fault
down_read(mmap_sem); [3]
[1] will never be released until [3] can be taken and released, however:
[2] blocks on [1]; [3] blocks on [2].
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/fs/splice.c
===================================================================
--- linux-2.6.orig/fs/splice.c
+++ linux-2.6/fs/splice.c
@@ -1534,12 +1534,6 @@ static int get_iovec_page_array(const st
{
int buffers = 0, error = 0;
- /*
- * It's ok to take the mmap_sem for reading, even
- * across a "get_user()".
- */
- down_read(¤t->mm->mmap_sem);
-
while (nr_vecs) {
unsigned long off, npages;
void __user *base;
@@ -1583,9 +1577,11 @@ static int get_iovec_page_array(const st
if (npages > PIPE_BUFFERS - buffers)
npages = PIPE_BUFFERS - buffers;
+ down_read(¤t->mm->mmap_sem);
error = get_user_pages(current, current->mm,
(unsigned long) base, npages, 0, 0,
&pages[buffers], NULL);
+ up_read(¤t->mm->mmap_sem);
if (unlikely(error <= 0))
break;
@@ -1624,8 +1620,6 @@ static int get_iovec_page_array(const st
iov++;
}
- up_read(¤t->mm->mmap_sem);
-
if (buffers)
return buffers;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2007-09-28 16:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-28 16:00 Nick Piggin [this message]
2007-09-28 17:31 ` Jens Axboe
2007-09-28 18:10 ` Linus Torvalds
2007-09-28 18:15 ` Jens Axboe
2007-09-28 18:23 ` Linus Torvalds
2007-09-28 19:30 ` Jens Axboe
2007-09-28 20:02 ` Linus Torvalds
2007-09-28 20:08 ` Linus Torvalds
2007-09-29 6:37 ` Jens Axboe
2007-10-01 12:03 ` Jens Axboe
2007-10-01 15:11 ` Linus Torvalds
2007-10-01 15:45 ` Balbir Singh
2007-10-01 16:11 ` Linus Torvalds
2007-10-01 18:19 ` Balbir Singh
2007-10-01 17:33 ` Jens Axboe
2007-09-29 13:10 ` Nick Piggin
2007-09-30 6:46 ` Jens Axboe
2007-09-30 12:07 ` Nick Piggin
2007-09-30 20:05 ` Jens Axboe
2007-09-30 20:12 ` Nick Piggin
2007-09-29 13:08 ` Nick Piggin
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=20070928160035.GD12538@wotan.suse.de \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=linux-mm@kvack.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