On Thursday 15 June 2017 02:18 PM, Kirill A. Shutemov wrote:
O
I am not suggesting we don't do the invalidate (the need for that is
documented in __split_huge_pmd_locked(). I am suggesting we need a new
interface, something like Andrea suggested.
old_pmd = pmdp_establish(pmd_mknotpresent());
On Thu, Jun 15, 2017 at 06:35:21AM +0530, Aneesh Kumar K.V wrote:
>
>
> On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote:
> > Hi Aneesh,
> >
> > On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote:
> > > On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote:
> > > > Vlas
On Thursday 15 June 2017 06:35 AM, Aneesh Kumar K.V wrote:
W.r.t pmdp_invalidate() usage, I was wondering whether we can do that
early in __split_huge_pmd_locked().
BTW by moving pmdp_invalidate early, we can then get rid of
pmdp_huge_split_prepare(vma, haddr, pmd);
-aneesh
On Wednesday 14 June 2017 10:30 PM, Vlastimil Babka wrote:
On 06/14/2017 06:55 PM, Will Deacon wrote:
May be we should relook at pmd PTE udpate interface. We really need an
interface that can update pmd entries such that we don't clear it in
between. IMHO, we can avoid the pmdp_invalidate() c
On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote:
Hi Aneesh,
On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote:
On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote:
Vlastimil noted that pmdp_invalidate() is not atomic and we can loose
dirty and access bits if CPU
On 06/14/2017 06:55 PM, Will Deacon wrote:
>>
>> May be we should relook at pmd PTE udpate interface. We really need an
>> interface that can update pmd entries such that we don't clear it in
>> between. IMHO, we can avoid the pmdp_invalidate() completely, if we can
>> switch from a pmd PTE entry t
Hi Aneesh,
On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote:
> On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote:
> >Vlastimil noted that pmdp_invalidate() is not atomic and we can loose
> >dirty and access bits if CPU sets them after pmdp dereference, but
> >before set_
On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote:
Hi,
Vlastimil noted that pmdp_invalidate() is not atomic and we can loose
dirty and access bits if CPU sets them after pmdp dereference, but
before set_pmd_at().
The bug doesn't lead to user-visible misbehaviour in current kernel,
Hi Kirill,
On Wed, 14 Jun 2017 16:51:40 +0300
"Kirill A. Shutemov" wrote:
> Vlastimil noted that pmdp_invalidate() is not atomic and we can loose
> dirty and access bits if CPU sets them after pmdp dereference, but
> before set_pmd_at().
>
> The bug doesn't lead to user-visible misbehaviour in
Hi,
Vlastimil noted that pmdp_invalidate() is not atomic and we can loose
dirty and access bits if CPU sets them after pmdp dereference, but
before set_pmd_at().
The bug doesn't lead to user-visible misbehaviour in current kernel, but
fixing this would be critical for future work on THP: both hug
10 matches
Mail list logo
