cking if it is really locked or not
as there are explicit APIs to set PG_locked.
I didn't get traces of history for having PG_locked being set non-atomically.
I believe it could be because of performance reasons. Not sure though.
Chintan Pandya (2):
page-flags: Make page lock operation ato
ge-Id: I13bdbedc2b198af014d885e1925c93b83ed6660e
Signed-off-by: Chintan Pandya
---
fs/cifs/file.c | 8
fs/pipe.c | 2 +-
include/linux/page-flags.h | 2 +-
include/linux/pagemap.h| 6 +++---
mm/filemap.c | 4 ++--
mm/khugepaged.c| 2 +-
mm/
wait-until-set. So, at least, find out who is
doing double setting and fix them.
Change-Id: I1295fcb8527ce4b54d5d11c11287fc7516006cf0
Signed-off-by: Chintan Pandya
---
include/linux/page-flags.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/page-flags.h b/include
Commit-ID: 785a19f9d1dd8a4ab2d0633be4656653bd3de1fc
Gitweb: https://git.kernel.org/tip/785a19f9d1dd8a4ab2d0633be4656653bd3de1fc
Author: Chintan Pandya
AuthorDate: Wed, 27 Jun 2018 08:13:47 -0600
Committer: Thomas Gleixner
CommitDate: Wed, 4 Jul 2018 21:37:08 +0200
ioremap: Update
Hi Andrew,
On 6/6/2018 9:15 PM, Will Deacon wrote:
[...]
On Wed, Jun 06, 2018 at 12:31:18PM +0530, Chintan Pandya wrote:
This series of patches re-bring huge vmap back for arm64.
Patch 1/3 has been taken by Toshi in his series of patches
by name "[PATCH v3 0/3] fix free pmd/pte
On 6/6/2018 9:15 PM, Will Deacon wrote:
Hi Chintan,
Hi Will,
Thanks for sticking with this. I've reviewed the series now and I'm keen
for it to land in mainline. Just a couple of things below.
Thanks for all the reviews so far.
On Wed, Jun 06, 2018 at 12:31:18PM +0530, Chin
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index dfc61d7
From: Chintan Pandya
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.
1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4
and also free the leaking page tables.
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidation of TLB
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 48
1 file
one perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandy
On 6/4/2018 5:43 PM, Will Deacon wrote:
On Fri, Jun 01, 2018 at 06:09:16PM +0530, Chintan Pandya wrote:
Add helper macros to give virtual references to page
tables. These will be used while freeing dangling
page tables.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/pgtable.h
On 6/4/2018 5:44 PM, Will Deacon wrote:
On Fri, Jun 01, 2018 at 06:09:18PM +0530, Chintan Pandya wrote:
Huge mappings have had stability issues due to stale
TLB entry and memory leak issues. Since, those are
addressed in this series of patches, it is now safe
to allow huge mappings.
Signed
On 6/4/2018 5:43 PM, Will Deacon wrote:
On Fri, Jun 01, 2018 at 06:09:17PM +0530, Chintan Pandya wrote:
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but
d enough. Test ended positively.
Thanks,
On 6/1/2018 6:09 PM, Chintan Pandya wrote:
This series of patches re-bring huge vmap back for arm64.
Patch 1/4 has been taken by Toshi in his series of patches
by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86"
to avoid merge conflict wi
Add helper macros to give virtual references to page
tables. These will be used while freeing dangling
page tables.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/pgtable.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm
From: Chintan Pandya
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.
1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index dfc61d7
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64
and table free
- Avoid redundant TLB invalidatation in one perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmappe
Huge mappings have had stability issues due to stale
TLB entry and memory leak issues. Since, those are
addressed in this series of patches, it is now safe
to allow huge mappings.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 18 ++
1 file changed, 2 insertions(+), 16
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index dfc61d7
From: Chintan Pandya
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.
1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8 --
ne perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandya
On 5/24/2018 7:27 PM, Chintan Pandya wrote:
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8 --
From: Chintan Pandya
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.
1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index dfc61d7
for 'addr' in x86 implementation
- Re-order pmd/pud clear and table free
- Avoid redundant TLB invalidatation in one perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of &
/4 as updated by Toshi.
On Mon, Apr 30, 2018 at 01:11:33PM +0530, Chintan Pandya wrote:
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entr
On 5/23/2018 8:04 PM, Kani, Toshi wrote:
On Wed, 2018-05-23 at 15:01 +0100, Will Deacon wrote:
Hi Chintan,
[as a side note: I'm confused on the status of this patch series, as part
of it was reposted separately by Toshi. Please can you work together?]
I do not know the status of my patch
On 5/4/2018 3:12 AM, Andrew Morton wrote:
On Tue, 17 Apr 2018 16:13:48 +0530 Chintan Pandya
wrote:
Client can call vunmap with some intermediate 'addr'
which may not be the start of the VM area. Entire
unmap code works with vm->vm_start which is proper
but debug object API i
On 5/2/2018 1:24 PM, Ganesh Mahendran wrote:
Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This
enables Speculative Page Fault handler.
Signed-off-by: Ganesh Mahendran
---
This patch is on top of Laurent's v10 spf
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --g
) + 45.468 us |}
6) 2.760 us|vunmap_page_range();
6) ! 505.105 us | }
Signed-off-by: Chintan Pandya
---
mm/vmalloc.c | 29 +++--
1 file changed, 7 insertions(+), 22 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ebff729..781ce02 100644
--- a
On 5/1/2018 4:22 AM, Andrew Morton wrote:
On Mon, 16 Apr 2018 16:29:02 +0530 Chintan Pandya
wrote:
vunmap does page table clear operations twice in the
case when DEBUG_PAGEALLOC_ENABLE_DEFAULT is enabled.
So, clean up the code as that is unintended.
As a perf gain, we save few us. Below
On 5/1/2018 4:34 AM, Andrew Morton wrote:
should check for it and do a WARN_ONCE so it gets fixed.
Yes, that was an idea in discussion but I've been suggested that it
could be intentional. But since you are raising this, I will try to dig
once again and share a patch with WARN_ONCE if passing
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64
pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 8 +---
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8 --
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index dfc61d7
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandya (4):
ioremap: Update pgtable free interfaces with addr
arm64: tlbflush: Introduce __flush_tlb_kernel_pgt
On 4/29/2018 2:24 AM, Kani, Toshi wrote:
On Sat, 2018-04-28 at 11:02 +0200, j...@8bytes.org wrote:
On Fri, Apr 27, 2018 at 02:31:51PM +, Kani, Toshi wrote:
So, we can add the step 2 on top of this patch.
1. Clear pud/pmd entry.
2. System wide TLB flush <-- TO BE ADDED BY NEW PATCH
3
On 4/27/2018 6:18 PM, j...@8bytes.org wrote:
On Fri, Apr 27, 2018 at 05:22:28PM +0530, Chintan Pandya wrote:
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 woul
On 4/27/2018 3:59 PM, Catalin Marinas wrote:
On Tue, Apr 03, 2018 at 01:30:44PM +0530, Chintan Pandya wrote:
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 6 ++
1 file changed, 6
On 4/27/2018 1:07 PM, j...@8bytes.org wrote:
On Thu, Apr 26, 2018 at 10:30:14PM +, 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-struc
the debug objects corresponding to this vm area.
Here, we actually free 'other' client's debug objects.
Fix this by freeing the debug objects first and then
releasing the VM area.
Signed-off-by: Chintan Pandya
---
mm/vmalloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-
s into debug object API.
Signed-off-by: Chintan Pandya
---
mm/vmalloc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 12d675c..033c918 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1124,15 +1124,15 @@ void vm_unmap_ram(const void *
Below 2 patches are rebased over tip + my other patch in
review "[PATCH v2] mm: vmalloc: Clean up vunmap to avoid
pgtable ops twice"
Chintan Pandya (2):
mm: vmalloc: Avoid racy handling of debugobjects in vunmap
mm: vmalloc: Pass proper vm_start into debugobjects
>From V1->
Ping...
On 4/3/2018 1:30 PM, Chintan Pandya wrote:
This series of patches are follow up work (and depends on)
Toshi Kani 's patches "fix memory leak/
panic in ioremap huge pages".
This series of patches are tested on 4.9 kernel with Cortex-A75
based SoC.
These patches c
On 4/17/2018 8:39 AM, Anshuman Khandual wrote:
On 04/16/2018 05:39 PM, Chintan Pandya wrote:
On 4/13/2018 5:31 PM, Anshuman Khandual wrote:
On 04/13/2018 05:03 PM, Chintan Pandya wrote:
Client can call vunmap with some intermediate 'addr'
which may not be the start of the VM ar
On 4/13/2018 5:31 PM, Anshuman Khandual wrote:
On 04/13/2018 05:03 PM, Chintan Pandya wrote:
Client can call vunmap with some intermediate 'addr'
which may not be the start of the VM area. Entire
unmap code works with vm->vm_start which is proper
but debug object API is call
) + 45.468 us |}
6) 2.760 us|vunmap_page_range();
6) ! 505.105 us | }
Signed-off-by: Chintan Pandya
---
mm/vmalloc.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ebff729..6729400 100644
--- a/mm
On 4/13/2018 5:11 PM, Michal Hocko wrote:
On Fri 13-04-18 16:57:06, Chintan Pandya wrote:
On 4/13/2018 4:39 PM, Michal Hocko wrote:
On Fri 13-04-18 16:15:26, Chintan Pandya wrote:
On 4/13/2018 4:10 PM, Anshuman Khandual wrote:
On 04/13/2018 03:47 PM, Chintan Pandya wrote:
On 4/13
s into debug object API.
Signed-off-by: Chintan Pandya
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 9ff21a1..28034c55 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1526,8 +1526,8 @@ static void __vunmap(const void *addr
the debug objects corresponding to this vm area.
Here, we actually free 'other' client's debug objects.
Fix this by freeing the debug objects first and then
releasing the VM area.
Signed-off-by: Chintan Pandya
---
mm/vmalloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-
help
debug objects to be in consistent state.
We've observed some list corruptions in debug objects.
However, no claims that these patches will be fixing
them.
If one has an opinion that debug object has no use in
vmalloc framework, I would raise a patch to remove
them from the vunmap leg.
Ch
On 4/13/2018 4:39 PM, Michal Hocko wrote:
On Fri 13-04-18 16:15:26, Chintan Pandya wrote:
On 4/13/2018 4:10 PM, Anshuman Khandual wrote:
On 04/13/2018 03:47 PM, Chintan Pandya wrote:
On 4/13/2018 3:29 PM, Anshuman Khandual wrote:
On 04/13/2018 02:46 PM, Chintan Pandya wrote:
Unmap
On 4/13/2018 4:10 PM, Anshuman Khandual wrote:
On 04/13/2018 03:47 PM, Chintan Pandya wrote:
On 4/13/2018 3:29 PM, Anshuman Khandual wrote:
On 04/13/2018 02:46 PM, Chintan Pandya wrote:
Unmap legs do call vunmap_page_range() irrespective of
debug_pagealloc_enabled() is enabled or not. So
On 4/13/2018 3:29 PM, Anshuman Khandual wrote:
On 04/13/2018 02:46 PM, Chintan Pandya wrote:
Unmap legs do call vunmap_page_range() irrespective of
debug_pagealloc_enabled() is enabled or not. So, remove
redundant check and optional vunmap_page_range() routines.
vunmap_page_range() tears
Unmap legs do call vunmap_page_range() irrespective of
debug_pagealloc_enabled() is enabled or not. So, remove
redundant check and optional vunmap_page_range() routines.
Signed-off-by: Chintan Pandya
---
mm/vmalloc.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions
On 4/3/2018 5:25 PM, Chintan Pandya wrote:
On 4/3/2018 2:13 PM, Marc Zyngier wrote:
Hi Chintan,
Hi Marc,
On 03/04/18 09:00, Chintan Pandya wrote:
This series of patches are follow up work (and depends on)
Toshi Kani 's patches "fix memory leak/
panic in ioremap huge pages"
On 4/3/2018 2:13 PM, Marc Zyngier wrote:
Hi Chintan,
Hi Marc,
On 03/04/18 09:00, Chintan Pandya wrote:
This series of patches are follow up work (and depends on)
Toshi Kani 's patches "fix memory leak/
panic in ioremap huge pages".
This series of patches are tested on
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index 9e82dd7
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8 --
pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 8 +---
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64
wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chintan-Pandya/ioremap-Update-pgtable-free-interfaces-with-addr/20180329-133736
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce
d redundant TLB invalidatation in one perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honor
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8 --
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index 9e82dd7
pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 8 +---
;V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandya (4):
ioremap: Update pgtable free inte
On 3/28/2018 5:20 PM, kbuild test robot wrote:
@725 if (!pmd_free_pte_page(&pmd[i]))
My bad ! Will fix this in v7
Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative
I goofed up in making a patch file so enumeration is wrong.
I'll upload v7
On 3/28/2018 4:28 PM, Chintan Pandya wrote:
This series of patches are follow up work (and depends on)
Toshi Kani 's patches "fix memory leak/
panic in ioremap huge pages".
This series of patch
pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
>From V4->V6:
- No change
arch/arm64/mm/mmu.c | 4 ++--
arch/x8
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
From: V1-> V6:
- No change
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
>From
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
From: V5->V6:
- No change
arch/arm64/include/asm/tlbflush.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/
->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandya (4):
ioremap: Update pgtable free interfaces with addr
arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
arm64: Implement page table
On 3/27/2018 11:30 PM, Will Deacon wrote:
Hi Chintan,
Hi Will,
On Tue, Mar 27, 2018 at 06:54:59PM +0530, Chintan Pandya wrote:
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Freeing of the un-used next level page tables
2) Clearing off the current
pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
No change in v5.
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 6
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Freeing of the un-used next level page tables
2) Clearing off the current pud/pmd entry
3) Invalidate TLB which could have previously
valid but not stale entry
Signed-off-by: Chintan Pandya
---
V4->
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
No change in v5
arch/arm64/mm
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
Introduced in v5
arch/arm64/include/asm/tlbflush.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
This series of patches are follow up work (and depends on)
Toshi Kani 's patches "fix memory leak/
panic in ioremap huge pages".
This series of patches are tested on 4.9 kernel with Cortex-A75
based SoC.
These patches can also go into '-stable' branch.
Chintan Pand
On 3/26/2018 3:25 PM, Mark Rutland wrote:
On Tue, Mar 20, 2018 at 05:15:13PM +0530, Chintan Pandya wrote:
+static int __pmd_free_pte_page(pmd_t *pmd, unsigned long addr, bool tlb_inv)
+{
+ pmd_t *table;
+
+ if (pmd_val(*pmd)) {
+ table = __va(pmd_val(*pmd
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Freeing of the un-used next level page tables
2) Clearing off the current pud/pmd entry
3) Invalidate TLB which could have previously
valid but not stale entry
Signed-off-by: Chintan Pandya
---
arch/arm64
pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 6 --
include/a
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8 --
This series of patches are follow up work (and depends on)
Toshi Kani 's patches "fix memory leak/
panic in ioremap huge pages".
This series of patches are tested on 4.9 kernel with Cortex-A75
based SoC.
Chintan Pandya (3):
ioremap: Update pgtable free interfaces with addr
a
On 3/20/2018 12:59 AM, Kani, Toshi wrote:
On Mon, 2018-03-19 at 18:10 +0530, Chintan Pandya wrote:
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Freeing of the un-used next level page tables
2) Clearing off the current pud/pmd entry
3) Invalidate
On 3/20/2018 12:31 AM, Kani, Toshi wrote:
On Mon, 2018-03-19 at 18:10 +0530, Chintan Pandya wrote:
This patch ("mm/vmalloc: Add interfaces to free unmapped
page table") adds following 2 interfaces to free the page
table in case we implement huge mapping.
pud_free_pmd_
This series of patches are follow up work (and depends on)
Toshi Kani 's patches "fix memory leak/
panic in ioremap huge pages".
This series of patches are tested on 4.9 kernel with Cortex-A75
based SoC.
Chintan Pandya (3):
ioremap: Update pgtable free interfaces with addr
a
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Freeing of the un-used next level page tables
2) Clearing off the current pud/pmd entry
3) Invalidate TLB which could have previously
valid but not stale entry
Signed-off-by: Chintan Pandya
---
arch/arm64
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8 --
pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 4 ++--
include/a
On 3/15/2018 6:48 PM, Mark Rutland wrote:
On Thu, Mar 15, 2018 at 06:15:05PM +0530, Chintan Pandya wrote:
Implement pud_free_pmd_page() and pmd_free_pte_page().
Make sure, that they are indeed a page table before
taking them to free.
As mentioned on the prior patch, if the tables we&#x
1 - 100 of 172 matches
Mail list logo
