LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Chintan Pandya <cpandya@codeaurora.org>
To: "joro@8bytes.org" <joro@8bytes.org>, "Kani, Toshi" <toshi.kani@hpe.com>
Cc: "Hocko, Michal" <MHocko@suse.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"wxf.wang@hisilicon.com" <wxf.wang@hisilicon.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"willy@infradead.org" <willy@infradead.org>,
	"guohanjun@huawei.com" <guohanjun@huawei.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"bp@suse.de" <bp@suse.de>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces
Date: Fri, 27 Apr 2018 17:22:28 +0530	[thread overview]
Message-ID: <5b237058-6617-6af3-8499-8836d95f538d@codeaurora.org> (raw)
In-Reply-To: <20180427073719.GT15462@8bytes.org>



On 4/27/2018 1:07 PM, joro@8bytes.org wrote:
> On Thu, Apr 26, 2018 at 10:30:14PM +0000, Kani, Toshi wrote:
>> Thanks for the clarification. After reading through SDM one more time, I
>> agree that we need a TLB purge here. Here is my current understanding.
>>
>>   - INVLPG purges both TLB and paging-structure caches. So, PMD cache was
>> purged once.
>>   - However, processor may cache this PMD entry later in speculation
>> since it has p-bit set. (This is where my misunderstanding was.
>> Speculation is not allowed to access a target address, but it may still
>> cache this PMD entry.)
>>   - A single INVLPG on each processor purges this PMD cache. It does not
>> need a range purge (which was already done).
>>
>> Does it sound right to you?
> 
> The right fix is to first synchronize the changes when the PMD/PUD is
> cleared and then flush the TLB system-wide. After that is done you can
> free the page.
> 

I'm bit confused here. Are you pointing to race within ioremap/vmalloc
framework while updating the page table or race during tlb ops. Since
later is arch dependent, I would not comment. But if the race being 
discussed here while altering page tables, I'm not on the same page.

Current ioremap/vmalloc framework works with reserved virtual area for 
its own purpose. Within this virtual area, we maintain mutual 
exclusiveness by maintaining separate rbtree which is of course 
synchronized. In the __vunmap leg, we perform page table ops first and
then release the virtual area for someone else to re-use. This way, 
without taking any additional locks for page table modifications, we are
good.

If that's not the case and I'm missing something here.

Also, I'm curious to know what race you are observing at your end.


Chintan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

  parent reply	other threads:[~2018-04-27 11:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14 18:01 [PATCH v2 0/2] fix memory leak / panic in ioremap huge pages Toshi Kani
2018-03-14 18:01 ` [PATCH v2 1/2] mm/vmalloc: Add interfaces to free unmapped page table Toshi Kani
2018-03-14 22:38   ` Andrew Morton
2018-03-15 14:27     ` Kani, Toshi
2018-03-14 18:01 ` [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces Toshi Kani
2018-03-15  7:39   ` Chintan Pandya
2018-03-15 14:51     ` Kani, Toshi
2018-04-26 14:19   ` Joerg Roedel
2018-04-26 16:21     ` Kani, Toshi
2018-04-26 17:23       ` joro
2018-04-26 17:49         ` Kani, Toshi
2018-04-26 20:07           ` joro
2018-04-26 22:30             ` Kani, Toshi
2018-04-27  7:37               ` joro
2018-04-27 11:39                 ` Michal Hocko
2018-04-27 11:46                   ` joro
2018-04-27 11:52                 ` Chintan Pandya [this message]
2018-04-27 12:48                   ` joro
2018-04-27 13:42                     ` Chintan Pandya
2018-04-27 14:31                 ` Kani, Toshi
2018-04-28  9:02                   ` joro
2018-04-28 20:54                     ` Kani, Toshi
2018-04-30  7:30                       ` Chintan Pandya
2018-04-30 13:43                         ` Kani, Toshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b237058-6617-6af3-8499-8836d95f538d@codeaurora.org \
    --to=cpandya@codeaurora.org \
    --cc=MHocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hpe.com \
    --cc=will.deacon@arm.com \
    --cc=willy@infradead.org \
    --cc=wxf.wang@hisilicon.com \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).