On 08/23/2012 03:50 AM, Andrea Arcangeli wrote:
> Hi Andrew,
>
> On Wed, Aug 22, 2012 at 12:15:35PM -0700, Andrew Morton wrote:
>> On Wed, 22 Aug 2012 18:29:55 +0200
>> Andrea Arcangeli wrote:
>>
>>> On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM,
On 08/23/2012 12:37 AM, Andrea Arcangeli wrote:
> On Wed, Aug 22, 2012 at 11:51:17AM +0800, Xiao Guangrong wrote:
>> Hmm, in KSM code, i found this code in replace_page:
>>
>> set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma->vm_page_prot));
>>
>> It is possible to establish a writable pte, no?
On 08/23/2012 12:37 AM, Andrea Arcangeli wrote:
On Wed, Aug 22, 2012 at 11:51:17AM +0800, Xiao Guangrong wrote:
Hmm, in KSM code, i found this code in replace_page:
set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma-vm_page_prot));
It is possible to establish a writable pte, no?
Hugh
On 08/23/2012 03:50 AM, Andrea Arcangeli wrote:
Hi Andrew,
On Wed, Aug 22, 2012 at 12:15:35PM -0700, Andrew Morton wrote:
On Wed, 22 Aug 2012 18:29:55 +0200
Andrea Arcangeli aarca...@redhat.com wrote:
On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM,
On Wed, Aug 22, 2012 at 12:58:05PM -0700, Andrew Morton wrote:
> If you can suggest some text I'll type it in right now.
Ok ;), I tried below:
This is safe to start by updating the secondary MMUs, because the
relevant primary MMU pte invalidate must have already happened with a
ptep_clear_flush
On Wed, 22 Aug 2012 21:50:43 +0200
Andrea Arcangeli wrote:
> Hi Andrew,
>
> On Wed, Aug 22, 2012 at 12:15:35PM -0700, Andrew Morton wrote:
> > On Wed, 22 Aug 2012 18:29:55 +0200
> > Andrea Arcangeli wrote:
> >
> > > On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
> > > > On
Hi Andrew,
On Wed, Aug 22, 2012 at 12:15:35PM -0700, Andrew Morton wrote:
> On Wed, 22 Aug 2012 18:29:55 +0200
> Andrea Arcangeli wrote:
>
> > On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
> > > On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> > > > CPU0
On Wed, 22 Aug 2012 18:29:55 +0200
Andrea Arcangeli wrote:
> On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
> > On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> > > CPU0 CPU1
> > > oldpage[1] == 0 (both guest & host)
> > >
On Wed, Aug 22, 2012 at 11:51:17AM +0800, Xiao Guangrong wrote:
> Hmm, in KSM code, i found this code in replace_page:
>
> set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma->vm_page_prot));
>
> It is possible to establish a writable pte, no?
Hugh already answered this thanks. Further details
On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
> On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> > CPU0CPU1
> > oldpage[1] == 0 (both guest & host)
> > oldpage[0] = 1
> > trigger do_wp_page
>
> We always do
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> On Tue, Aug 21, 2012 at 05:46:39PM +0800, Xiao Guangrong wrote:
>> There has a bug in set_pte_at_notify which always set the pte to the
>> new page before release the old page in secondary MMU, at this time,
>> the process will access on the new
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
On Tue, Aug 21, 2012 at 05:46:39PM +0800, Xiao Guangrong wrote:
There has a bug in set_pte_at_notify which always set the pte to the
new page before release the old page in secondary MMU, at this time,
the process will access on the new page, but
On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
CPU0CPU1
oldpage[1] == 0 (both guest host)
oldpage[0] = 1
trigger do_wp_page
We always do ptep_clear_flush before
On Wed, Aug 22, 2012 at 11:51:17AM +0800, Xiao Guangrong wrote:
Hmm, in KSM code, i found this code in replace_page:
set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma-vm_page_prot));
It is possible to establish a writable pte, no?
Hugh already answered this thanks. Further details on the
On Wed, 22 Aug 2012 18:29:55 +0200
Andrea Arcangeli aarca...@redhat.com wrote:
On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
CPU0 CPU1
oldpage[1] == 0 (both guest
Hi Andrew,
On Wed, Aug 22, 2012 at 12:15:35PM -0700, Andrew Morton wrote:
On Wed, 22 Aug 2012 18:29:55 +0200
Andrea Arcangeli aarca...@redhat.com wrote:
On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
CPU0
On Wed, 22 Aug 2012 21:50:43 +0200
Andrea Arcangeli aarca...@redhat.com wrote:
Hi Andrew,
On Wed, Aug 22, 2012 at 12:15:35PM -0700, Andrew Morton wrote:
On Wed, 22 Aug 2012 18:29:55 +0200
Andrea Arcangeli aarca...@redhat.com wrote:
On Wed, Aug 22, 2012 at 02:03:41PM +0800, Xiao
On Wed, Aug 22, 2012 at 12:58:05PM -0700, Andrew Morton wrote:
If you can suggest some text I'll type it in right now.
Ok ;), I tried below:
This is safe to start by updating the secondary MMUs, because the
relevant primary MMU pte invalidate must have already happened with a
ptep_clear_flush
On 08/22/2012 12:12 PM, Hugh Dickins wrote:
> On Wed, 22 Aug 2012, Xiao Guangrong wrote:
>> On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
>>>
>>> The KSM usage of it looks safe because it will only establish readonly
>>> ptes with it.
>>
>> Hmm, in KSM code, i found this code in replace_page:
>>
On Wed, 22 Aug 2012, Xiao Guangrong wrote:
> On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> >
> > The KSM usage of it looks safe because it will only establish readonly
> > ptes with it.
>
> Hmm, in KSM code, i found this code in replace_page:
>
> set_pte_at_notify(mm, addr, ptep,
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> On Tue, Aug 21, 2012 at 05:46:39PM +0800, Xiao Guangrong wrote:
>> There has a bug in set_pte_at_notify which always set the pte to the
>> new page before release the old page in secondary MMU, at this time,
>> the process will access on the new
On Tue, Aug 21, 2012 at 05:46:39PM +0800, Xiao Guangrong wrote:
> There has a bug in set_pte_at_notify which always set the pte to the
> new page before release the old page in secondary MMU, at this time,
> the process will access on the new page, but the secondary MMU still
> access on the old
There has a bug in set_pte_at_notify which always set the pte to the
new page before release the old page in secondary MMU, at this time,
the process will access on the new page, but the secondary MMU still
access on the old page, the memory is inconsistent between them
Below scenario shows the
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
On Tue, Aug 21, 2012 at 05:46:39PM +0800, Xiao Guangrong wrote:
There has a bug in set_pte_at_notify which always set the pte to the
new page before release the old page in secondary MMU, at this time,
the process will access on the new page, but
On Wed, 22 Aug 2012, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
The KSM usage of it looks safe because it will only establish readonly
ptes with it.
Hmm, in KSM code, i found this code in replace_page:
set_pte_at_notify(mm, addr, ptep, mk_pte(kpage,
On 08/22/2012 12:12 PM, Hugh Dickins wrote:
On Wed, 22 Aug 2012, Xiao Guangrong wrote:
On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
The KSM usage of it looks safe because it will only establish readonly
ptes with it.
Hmm, in KSM code, i found this code in replace_page:
There has a bug in set_pte_at_notify which always set the pte to the
new page before release the old page in secondary MMU, at this time,
the process will access on the new page, but the secondary MMU still
access on the old page, the memory is inconsistent between them
Below scenario shows the
On Tue, Aug 21, 2012 at 05:46:39PM +0800, Xiao Guangrong wrote:
There has a bug in set_pte_at_notify which always set the pte to the
new page before release the old page in secondary MMU, at this time,
the process will access on the new page, but the secondary MMU still
access on the old page,
28 matches
Mail list logo
