Message ID | 20190116085035.29729-1-aneesh.kumar@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | NestMMU pte upgrade workaround for mprotect | expand |
Andrew, How do you want to merge this? Michael Ellerman suggests this should go via -mm tree. -aneesh "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes: > We can upgrade pte access (R -> RW transition) via mprotect. We need > to make sure we follow the recommended pte update sequence as outlined in > commit bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle nest MMU hang") > for such updates. This patch series do that. > > Changes from V4: > * Drop EXPORT_SYMBOL > > Changes from V3: > * Build fix for x86 > > Changes from V2: > * Update commit message for patch 4 > * use radix tlb flush routines directly. > > Changes from V1: > * Restrict ths only for R->RW upgrade. We don't need to do this for Autonuma > * Restrict this only for radix translation mode. > > > Aneesh Kumar K.V (5): > mm: Update ptep_modify_prot_start/commit to take vm_area_struct as arg > mm: update ptep_modify_prot_commit to take old pte value as arg > arch/powerpc/mm: Nest MMU workaround for mprotect RW upgrade. > mm/hugetlb: Add prot_modify_start/commit sequence for hugetlb update > arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW > upgrade > > arch/powerpc/include/asm/book3s/64/hugetlb.h | 12 ++++++++++ > arch/powerpc/include/asm/book3s/64/pgtable.h | 18 ++++++++++++++ > arch/powerpc/include/asm/book3s/64/radix.h | 4 ++++ > arch/powerpc/mm/hugetlbpage-hash64.c | 25 ++++++++++++++++++++ > arch/powerpc/mm/hugetlbpage-radix.c | 17 +++++++++++++ > arch/powerpc/mm/pgtable-book3s64.c | 25 ++++++++++++++++++++ > arch/powerpc/mm/pgtable-radix.c | 18 ++++++++++++++ > arch/s390/include/asm/pgtable.h | 5 ++-- > arch/s390/mm/pgtable.c | 8 ++++--- > arch/x86/include/asm/paravirt.h | 13 +++++----- > arch/x86/include/asm/paravirt_types.h | 5 ++-- > arch/x86/xen/mmu.h | 4 ++-- > arch/x86/xen/mmu_pv.c | 8 +++---- > fs/proc/task_mmu.c | 8 ++++--- > include/asm-generic/pgtable.h | 18 +++++++------- > include/linux/hugetlb.h | 20 ++++++++++++++++ > mm/hugetlb.c | 8 ++++--- > mm/memory.c | 8 +++---- > mm/mprotect.c | 6 ++--- > 19 files changed, 189 insertions(+), 41 deletions(-) > > -- > 2.20.1
On Wed, 16 Jan 2019 14:20:30 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote: > We can upgrade pte access (R -> RW transition) via mprotect. We need > to make sure we follow the recommended pte update sequence as outlined in > commit bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle nest MMU hang") > for such updates. This patch series do that. This series is at v5 and has no recorded review activity. Perhaps you cold hunt down some people to help out here?
[patch 1/5]: unreviewed and has unaddressed comments from mpe. [patch 2/5]: ditto [patch 3/5]: ditto [patch 4/5]: seems ready [patch 5/5]: reviewed by mpe, but appears to need more work
Andrew Morton <akpm@linux-foundation.org> writes: > [patch 1/5]: unreviewed and has unaddressed comments from mpe. > [patch 2/5]: ditto > [patch 3/5]: ditto > [patch 4/5]: seems ready > [patch 5/5]: reviewed by mpe, but appears to need more work That was mostly variable naming preferences. I like the christmas tree style not the inverted christmas tree. There is one detail about commit message, which indicate the change may be required by other architecture too. Was not sure whether that needed a commit message update. I didn't send an updated series because after replying to most of them I didn't find a strong request to get the required changes in. If you want me update the series with this variable name ordering and commit message update I can send a new series today. -aneesh
On Wed, 27 Feb 2019 14:28:43 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote: > Andrew Morton <akpm@linux-foundation.org> writes: > > > [patch 1/5]: unreviewed and has unaddressed comments from mpe. > > [patch 2/5]: ditto > > [patch 3/5]: ditto > > [patch 4/5]: seems ready > > [patch 5/5]: reviewed by mpe, but appears to need more work > > That was mostly variable naming preferences. I like the christmas > tree style not the inverted christmas tree. There is one detail about > commit message, which indicate the change may be required by other > architecture too. Was not sure whether that needed a commit message > update. > > I didn't send an updated series because after replying to most of them I > didn't find a strong request to get the required changes in. If you want > me update the series with this variable name ordering and commit message > update I can send a new series today. > OK, minor stuff. The patches have been in -next for a month, which is good but we really should get some review of the first three.