Ingo Molnar wrote:
spurious faults happen all the time on SMP, in the native kernel.
And what i mean is that Linux mprotect currently does not take advantage
of x86's ability to just change the ptes, because there's no structured
way to tell mm/mprotect.c that "it's safe to skip the TLB flush
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> thanks, applied.
>>
>> it would be nice to expose this ability of the architecture to the core
>> Linux kernel mprotect code as well, and let it skip on a TLB flush when
>> doing a RO->RW transition.
>
> The usermode fault
Ingo Molnar wrote:
thanks, applied.
it would be nice to expose this ability of the architecture to the core
Linux kernel mprotect code as well, and let it skip on a TLB flush when
doing a RO->RW transition.
The usermode fault handler already effectively does this; this patch
just does it fo
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> When changing a kernel page from RO->RW, it's OK to leave stale TLB
> entries around, since doing a global flush is expensive and they pose
> no security problem. They can, however, generate a spurious fault,
> which we should catch and simpl
On 25/1/08 10:19, "Andi Kleen" <[EMAIL PROTECTED]> wrote:
>> Whether this a problem in light of Xen spurious faults depends on whether
>> NMI handlers touch dynamically-allocated data.
>
> How do you define dynamically-allocated data?
Anything that could have been a read-only pte or ldt page in
> Whether this a problem in light of Xen spurious faults depends on whether
> NMI handlers touch dynamically-allocated data.
How do you define dynamically-allocated data?
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
> Whether this a problem in light of Xen spurious faults depends on whether
> NMI handlers touch dynamically-allocated data. And if they do, it still
> depends on the exact scenario. If it is likely to be a problem, a Xen pv_op
> can flush the TLB on NMI entry, or we could have Xen do that implici
>>> Nick Piggin <[EMAIL PROTECTED]> 25.01.08 09:38 >>>
>On Friday 25 January 2008 19:15, Jan Beulich wrote:
>> Actually, another thought: permitting (and handling) spurious faults for
>> kernel mappings conflicts with NMI handling, i.e. great care would be
>> needed to ensure the NMI path cannot to
On 25/1/08 09:11, "Andi Kleen" <[EMAIL PROTECTED]> wrote:
>>> Actually, another thought: permitting (and handling) spurious faults for
>>> kernel mappings conflicts with NMI handling, i.e. great care would be
>>> needed to ensure the NMI path cannot touch any such mapping. So
>>> even the present
On Friday 25 January 2008 09:38:38 Nick Piggin wrote:
> On Friday 25 January 2008 19:15, Jan Beulich wrote:
> > Actually, another thought: permitting (and handling) spurious faults for
> > kernel mappings conflicts with NMI handling, i.e. great care would be
> > needed to ensure the NMI path cannot
On 25/1/08 00:26, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
>> I (obviously) don't know exactly how the TLB works in x86, but I
>> thought that on a miss, the CPU walks the pagetables first before
>> faulting? Maybe that's not the case if there is an RO entry
>> actually in the TLB?
>>
>
On Friday 25 January 2008 19:15, Jan Beulich wrote:
> Actually, another thought: permitting (and handling) spurious faults for
> kernel mappings conflicts with NMI handling, i.e. great care would be
> needed to ensure the NMI path cannot touch any such mapping. So
> even the present Xen/Linux Dom0
Actually, another thought: permitting (and handling) spurious faults for
kernel mappings conflicts with NMI handling, i.e. great care would be
needed to ensure the NMI path cannot touch any such mapping. So
even the present Xen/Linux Dom0 implementation may have some
(perhaps unlikely) problems her
Nick Piggin wrote:
On Friday 25 January 2008 06:21, Jeremy Fitzhardinge wrote:
Matt Mackall wrote:
There's perhaps an opportunity to do this lazy TLB trick in the mmap
path as well, where RW mappings are initially mapped as RO so we can
catch processes dirtying them and then switched to
On Friday 25 January 2008 06:21, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> > There's perhaps an opportunity to do this lazy TLB trick in the mmap
> > path as well, where RW mappings are initially mapped as RO so we can
> > catch processes dirtying them and then switched to RW. If the mappi
Matt Mackall wrote:
There's perhaps an opportunity to do this lazy TLB trick in the mmap
path as well, where RW mappings are initially mapped as RO so we can
catch processes dirtying them and then switched to RW. If the mapping is
shared across threads on multiple cores, we can defer synchronizin
On Wed, 2008-01-23 at 16:28 -0800, Jeremy Fitzhardinge wrote:
> When changing a kernel page from RO->RW, it's OK to leave stale TLB
> entries around, since doing a global flush is expensive and they pose
> no security problem. They can, however, generate a spurious fault,
> which we should catch
When changing a kernel page from RO->RW, it's OK to leave stale TLB
entries around, since doing a global flush is expensive and they pose
no security problem. They can, however, generate a spurious fault,
which we should catch and simply return from (which will have the
side-effect of reloading t
18 matches
Mail list logo
