| Message ID | cover.1646847561.git.christophe.leroy@csgroup.eu (mailing list archive) |
|---|---|
| Headers | show |
| Series | Convert powerpc to default topdown mmap layout (v8) | expand |
Hi Michael, hi Andrew Le 09/03/2022 à 18:44, Christophe Leroy a écrit : > Rebased on top of powerpc/next branch > > This series converts powerpc to default topdown mmap layout. > > powerpc requires its own arch_get_unmapped_area() only when > slices are needed, which is only for book3s/64. First part of > the series moves slices into book3s/64 specific directories > and cleans up other subarchitectures. > > Last part converts to default topdown mmap layout. > > A small modification is done to core mm to allow > powerpc to still provide its own arch_randomize_brk() > > Another modification is done to core mm to allow powerpc > to use generic versions of get_unmapped_area functions for Radix > while still providing its own implementation for Hash, the > selection between Radix and Hash being doing at runtime. > > Last modification to core mm is to give len and flags to > arch_get_mmap_end(). > > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> What's the way forward for this series ? Patches 1 has been merged in PCI tree. Patches 2 to 5 are core mm, patch 5 being a fix. Then patches 6 to 14 are powerpc. What will be the merge strategy ? I guess it's a bit late to get it through powerpc tree, so I was just wondering whether we could get patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? Thanks Christophe > > Changes in v8: > - Moved patch "sizes.h: Add SZ_1T macro" up from which is already in linux-next but not in Linus tree yet. > - Rebased on today's powerpc/next > > Changes in v7: > - Taken into account comments from Catalin (patches 3 and 4) > > Changes in v6: > - New patch (patch 4) to take arch_get_mmap_base() and arch_get_mmap_end() into account in generic hugetlb_get_unmapped_area() > - Get back arch_randomize_brk() simplification as it relies on default topdown mmap layout. > - Fixed precedence between || and && in powerpc's arch_get_mmap_end() (patch 9) > > Changes in v5: > - Added patch 3 > - Added arch_get_mmap_base() and arch_get_mmap_end() to patch 7 to better match original powerpc behaviour > - Switched patched 10 and 11 and performed full randomisation in patch 10 just before switching to default implementation, as suggested by Nic. > > Changes in v4: > - Move arch_randomize_brk() simplification out of this series > - Add a change to core mm to enable using generic implementation > while providing arch specific one at the same time. > - Reworked radix get_unmapped_area to use generic implementation > - Rebase on top of Nic's series v6 > > Changes in v3: > - Fixed missing <linux/elf-randomize.h> in last patch > - Added a patch to move SZ_1T out of drivers/pci/controller/pci-xgene.c > > Changes in v2: > - Moved patch 4 before patch 2 > - Make generic arch_randomize_brk() __weak > - Added patch 9 > > Christophe Leroy (14): > sizes.h: Add SZ_1T macro > mm: Allow arch specific arch_randomize_brk() with > CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT > mm, hugetlbfs: Allow an arch to always use generic versions of > get_unmapped_area functions > mm: Add len and flags parameters to arch_get_mmap_end() > mm, hugetlbfs: Allow for "high" userspace addresses > powerpc/mm: Move vma_mmu_pagesize() > powerpc/mm: Make slice specific to book3s/64 > powerpc/mm: Remove CONFIG_PPC_MM_SLICES > powerpc/mm: Use generic_get_unmapped_area() and call it from > arch_get_unmapped_area() > powerpc/mm: Use generic_hugetlb_get_unmapped_area() > powerpc/mm: Move get_unmapped_area functions to slice.c > powerpc/mm: Enable full randomisation of memory mappings > powerpc/mm: Convert to default topdown mmap layout > powerpc: Simplify and move arch_randomize_brk() > > arch/arm64/include/asm/processor.h | 4 +- > arch/powerpc/Kconfig | 2 +- > arch/powerpc/include/asm/book3s/64/hugetlb.h | 4 - > arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 + > arch/powerpc/include/asm/book3s/64/mmu.h | 6 - > arch/powerpc/include/asm/book3s/64/slice.h | 24 ++ > arch/powerpc/include/asm/hugetlb.h | 2 +- > arch/powerpc/include/asm/paca.h | 7 - > arch/powerpc/include/asm/page.h | 1 - > arch/powerpc/include/asm/processor.h | 2 - > arch/powerpc/include/asm/slice.h | 46 ---- > arch/powerpc/include/asm/task_size_64.h | 8 + > arch/powerpc/kernel/paca.c | 5 - > arch/powerpc/kernel/process.c | 41 --- > arch/powerpc/mm/Makefile | 3 +- > arch/powerpc/mm/book3s64/Makefile | 2 +- > arch/powerpc/mm/book3s64/hash_utils.c | 33 ++- > arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 55 ---- > arch/powerpc/mm/{ => book3s64}/slice.c | 71 ++++- > arch/powerpc/mm/hugetlbpage.c | 34 --- > arch/powerpc/mm/mmap.c | 256 ------------------ > arch/powerpc/mm/nohash/mmu_context.c | 9 - > arch/powerpc/mm/nohash/tlb.c | 4 - > arch/powerpc/platforms/Kconfig.cputype | 4 - > drivers/pci/controller/pci-xgene.c | 1 - > fs/hugetlbfs/inode.c | 26 +- > include/linux/hugetlb.h | 5 + > include/linux/sched/mm.h | 17 ++ > include/linux/sizes.h | 2 + > mm/mmap.c | 43 +-- > mm/util.c | 2 +- > 31 files changed, 185 insertions(+), 535 deletions(-) > delete mode 100644 arch/powerpc/include/asm/slice.h > rename arch/powerpc/mm/{ => book3s64}/slice.c (91%) > delete mode 100644 arch/powerpc/mm/mmap.c >
Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Hi Michael, hi Andrew > > Le 09/03/2022 à 18:44, Christophe Leroy a écrit : >> Rebased on top of powerpc/next branch >> >> This series converts powerpc to default topdown mmap layout. >> >> powerpc requires its own arch_get_unmapped_area() only when >> slices are needed, which is only for book3s/64. First part of >> the series moves slices into book3s/64 specific directories >> and cleans up other subarchitectures. >> >> Last part converts to default topdown mmap layout. >> >> A small modification is done to core mm to allow >> powerpc to still provide its own arch_randomize_brk() >> >> Another modification is done to core mm to allow powerpc >> to use generic versions of get_unmapped_area functions for Radix >> while still providing its own implementation for Hash, the >> selection between Radix and Hash being doing at runtime. >> >> Last modification to core mm is to give len and flags to >> arch_get_mmap_end(). >> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> > > What's the way forward for this series ? It's a bit of a tricky series. > Patches 1 has been merged in PCI tree. That's fine I guess, it can go into v5.18, it's only patch 14 that depends on it. > Patches 2 to 5 are core mm, patch 5 being a fix. A fix for arm64 even, just to complicate things :) > Then patches 6 to 14 are powerpc. With a fairly sizable diffstat, ie. likely to conflict. > What will be the merge strategy ? I guess it's a bit late to get it > through powerpc tree, so I was just wondering whether we could get > patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? Yeah I didn't pick it up because the mm changes don't have many acks and I'm always nervous about carrying generic mm changes. It would be my preference if Andrew could take 2-5 through mm for v5.18, but it is quite late, so I'm not sure how he will feel about that. Arguably 2, 3, 4 do very little. It's only patch 5 that has much effect, and it has a reviewed-by from Catalin at least. cheers
On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote: > > What will be the merge strategy ? I guess it's a bit late to get it > > through powerpc tree, so I was just wondering whether we could get > > patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? > > Yeah I didn't pick it up because the mm changes don't have many acks and > I'm always nervous about carrying generic mm changes. > > It would be my preference if Andrew could take 2-5 through mm for v5.18, > but it is quite late, so I'm not sure how he will feel about that. 5.18 isn't a problem. Perhaps you meant 5.17, which would be real tough. Can we take a look after 5.18-rc1?
Hi Andrew, Le 11/03/2022 à 05:49, Andrew Morton a écrit : > On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote: > >>> What will be the merge strategy ? I guess it's a bit late to get it >>> through powerpc tree, so I was just wondering whether we could get >>> patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? >> >> Yeah I didn't pick it up because the mm changes don't have many acks and >> I'm always nervous about carrying generic mm changes. >> >> It would be my preference if Andrew could take 2-5 through mm for v5.18, >> but it is quite late, so I'm not sure how he will feel about that. > > 5.18 isn't a problem. Perhaps you meant 5.17, which would be real tough. > > Can we take a look after 5.18-rc1? 5.18-rc1 was released last night. Can you take patchs 2-5 as they are, or do you prefer I resend them to yourself as a standalone series ? Thanks Christophe
Hi Andrew, Le 04/04/2022 à 07:22, Christophe Leroy a écrit : > Hi Andrew, > > Le 11/03/2022 à 05:49, Andrew Morton a écrit : >> On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman >> <mpe@ellerman.id.au> wrote: >> >>>> What will be the merge strategy ? I guess it's a bit late to get it >>>> through powerpc tree, so I was just wondering whether we could get >>>> patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? >>> >>> Yeah I didn't pick it up because the mm changes don't have many acks and >>> I'm always nervous about carrying generic mm changes. >>> >>> It would be my preference if Andrew could take 2-5 through mm for v5.18, >>> but it is quite late, so I'm not sure how he will feel about that. >> >> 5.18 isn't a problem. Perhaps you meant 5.17, which would be real tough. >> >> Can we take a look after 5.18-rc1? > > 5.18-rc1 was released last night. > > Can you take patchs 2-5 as they are, or do you prefer I resend them to > yourself as a standalone series ? > Are you expecting anything from me ? Do you need a resend of those 4 patches as a standalone series ? Thanks Christiphe
Andrew Morton <akpm@linux-foundation.org> writes: > On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote: > >> > What will be the merge strategy ? I guess it's a bit late to get it >> > through powerpc tree, so I was just wondering whether we could get >> > patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? >> >> Yeah I didn't pick it up because the mm changes don't have many acks and >> I'm always nervous about carrying generic mm changes. >> >> It would be my preference if Andrew could take 2-5 through mm for v5.18, >> but it is quite late, so I'm not sure how he will feel about that. > > 5.18 isn't a problem. Perhaps you meant 5.17, which would be real tough. Sorry, missed your reply. > Can we take a look after 5.18-rc1? Yes :) cheers
Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Le 04/04/2022 à 07:22, Christophe Leroy a écrit : >> Le 11/03/2022 à 05:49, Andrew Morton a écrit : >>> On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman >>> <mpe@ellerman.id.au> wrote: >>> >>>>> What will be the merge strategy ? I guess it's a bit late to get it >>>>> through powerpc tree, so I was just wondering whether we could get >>>>> patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? >>>> >>>> Yeah I didn't pick it up because the mm changes don't have many acks and >>>> I'm always nervous about carrying generic mm changes. >>>> >>>> It would be my preference if Andrew could take 2-5 through mm for v5.18, >>>> but it is quite late, so I'm not sure how he will feel about that. >>> >>> 5.18 isn't a problem. Perhaps you meant 5.17, which would be real tough. >>> >>> Can we take a look after 5.18-rc1? >> >> 5.18-rc1 was released last night. >> >> Can you take patchs 2-5 as they are, or do you prefer I resend them to >> yourself as a standalone series ? > > Are you expecting anything from me ? Do you need a resend of those 4 > patches as a standalone series ? I think that's probably best, saves akpm having to extract the patches from the series. cheers
Rebased on top of powerpc/next branch This series converts powerpc to default topdown mmap layout. powerpc requires its own arch_get_unmapped_area() only when slices are needed, which is only for book3s/64. First part of the series moves slices into book3s/64 specific directories and cleans up other subarchitectures. Last part converts to default topdown mmap layout. A small modification is done to core mm to allow powerpc to still provide its own arch_randomize_brk() Another modification is done to core mm to allow powerpc to use generic versions of get_unmapped_area functions for Radix while still providing its own implementation for Hash, the selection between Radix and Hash being doing at runtime. Last modification to core mm is to give len and flags to arch_get_mmap_end(). Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Changes in v8: - Moved patch "sizes.h: Add SZ_1T macro" up from which is already in linux-next but not in Linus tree yet. - Rebased on today's powerpc/next Changes in v7: - Taken into account comments from Catalin (patches 3 and 4) Changes in v6: - New patch (patch 4) to take arch_get_mmap_base() and arch_get_mmap_end() into account in generic hugetlb_get_unmapped_area() - Get back arch_randomize_brk() simplification as it relies on default topdown mmap layout. - Fixed precedence between || and && in powerpc's arch_get_mmap_end() (patch 9) Changes in v5: - Added patch 3 - Added arch_get_mmap_base() and arch_get_mmap_end() to patch 7 to better match original powerpc behaviour - Switched patched 10 and 11 and performed full randomisation in patch 10 just before switching to default implementation, as suggested by Nic. Changes in v4: - Move arch_randomize_brk() simplification out of this series - Add a change to core mm to enable using generic implementation while providing arch specific one at the same time. - Reworked radix get_unmapped_area to use generic implementation - Rebase on top of Nic's series v6 Changes in v3: - Fixed missing <linux/elf-randomize.h> in last patch - Added a patch to move SZ_1T out of drivers/pci/controller/pci-xgene.c Changes in v2: - Moved patch 4 before patch 2 - Make generic arch_randomize_brk() __weak - Added patch 9 Christophe Leroy (14): sizes.h: Add SZ_1T macro mm: Allow arch specific arch_randomize_brk() with CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT mm, hugetlbfs: Allow an arch to always use generic versions of get_unmapped_area functions mm: Add len and flags parameters to arch_get_mmap_end() mm, hugetlbfs: Allow for "high" userspace addresses powerpc/mm: Move vma_mmu_pagesize() powerpc/mm: Make slice specific to book3s/64 powerpc/mm: Remove CONFIG_PPC_MM_SLICES powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area() powerpc/mm: Use generic_hugetlb_get_unmapped_area() powerpc/mm: Move get_unmapped_area functions to slice.c powerpc/mm: Enable full randomisation of memory mappings powerpc/mm: Convert to default topdown mmap layout powerpc: Simplify and move arch_randomize_brk() arch/arm64/include/asm/processor.h | 4 +- arch/powerpc/Kconfig | 2 +- arch/powerpc/include/asm/book3s/64/hugetlb.h | 4 - arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 + arch/powerpc/include/asm/book3s/64/mmu.h | 6 - arch/powerpc/include/asm/book3s/64/slice.h | 24 ++ arch/powerpc/include/asm/hugetlb.h | 2 +- arch/powerpc/include/asm/paca.h | 7 - arch/powerpc/include/asm/page.h | 1 - arch/powerpc/include/asm/processor.h | 2 - arch/powerpc/include/asm/slice.h | 46 ---- arch/powerpc/include/asm/task_size_64.h | 8 + arch/powerpc/kernel/paca.c | 5 - arch/powerpc/kernel/process.c | 41 --- arch/powerpc/mm/Makefile | 3 +- arch/powerpc/mm/book3s64/Makefile | 2 +- arch/powerpc/mm/book3s64/hash_utils.c | 33 ++- arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 55 ---- arch/powerpc/mm/{ => book3s64}/slice.c | 71 ++++- arch/powerpc/mm/hugetlbpage.c | 34 --- arch/powerpc/mm/mmap.c | 256 ------------------ arch/powerpc/mm/nohash/mmu_context.c | 9 - arch/powerpc/mm/nohash/tlb.c | 4 - arch/powerpc/platforms/Kconfig.cputype | 4 - drivers/pci/controller/pci-xgene.c | 1 - fs/hugetlbfs/inode.c | 26 +- include/linux/hugetlb.h | 5 + include/linux/sched/mm.h | 17 ++ include/linux/sizes.h | 2 + mm/mmap.c | 43 +-- mm/util.c | 2 +- 31 files changed, 185 insertions(+), 535 deletions(-) delete mode 100644 arch/powerpc/include/asm/slice.h rename arch/powerpc/mm/{ => book3s64}/slice.c (91%) delete mode 100644 arch/powerpc/mm/mmap.c