[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131205172355.GA25780@redhat.com>
Date: Thu, 5 Dec 2013 18:23:55 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "H. Peter Anvin" <hpa@...or.com>, Hugh Dickins <hughd@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Kosina <jkosina@...e.cz>,
Andi Kleen <andi@...stfloor.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Andi Kleen <ak@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Subject: Re: [PATCH?] uprobes: change uprobe_write_opcode() to modify the
page directly
On 12/04, Oleg Nesterov wrote:
>
> And/Or. Are you still saying that on x86 (and powerpc?) we do not need
> these pte games at all and uprobe_write_opcode() can simply do:
>
> /* Break the mapping unless the page is already anonymous */
> ret = get_user_pages(NULL, mm, vaddr, 1, 1, 1, &page, &vma);
>
> // this page can't be swapped out due to page_freeze_refs()
> copy_to_page(page, vaddr, &opcode, UPROBE_SWBP_INSN_SIZE);
>
> set_page_dirty_lock(page);
This is almost off-topic, but I am wondering if (in the long term)
we can avoid this "insert the bp into every mm" altogether.
Instead, uprobe_write_opcode() should only unmap this page and set
SWP_UPROBE_ENTRY. The probed application should install the page
with breakpoints itself on demand during the fault, do_swap_page()
->non_swap_entry() can do this.
This also allows to share the patched page, uprobes should read it
at uprobe_register() time, make a copy, add the breakpoint, and keep
it for do_swap_page().
Perhaps. Not sure this is really possible, and of course this is not
that simple, and the filtering complicates this even more. And we
should ensure that the application itself or ptracer can't write to
this page (or even cow it), but this doesn't look too hard.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists