[PATCH v2 00/13] mm/gup: Unify hugetlb, part 2

2024-01-03 Thread peterx
From: Peter Xu v2: - Collect acks - Patch 9: - Use READ_ONCE() to fetch pud entry [James] rfc: https://lore.kernel.org/r/20231116012908.392077-1-pet...@redhat.com v1: https://lore.kernel.org/r/20231219075538.414708-1-pet...@redhat.com This is v2 of the series, based on latest mm-unstalbe (85

[PATCH v2 01/13] mm/Kconfig: CONFIG_PGTABLE_HAS_HUGE_LEAVES

2024-01-03 Thread peterx
From: Peter Xu Introduce a config option that will be selected as long as huge leaves are involved in pgtable (thp or hugetlbfs). It would be useful to mark any code with this new config that can process either hugetlb or thp pages in any level that is higher than pte level. Signed-off-by: Pete

[PATCH v2 02/13] mm/hugetlb: Declare hugetlbfs_pagecache_present() non-static

2024-01-03 Thread peterx
From: Peter Xu It will be used outside hugetlb.c soon. Signed-off-by: Peter Xu --- include/linux/hugetlb.h | 9 + mm/hugetlb.c| 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index c1ee640d87b1..e8ed

[PATCH v2 03/13] mm: Provide generic pmd_thp_or_huge()

2024-01-03 Thread peterx
From: Peter Xu ARM defines pmd_thp_or_huge(), detecting either a THP or a huge PMD. It can be a helpful helper if we want to merge more THP and hugetlb code paths. Make it a generic default implementation, only exist when CONFIG_MMU. Arch can overwrite it by defining its own version. For exam

[PATCH v2 04/13] mm: Make HPAGE_PXD_* macros even if !THP

2024-01-03 Thread peterx
From: Peter Xu These macros can be helpful when we plan to merge hugetlb code into generic code. Move them out and define them even if !THP. We actually already defined HPAGE_PMD_NR for other reasons even if !THP. Reorganize these macros. Reviewed-by: Christoph Hellwig Signed-off-by: Peter Xu

[PATCH v2 05/13] mm: Introduce vma_pgtable_walk_{begin|end}()

2024-01-03 Thread peterx
From: Peter Xu Introduce per-vma begin()/end() helpers for pgtable walks. This is a preparation work to merge hugetlb pgtable walkers with generic mm. The helpers need to be called before and after a pgtable walk, will start to be needed if the pgtable walker code supports hugetlb pages. It's

[PATCH v2 06/13] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

2024-01-03 Thread peterx
From: Peter Xu Hugepd format for GUP is only used in PowerPC with hugetlbfs. There are some kernel usage of hugepd (can refer to hugepd_populate_kernel() for PPC_8XX), however those pages are not candidates for GUP. Commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to file-b

[PATCH v2 07/13] mm/gup: Refactor record_subpages() to find 1st small page

2024-01-03 Thread peterx
From: Peter Xu All the fast-gup functions take a tail page to operate, always need to do page mask calculations before feeding that into record_subpages(). Merge that logic into record_subpages(), so that it will do the nth_page() calculation. Signed-off-by: Peter Xu --- mm/gup.c | 25 +++

[PATCH v2 08/13] mm/gup: Handle hugetlb for no_page_table()

2024-01-03 Thread peterx
From: Peter Xu no_page_table() is not yet used for hugetlb code paths. Make it prepared. The major difference here is hugetlb will return -EFAULT as long as page cache does not exist, even if VM_SHARED. See hugetlb_follow_page_mask(). Pass "address" into no_page_table() too, as hugetlb will ne

[PATCH v2 09/13] mm/gup: Cache *pudp in follow_pud_mask()

2024-01-03 Thread peterx
From: Peter Xu Introduce "pud_t pud" in the function, so the code won't dereference *pudp multiple time. Not only because that looks less straightforward, but also because if the dereference really happened, it's not clear whether there can be race to see different *pudp values if it's being mod

[PATCH v2 10/13] mm/gup: Handle huge pud for follow_pud_mask()

2024-01-03 Thread peterx
From: Peter Xu Teach follow_pud_mask() to be able to handle normal PUD pages like hugetlb. Rename follow_devmap_pud() to follow_huge_pud() so that it can process either huge devmap or hugetlb. Move it out of TRANSPARENT_HUGEPAGE_PUD and and huge_memory.c (which relies on CONFIG_THP). In the new

[PATCH v2 11/13] mm/gup: Handle huge pmd for follow_pmd_mask()

2024-01-03 Thread peterx
From: Peter Xu Replace pmd_trans_huge() with pmd_thp_or_huge() to also cover pmd_huge() as long as enabled. FOLL_TOUCH and FOLL_SPLIT_PMD only apply to THP, not yet huge. Since now follow_trans_huge_pmd() can process hugetlb pages, renaming it into follow_huge_pmd() to match what it does. Move

[PATCH v2 12/13] mm/gup: Handle hugepd for follow_page()

2024-01-03 Thread peterx
From: Peter Xu Hugepd is only used in PowerPC so far on 4K page size kernels where hash mmu is used. follow_page_mask() used to leverage hugetlb APIs to access hugepd entries. Teach follow_page_mask() itself on hugepd. With previous refactors on fast-gup gup_huge_pd(), most of the code can be

[PATCH v2 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code

2024-01-03 Thread peterx
From: Peter Xu Now follow_page() is ready to handle hugetlb pages in whatever form, and over all architectures. Switch to the generic code path. Time to retire hugetlb_follow_page_mask(), following the previous retirement of follow_hugetlb_page() in 4849807114b8. There may be a slight differen

Re: [PATCH v2 00/13] mm/gup: Unify hugetlb, part 2

2024-01-03 Thread Christophe Leroy
Le 03/01/2024 à 10:14, pet...@redhat.com a écrit : > From: Peter Xu > > > Test Done > = > > This v1 went through the normal GUP smoke tests over different memory > types on archs (using VM instances): x86_64, aarch64, ppc64le. For > aarch64, tested over 64KB cont_pte huge pages. For

Re: [PATCH v1 1/1] powerpc/powernv: fix up kernel compile issues

2024-01-03 Thread kernel test robot
Hi Luming, kernel test robot noticed the following build errors: [auto build test ERROR on powerpc/next] [also build test ERROR on powerpc/fixes linus/master v6.7-rc8 next-20240103] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to

Re: [PATCH v1 1/1] powerpc/powernv: fix up kernel compile issues

2024-01-03 Thread Christophe Leroy
Hi, Le 02/01/2024 à 03:48, Luming Yu a écrit : > [Vous ne recevez pas souvent de courriers de luming...@shingroup.cn. > Découvrez pourquoi ceci est important à > https://aka.ms/LearnAboutSenderIdentification ] > > up kernel is quite useful to silicon validation, despite > it is rare to be found

Re: [PATCH v2 00/14] Unified cross-architecture kernel-mode FPU API

2024-01-03 Thread Alex Deucher
On Thu, Dec 28, 2023 at 5:11 AM Samuel Holland wrote: > > This series unifies the kernel-mode FPU API across several architectures > by wrapping the existing functions (where needed) in consistently-named > functions placed in a consistent header location, with mostly the same > semantics: they ca

Re: WARNING: No atomic I2C transfer handler for 'i2c-4' at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x178/0x190 (kernel 6.6.X, 6.7-rcX, PowerMac G5 11,2)

2024-01-03 Thread Tor Vic
On 12/22/23 23:01, Erhard Furtner wrote: Greetings! I am getting this on my PowerMac G5 11,2 at reboot on kernels 6.6.X and 6.7-rcX: Hi, this seems to be the same issue as [1], and also referenced in [2]. For now, I have reverted the patch [3] as the huge splats on reboot are really ann

[PATCH 7/8] powerpc: Fix typos

2024-01-03 Thread Bjorn Helgaas
From: Bjorn Helgaas Fix typos, most reported by "codespell arch/powerpc". Only touches comments, no code changes. Signed-off-by: Bjorn Helgaas Cc: Nicholas Piggin Cc: Christophe Leroy Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/boot/Makefile | 4 ++-- arch/powerpc/

Re: [PATCH 7/8] powerpc: Fix typos

2024-01-03 Thread Randy Dunlap
On 1/3/24 15:16, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > Fix typos, most reported by "codespell arch/powerpc". Only touches > comments, no code changes. > > Signed-off-by: Bjorn Helgaas > Cc: Nicholas Piggin > Cc: Christophe Leroy > Cc: linuxppc-dev@lists.ozlabs.org > --- > arch/p