[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <529974C9.6040607@zytor.com>
Date: Fri, 29 Nov 2013 21:16:57 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Oleg Nesterov <oleg@...hat.com>, Andi Kleen <andi@...stfloor.org>
CC: linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
x86@...nel.org, Andi Kleen <ak@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] Add a text_poke syscall v2
On 11/29/2013 12:05 PM, Oleg Nesterov wrote:
> On 11/29, Andi Kleen wrote:
>>
>>> Andi, et al. I am going to discuss the things I do not really
>>> understand, probably this can't make any sense, but...
>>
>> I think it's enough to set the dirty bit in the underlying
>> struct page, no need to play games with the PTE.
>
> Ah, sorry for confusion, I guess you misunderstood.
>
> I meant, perhaps sys_text_poke() doesn't the in-kernel text_poke
> machinery altogether?
>
> Can't we invalidate pte (so that any user will stuck in page fault),
> update the page(s), restore the pte and drop the locks?
>
> This way sys_text_poke() won't be x86-specific, and it will be per-mm.
>
Hmmm... if we hold mmap_sem() this pretty much will be the net result,
no? That would mean no additional tests needed on the page fault path.
What I'm not sure of is whether or not it is actually safe to hold
mmap_sem across all the code we need -- on the other hand, we may very
well need to do so.
-hpa
--
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