lkml.org 
[lkml]   [2005]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fix crash when ptrace poking hugepage areas
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().

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-11-29 06:21    [W:0.041 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site