From: Andrew Morton <akpm@zip.com.au>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Daniel Jacobowitz <dan@debian.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH?] Crash in 2.4.17/ptrace
Date: Mon, 28 Jan 2002 21:35:08 -0800 [thread overview]
Message-ID: <3C56348C.F516A2DB@zip.com.au> (raw)
In-Reply-To: <20020128153210.A3032@nevyn.them.org> <3C55BC89.EDE3105C@zip.com.au>, <3C55BC89.EDE3105C@zip.com.au> <20020128161900.A9071@nevyn.them.org> <3C55C2AB.AE73A75D@zip.com.au>, <3C55C2AB.AE73A75D@zip.com.au>; from akpm@zip.com.au on Mon, Jan 28, 2002 at 01:29:15PM -0800 <20020129005451.H1309@athlon.random>
Andrea Arcangeli wrote:
>
> ...
> Well, I think your earlier suggestion to bale out with an error if an
> invalid page is found sounds like the cleaner fix (possibly in function
> of yet another bitflag, so if somebody wants to get the nearby pages
> regardless of an invalid pages somewhere, it can).
>
I find it rather hard to decide about this. get_user_pages()
leaves null page pointers in the page[] array for invalid
pages, and that's a reasonable API, as long as all callers
are actually aware of it....
In the O_DIRECT case, the kernel does not crash, because
brw_kiovec() does:
map = iobuf->maplist[pageind];
if (!map) {
err = -EFAULT;
goto finished;
}
However, I think it _would_ crash if the first entry in the maplist[]
was non-null, and the second is null, because that would cause
generic_file_direct_IO() to call mark_dirty_kiobuf(), and
mark_dirty_kiobuf() forgets to check for NULL page *'s in the maplist[].
Given the difficulty of testing all this, and the dubious benefit
in allowing a holey maplist[], I'm inclined to just disallow it
in 2.4. What do you think?
--- linux-2.4.18-pre7/mm/memory.c Fri Dec 21 11:19:23 2001
+++ linux-akpm/mm/memory.c Mon Jan 28 16:26:47 2002
@@ -453,6 +453,7 @@ int get_user_pages(struct task_struct *t
vma = find_extend_vma(mm, start);
if ( !vma ||
+ (vma->vm_flags & VM_IO) ||
(!force &&
((write && (!(vma->vm_flags & VM_WRITE))) ||
(!write && (!(vma->vm_flags & VM_READ))) ) )) {
@@ -486,8 +487,9 @@ int get_user_pages(struct task_struct *t
/* FIXME: call the correct function,
* depending on the type of the found page
*/
- if (pages[i])
- page_cache_get(pages[i]);
+ if (!pages[i])
+ goto bad_page;
+ page_cache_get(pages[i]);
}
if (vmas)
vmas[i] = vma;
@@ -497,7 +499,19 @@ int get_user_pages(struct task_struct *t
} while(len && start < vma->vm_end);
spin_unlock(&mm->page_table_lock);
} while(len);
+out:
return i;
+
+ /*
+ * We found an invalid page in the VMA. Release all we have
+ * so far and fail.
+ */
+bad_page:
+ spin_unlock(&mm->page_table_lock);
+ while (i--)
+ page_cache_release(pages[i]);
+ i = -EFAULT;
+ goto out;
}
/*
next prev parent reply other threads:[~2002-01-29 5:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-28 20:32 [PATCH?] Crash in 2.4.17/ptrace Daniel Jacobowitz
2002-01-28 21:03 ` Andrew Morton
2002-01-28 21:19 ` Daniel Jacobowitz
2002-01-28 21:29 ` Andrew Morton
2002-01-28 21:55 ` Alan Cox
2002-01-28 22:12 ` Andrew Morton
2002-01-29 22:59 ` [Linux-fbdev-devel] " James Simmons
2002-01-29 23:02 ` Andrew Morton
2002-01-30 0:13 ` James Simmons
2002-01-28 22:15 ` Benjamin Herrenschmidt
2002-01-28 23:57 ` Andrea Arcangeli
2002-01-28 23:54 ` Andrea Arcangeli
2002-01-29 5:35 ` Andrew Morton [this message]
2002-01-28 23:47 ` Andrea Arcangeli
2002-01-28 21:42 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2002-01-28 21:33 Manfred Spraul
2002-01-28 22:05 ` Alan Cox
2002-01-28 22:07 ` Manfred Spraul
2002-01-28 22:26 ` Daniel Jacobowitz
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=3C56348C.F516A2DB@zip.com.au \
--to=akpm@zip.com.au \
--cc=andrea@suse.de \
--cc=dan@debian.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