[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080311121714.GG18917@one.firstfloor.org>
Date: Tue, 11 Mar 2008 13:17:14 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: pageexec@...email.hu, Ingo Molnar <mingo@...e.hu>,
Srinivasa DS <srinivasa@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, ananth@...ibm.com,
Jim Keniston <jkenisto@...ibm.com>, srikar@...ux.vnet.ibm.com,
SystemTAP <systemtap@...rces.redhat.com>,
Andi Kleen <andi@...stfloor.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] x86 - Enhance DEBUG_RODATA support - alternatives
> First, that calling this text_poke implementation to modify text in a
> module won't fail. Is virt_to_page(addr) ok if addr is in a vmalloc'ed
> area ?
virt_to_page only works on direct mapping addresses, not vmalloc.
>
> Second, that calling virt_to_page(addr + PAGE_SIZE) won't have
> undesirable side-effects if addr happens to be in the last page of an
> allocated range. It should be ok for the core kernel text, because it is
> followed by the kernel rodata, but I am not certain for modules.
On non vmemmap/none flatmem kernels it could fail yes. But vmalloc/module_alloc
is not guaranteed to be continuous so you cannot do that anyways.
-Andi
--
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