From: David Gibson <david@gibson.dropbear.id.au>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, wli@holomorphy.com, linux-kernel@vger.kernel.org
Subject: Re: Fix crash when ptrace poking hugepage areas
Date: Tue, 29 Nov 2005 16:41:36 +1100 [thread overview]
Message-ID: <20051129054136.GA16852@localhost.localdomain> (raw)
In-Reply-To: <20051128211807.66817481.akpm@osdl.org>
On Mon, Nov 28, 2005 at 09:18:07PM -0800, Andrew Morton wrote:
> David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > Bill, does this look like the correct fix for the problem to you? If
> > so, please apply Andrew.
> >
> > set_page_dirty() will not cope with being handed a page * which is
> > part of a compound page, but not the master page in that compound
> > page. This case can occur via access_process_vm() if you attempt to
> > write to another process's hugepage memory area using ptrace()
> > (causing an oops or hang).
> >
> > This patch fixes the bug by first resolving the page * to the compound
> > page's master page.
>
> We already have to handle this situation for direct-io read()s into
> hugepages. bio_set_pages_dirty() does
>
> if (page && !PageCompound(page))
> set_page_dirty_lock(page);
>
> It's such a rare case that it's probably best to continue to do this in the
> caller rather than in the callee. That's access_process_vm().
Good call, revised patch below.
> Unless there's a reason why we actually want the compound page to be marked
> dirty? If there is, then direct-io has a problem.
I don't think so. Since hugepages are never disk-backed, I think the
PageDirty flag is more or less irrelevant.
Fix crash when ptrace poking hugepage areas
set_page_dirty() will not cope with being handed a page * which is
part of a compound page, but not the master page in that compound
page. This case can occur via access_process_vm() if you attemp to
write to another process's hugepage memory area using ptrace()
(causing an oops or hang).
This patch fixes the bug by only calling set_page_dirty() from
access_process_vm() if the page is not a compound page. We already
use a similar fix in bio_set_pages_dirty() for the case of direct io
to hugepages.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/kernel/ptrace.c
===================================================================
--- working-2.6.orig/kernel/ptrace.c 2005-11-29 16:37:15.000000000 +1100
+++ working-2.6/kernel/ptrace.c 2005-11-29 16:37:32.000000000 +1100
@@ -241,7 +241,8 @@ int access_process_vm(struct task_struct
if (write) {
copy_to_user_page(vma, page, addr,
maddr + offset, buf, bytes);
- set_page_dirty_lock(page);
+ if (!PageCompound(page))
+ set_page_dirty_lock(page);
} else {
copy_from_user_page(vma, page, addr,
buf, maddr + offset, bytes);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2005-11-29 5:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-29 5:06 Fix crash when ptrace poking hugepage areas David Gibson
2005-11-29 5:18 ` Andrew Morton
2005-11-29 5:41 ` David Gibson [this message]
2005-11-29 6:03 ` William Lee Irwin III
2005-11-29 6:02 ` William Lee Irwin III
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=20051129054136.GA16852@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=wli@holomorphy.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.