On Mon, 2018-04-30 at 13:00 +0530, Chintan Pandya wrote:
>
> 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
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 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. Free its underlining pmd/pte p
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. Free its underlining pmd/pte page.
This still lacks the page-table synchronization and will thus
On Fri, 2018-04-27 at 09:37 +0200, 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
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 would not comment
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 would not comment. But if the race being
> discussed here whi
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
On Fri, Apr 27, 2018 at 01:39:23PM +0200, Michal Hocko wrote:
> On Fri 27-04-18 09:37:20, j...@8bytes.org wrote:
> [...]
> > So until we make the generic ioremap code in lib/ioremap.c smarter about
> > unmapping/remapping ranges the best solution is making my fix work again
> > by reverting your pa
On Fri 27-04-18 09:37:20, j...@8bytes.org wrote:
[...]
> So until we make the generic ioremap code in lib/ioremap.c smarter about
> unmapping/remapping ranges the best solution is making my fix work again
> by reverting your patch.
Could you reuse the same mmu_gather mechanism as we use in the
zap
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-structure caches. So, PMD cache was
> purged on
On Thu, 2018-04-26 at 22:07 +0200, j...@8bytes.org wrote:
> On Thu, Apr 26, 2018 at 05:49:58PM +, Kani, Toshi wrote:
> > On Thu, 2018-04-26 at 19:23 +0200, j...@8bytes.org wrote:
> > > So the PMD entry you clear can still be in a page-walk cache and this
> > > needs to be flushed too before you
On Thu, Apr 26, 2018 at 05:49:58PM +, Kani, Toshi wrote:
> On Thu, 2018-04-26 at 19:23 +0200, j...@8bytes.org wrote:
> > So the PMD entry you clear can still be in a page-walk cache and this
> > needs to be flushed too before you can free the PTE page. Otherwise
> > page-walks might still go to
On Thu, 2018-04-26 at 19:23 +0200, j...@8bytes.org wrote:
> On Thu, Apr 26, 2018 at 04:21:19PM +, Kani, Toshi wrote:
> > All pages under the pmd had been unmapped and then lazy TLB purged with
> > INVLPG before coming to this code path. Speculation is not allowed to
> > pages without mapping.
On Thu, Apr 26, 2018 at 04:21:19PM +, Kani, Toshi wrote:
> All pages under the pmd had been unmapped and then lazy TLB purged with
> INVLPG before coming to this code path. Speculation is not allowed to
> pages without mapping.
CPUs have not only TLBs, but also page-walk caches which cache
in
On Thu, 2018-04-26 at 16:19 +0200, Joerg Roedel wrote:
> Hi Toshi, Andrew,
>
> this patch(-set) is broken in several ways, please see below.
>
> On Wed, Mar 14, 2018 at 12:01:55PM -0600, Toshi Kani wrote:
> > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which
> > clear a given pu
Hi Toshi, Andrew,
this patch(-set) is broken in several ways, please see below.
On Wed, Mar 14, 2018 at 12:01:55PM -0600, Toshi Kani wrote:
> Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which
> clear a given pud/pmd entry and free up lower level page table(s).
> Address range as
On Thu, 2018-03-15 at 13:09 +0530, Chintan Pandya wrote:
>
> On 3/14/2018 11:31 PM, Toshi Kani wrote:
> > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which
> > clear a given pud/pmd entry and free up lower level page table(s).
> > Address range associated with the pud/pmd entry m
On 3/14/2018 11:31 PM, Toshi Kani wrote:
Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which
clear a given pud/pmd entry and free up lower level page table(s).
Address range associated with the pud/pmd entry must have been purged
by INVLPG.
fixes: e61ce6ade404e ("mm: change ior
19 matches
Mail list logo
