Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
On 09/04/2020 08:56 PM, Gerald Schaefer wrote: > On Fri, 4 Sep 2020 12:18:05 +0530 > Anshuman Khandual wrote: > >> >> >> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: >>> This patch series includes fixes for debug_vm_pgtable test code so that >>> they follow page table updates rules correctly. The first two patches >>> introduce >>> changes w.r.t ppc64. The patches are included in this series for >>> completeness. We can >>> merge them via ppc64 tree if required. >>> >>> Hugetlb test is disabled on ppc64 because that needs larger change to >>> satisfy >>> page table update rules. >>> >>> These tests are broken w.r.t page table update rules and results in kernel >>> crash as below. >>> >>> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304! >>> cpu 0x0: Vector: 700 (Program Check) at [c00c6d1e76c0] >>> pc: c009a5ec: assert_pte_locked+0x14c/0x380 >>> lr: c05c: pte_update+0x11c/0x190 >>> sp: c00c6d1e7950 >>>msr: 82029033 >>> current = 0xc00c6d172c80 >>> paca= 0xc3ba irqmask: 0x03 irq_happened: 0x01 >>> pid = 1, comm = swapper/0 >>> kernel BUG at arch/powerpc/mm/pgtable.c:304! >>> [link register ] c05c pte_update+0x11c/0x190 >>> [c00c6d1e7950] 0001 (unreliable) >>> [c00c6d1e79b0] c05eee14 pte_update+0x44/0x190 >>> [c00c6d1e7a10] c1a2ca9c pte_advanced_tests+0x160/0x3d8 >>> [c00c6d1e7ab0] c1a2d4fc debug_vm_pgtable+0x7e8/0x1338 >>> [c00c6d1e7ba0] c00116ec do_one_initcall+0xac/0x5f0 >>> [c00c6d1e7c80] c19e4fac kernel_init_freeable+0x4dc/0x5a4 >>> [c00c6d1e7db0] c0012474 kernel_init+0x24/0x160 >>> [c00c6d1e7e20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c >>> >>> With DEBUG_VM disabled >>> >>> [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x >>> [ 20.530183] Faulting instruction address: 0xc00df330 >>> cpu 0x33: Vector: 380 (Data SLB Access) at [c00c6d19f700] >>> pc: c00df330: memset+0x68/0x104 >>> lr: c009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0 >>> sp: c00c6d19f990 >>>msr: 82009033 >>>dar: 0 >>> current = 0xc00c6d177480 >>> paca= 0xc0001ec4f400 irqmask: 0x03 irq_happened: 0x01 >>> pid = 1, comm = swapper/0 >>> [link register ] c009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0 >>> [c00c6d19f990] c009f748 >>> hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable) >>> [c00c6d19fa10] c19ebf30 pmd_advanced_tests+0x1f0/0x378 >>> [c00c6d19fab0] c19ed088 debug_vm_pgtable+0x79c/0x1244 >>> [c00c6d19fba0] c00116ec do_one_initcall+0xac/0x5f0 >>> [c00c6d19fc80] c19a4fac kernel_init_freeable+0x4dc/0x5a4 >>> [c00c6d19fdb0] c0012474 kernel_init+0x24/0x160 >>> [c00c6d19fe20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c >>> >>> Changes from v3: >>> * Address review feedback >>> * Move page table depost and withdraw patch after adding pmdlock to avoid >>> bisect failure. >> >> This version >> >> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with >> DEBUG_VM_PGTABLE) >> - Runs on arm64 and x86 without any regression, atleast nothing that I have >> noticed >> - Will be great if this could get tested on s390, arc, riscv, ppc32 >> platforms as well > > When I quickly tested v3, it worked fine, but now it turned out to > only work fine "sometimes", both v3 and v4. I need to look into it > further, but so far it seems related to the hugetlb_advanced_tests(). > > I guess there was already some discussion on this test, but we did > not receive all of the thread(s). Please always add at least > linux-s...@vger.kernel.org and maybe myself and Vasily Gorbik > > for further discussions. IIRC, the V3 series previously had all these addresses copied properly but this version once again missed copying all required addresses. > > That being said, sorry for duplications, this might already have been > discussed. Preliminary analysis showed that it only seems to go wrong > for certain random vaddr values. I cannot make any sense of that yet, > but what seems strange to me is that the hugetlb_advanced_tests() > take a (real) pte_t pointer as input, and also use that for all > kinds of operations (set_huge_pte_at, huge_ptep_get_and_clear, etc.). > > Although all the hugetlb code in the kernel is (mis)using pte_t > pointers instead of the correct pmd/pud_t pointers like THP, that > is just for historic reasons. The pointers will actually never point > to a real pte_t (i.e. page table entry), but of course to a pmd > or pud entry, depending on hugepage size. HugeTLB logically operates on a PTE entry irrespective of it's real page table level position. Nonetheless, IIUC, vaddr here should have been aligned to real page table level in which the entry is being mapped currently. > > What is passed in as p
Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
On 09/04/2020 09:31 PM, Gerald Schaefer wrote: > On Fri, 4 Sep 2020 17:26:47 +0200 > Gerald Schaefer wrote: > >> On Fri, 4 Sep 2020 12:18:05 +0530 >> Anshuman Khandual wrote: >> >>> >>> >>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: This patch series includes fixes for debug_vm_pgtable test code so that they follow page table updates rules correctly. The first two patches introduce changes w.r.t ppc64. The patches are included in this series for completeness. We can merge them via ppc64 tree if required. Hugetlb test is disabled on ppc64 because that needs larger change to satisfy page table update rules. These tests are broken w.r.t page table update rules and results in kernel crash as below. [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304! cpu 0x0: Vector: 700 (Program Check) at [c00c6d1e76c0] pc: c009a5ec: assert_pte_locked+0x14c/0x380 lr: c05c: pte_update+0x11c/0x190 sp: c00c6d1e7950 msr: 82029033 current = 0xc00c6d172c80 paca= 0xc3ba irqmask: 0x03 irq_happened: 0x01 pid = 1, comm = swapper/0 kernel BUG at arch/powerpc/mm/pgtable.c:304! [link register ] c05c pte_update+0x11c/0x190 [c00c6d1e7950] 0001 (unreliable) [c00c6d1e79b0] c05eee14 pte_update+0x44/0x190 [c00c6d1e7a10] c1a2ca9c pte_advanced_tests+0x160/0x3d8 [c00c6d1e7ab0] c1a2d4fc debug_vm_pgtable+0x7e8/0x1338 [c00c6d1e7ba0] c00116ec do_one_initcall+0xac/0x5f0 [c00c6d1e7c80] c19e4fac kernel_init_freeable+0x4dc/0x5a4 [c00c6d1e7db0] c0012474 kernel_init+0x24/0x160 [c00c6d1e7e20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c With DEBUG_VM disabled [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x [ 20.530183] Faulting instruction address: 0xc00df330 cpu 0x33: Vector: 380 (Data SLB Access) at [c00c6d19f700] pc: c00df330: memset+0x68/0x104 lr: c009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0 sp: c00c6d19f990 msr: 82009033 dar: 0 current = 0xc00c6d177480 paca= 0xc0001ec4f400 irqmask: 0x03 irq_happened: 0x01 pid = 1, comm = swapper/0 [link register ] c009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0 [c00c6d19f990] c009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable) [c00c6d19fa10] c19ebf30 pmd_advanced_tests+0x1f0/0x378 [c00c6d19fab0] c19ed088 debug_vm_pgtable+0x79c/0x1244 [c00c6d19fba0] c00116ec do_one_initcall+0xac/0x5f0 [c00c6d19fc80] c19a4fac kernel_init_freeable+0x4dc/0x5a4 [c00c6d19fdb0] c0012474 kernel_init+0x24/0x160 [c00c6d19fe20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c Changes from v3: * Address review feedback * Move page table depost and withdraw patch after adding pmdlock to avoid bisect failure. >>> >>> This version >>> >>> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with >>> DEBUG_VM_PGTABLE) >>> - Runs on arm64 and x86 without any regression, atleast nothing that I have >>> noticed >>> - Will be great if this could get tested on s390, arc, riscv, ppc32 >>> platforms as well >> >> When I quickly tested v3, it worked fine, but now it turned out to >> only work fine "sometimes", both v3 and v4. I need to look into it >> further, but so far it seems related to the hugetlb_advanced_tests(). >> >> I guess there was already some discussion on this test, but we did >> not receive all of the thread(s). Please always add at least >> linux-s...@vger.kernel.org and maybe myself and Vasily Gorbik >> >> for further discussions. > > BTW, with myself I mean the new address gerald.schae...@linux.ibm.com. > The old gerald.schae...@de.ibm.com seems to work (again), but is not > very reliable. Sure, noted. > > BTW2, a quick test with this change (so far) made the issues on s390 > go away: > > @@ -1069,7 +1074,7 @@ static int __init debug_vm_pgtable(void) > spin_unlock(ptl); > > #ifndef CONFIG_PPC_BOOK3S_64 > - hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot); > + hugetlb_advanced_tests(mm, vma, (pte_t *) pmdp, pmd_aligned, vaddr, > prot); > #endif > > spin_lock(&mm->page_table_lock); > > That would more match the "pte_t pointer" usage for hugetlb code, > i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned, > but I think the root cause is the pte_t pointer. Ideally, the pte_t pointer used here should be from huge_pte_alloc() not from pte_alloc_map_lock() as the case currently. > > Not entirely sure though if that would real
[kbuild] Re: [PATCH] ARC: [plat-eznps]: Drop support for EZChip NPS platform
Hi Vineet, I love your patch! Yet something to improve: url: https://github.com/0day-ci/linux/commits/Vineet-Gupta/ARC-plat-eznps-Drop-support-for-EZChip-NPS-platform/20200909-121133 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 34d4ddd359dbcdf6c5fb3f85a179243d7a1cb7f8 config: arc-randconfig-r026-20200909 compiler: arc-elf-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc randconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> arch/arc/Kconfig:100: can't open file "arch/arc/plat-eznps/Kconfig" make[2]: *** [scripts/kconfig/Makefile:71: oldconfig] Error 1 make[1]: *** [Makefile:606: oldconfig] Error 2 make: *** [Makefile:185: __sub-make] Error 2 make: Target 'oldconfig' not remade because of errors. -- >> arch/arc/Kconfig:100: can't open file "arch/arc/plat-eznps/Kconfig" make[2]: *** [scripts/kconfig/Makefile:71: olddefconfig] Error 1 make[1]: *** [Makefile:606: olddefconfig] Error 2 make: *** [Makefile:185: __sub-make] Error 2 make: Target 'olddefconfig' not remade because of errors. # https://github.com/0day-ci/linux/commit/80d11f778086417bae2b58423840deaa2e527ce6 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Vineet-Gupta/ARC-plat-eznps-Drop-support-for-EZChip-NPS-platform/20200909-121133 git checkout 80d11f778086417bae2b58423840deaa2e527ce6 vim +100 arch/arc/Kconfig cfdbc2e16e65c1e Vineet Gupta 2013-01-18 96 072eb693904a52d Christian Ruppert 2013-04-12 97 source "arch/arc/plat-tb10x/Kconfig" 556cc1c5f528dcc Alexey Brodkin2014-01-27 98 source "arch/arc/plat-axs10x/Kconfig" cfdbc2e16e65c1e Vineet Gupta 2013-01-18 99 #New platform adds here 966657890e874d3 Noam Camus2015-10-16 @100 source "arch/arc/plat-eznps/Kconfig" a518d63777a4e94 Alexey Brodkin2017-08-15 101 source "arch/arc/plat-hsdk/Kconfig" 93ad700de2abc11 Vineet Gupta 2013-01-22 102 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ kbuild mailing list -- kbu...@lists.01.org To unsubscribe send an email to kbuild-le...@lists.01.org ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
On 09/04/2020 11:23 PM, Gerald Schaefer wrote: > On Fri, 4 Sep 2020 18:01:15 +0200 > Gerald Schaefer wrote: > >> On Fri, 4 Sep 2020 17:26:47 +0200 >> Gerald Schaefer wrote: >> >>> On Fri, 4 Sep 2020 12:18:05 +0530 >>> Anshuman Khandual wrote: >>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: > This patch series includes fixes for debug_vm_pgtable test code so that > they follow page table updates rules correctly. The first two patches > introduce > changes w.r.t ppc64. The patches are included in this series for > completeness. We can > merge them via ppc64 tree if required. > > Hugetlb test is disabled on ppc64 because that needs larger change to > satisfy > page table update rules. > > These tests are broken w.r.t page table update rules and results in kernel > crash as below. > > [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304! > cpu 0x0: Vector: 700 (Program Check) at [c00c6d1e76c0] > pc: c009a5ec: assert_pte_locked+0x14c/0x380 > lr: c05c: pte_update+0x11c/0x190 > sp: c00c6d1e7950 >msr: 82029033 > current = 0xc00c6d172c80 > paca= 0xc3ba irqmask: 0x03 irq_happened: 0x01 > pid = 1, comm = swapper/0 > kernel BUG at arch/powerpc/mm/pgtable.c:304! > [link register ] c05c pte_update+0x11c/0x190 > [c00c6d1e7950] 0001 (unreliable) > [c00c6d1e79b0] c05eee14 pte_update+0x44/0x190 > [c00c6d1e7a10] c1a2ca9c pte_advanced_tests+0x160/0x3d8 > [c00c6d1e7ab0] c1a2d4fc debug_vm_pgtable+0x7e8/0x1338 > [c00c6d1e7ba0] c00116ec do_one_initcall+0xac/0x5f0 > [c00c6d1e7c80] c19e4fac kernel_init_freeable+0x4dc/0x5a4 > [c00c6d1e7db0] c0012474 kernel_init+0x24/0x160 > [c00c6d1e7e20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c > > With DEBUG_VM disabled > > [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x > [ 20.530183] Faulting instruction address: 0xc00df330 > cpu 0x33: Vector: 380 (Data SLB Access) at [c00c6d19f700] > pc: c00df330: memset+0x68/0x104 > lr: c009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0 > sp: c00c6d19f990 >msr: 82009033 >dar: 0 > current = 0xc00c6d177480 > paca= 0xc0001ec4f400 irqmask: 0x03 irq_happened: 0x01 > pid = 1, comm = swapper/0 > [link register ] c009f6d8 > hash__pmdp_huge_get_and_clear+0xe8/0x1b0 > [c00c6d19f990] c009f748 > hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable) > [c00c6d19fa10] c19ebf30 pmd_advanced_tests+0x1f0/0x378 > [c00c6d19fab0] c19ed088 debug_vm_pgtable+0x79c/0x1244 > [c00c6d19fba0] c00116ec do_one_initcall+0xac/0x5f0 > [c00c6d19fc80] c19a4fac kernel_init_freeable+0x4dc/0x5a4 > [c00c6d19fdb0] c0012474 kernel_init+0x24/0x160 > [c00c6d19fe20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c > > Changes from v3: > * Address review feedback > * Move page table depost and withdraw patch after adding pmdlock to avoid > bisect failure. This version - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with DEBUG_VM_PGTABLE) - Runs on arm64 and x86 without any regression, atleast nothing that I have noticed - Will be great if this could get tested on s390, arc, riscv, ppc32 platforms as well >>> >>> When I quickly tested v3, it worked fine, but now it turned out to >>> only work fine "sometimes", both v3 and v4. I need to look into it >>> further, but so far it seems related to the hugetlb_advanced_tests(). >>> >>> I guess there was already some discussion on this test, but we did >>> not receive all of the thread(s). Please always add at least >>> linux-s...@vger.kernel.org and maybe myself and Vasily Gorbik >>> >>> for further discussions. >> >> BTW, with myself I mean the new address gerald.schae...@linux.ibm.com. >> The old gerald.schae...@de.ibm.com seems to work (again), but is not >> very reliable. >> >> BTW2, a quick test with this change (so far) made the issues on s390 >> go away: >> >> @@ -1069,7 +1074,7 @@ static int __init debug_vm_pgtable(void) >> spin_unlock(ptl); >> >> #ifndef CONFIG_PPC_BOOK3S_64 >> - hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot); >> + hugetlb_advanced_tests(mm, vma, (pte_t *) pmdp, pmd_aligned, vaddr, >> prot); >> #endif >> >> spin_lock(&mm->page_table_lock); >> >> That would more match the "pte_t pointer" usage for hugetlb code, >> i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned, >> but I think the root cause is the pte_t pointer. >> >> Not entirely sur
Re: [PATCH] support: user more portable atomic wrappers
* Vineet Gupta via Libc-alpha: > This came up in a nascent arc64 port, lacking gcc atomics for now Can you please change the GCC port to provide atomics instead? It does not make sense to maintain those atomics in many projects separately. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Flushing transparent hugepages
Matthew Wilcox writes:
> PowerPC has special handling of hugetlbfs pages. Well, that's what
> the config option says, but actually it handles THP as well. If
> the config option is enabled.
>
> #ifdef CONFIG_HUGETLB_PAGE
> if (PageCompound(page)) {
> flush_dcache_icache_hugepage(page);
> return;
> }
> #endif
I do have a change posted sometime back to avoid that confusion.
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200320103256.229365-1-aneesh.ku...@linux.ibm.com/
But IIUC we use the head page flags (PG_arch_1) to track whether we need
the flush or not.
>
> By the way, THPs can be mapped askew -- that is, at an offset which
> means you can't use a PMD to map a PMD sized page.
>
> Anyway, we don't really have consensus between the various architectures
> on how to handle either THPs or hugetlb pages. It's not contemplated
> in Documentation/core-api/cachetlb.rst so there's no real surprise
> we've diverged.
>
> What would you _like_ to see? Would you rather flush_dcache_page()
> were called once for each subpage, or would you rather maintain
> the page-needs-flushing state once per compound page? We could also
> introduce flush_dcache_thp() if some architectures would prefer it one
> way and one the other, although that brings into question what to do
> for hugetlbfs pages.
>
> It might not be a bad idea to centralise the handling of all this stuff
> somewhere. Sounds like the kind of thing Arnd would like to do ;-) I'll
> settle for getting enough clear feedback about what the various arch
> maintainers want that I can write a documentation update for cachetlb.rst.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
On Wed, 9 Sep 2020 13:45:48 +0530 Anshuman Khandual wrote: [...] > > > > That would more match the "pte_t pointer" usage for hugetlb code, > > i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned, > > but I think the root cause is the pte_t pointer. > > Ideally, the pte_t pointer used here should be from huge_pte_alloc() > not from pte_alloc_map_lock() as the case currently. Ah, good point. I assumed that this would also always return casted pmd etc. pointers, and never pte pointers. Unfortunately, that doesn't seem to be true for all architectures, e.g. ia64, parisc, (some) powerpc, where they really do a pte_alloc_map() for some reason. I guess that means you cannot simply cast the pmd pointer, as suggested, although I really do not understand how any architecture can work with real ptes for hugepages. But that's fair, s390 also does some things that nobody would expect or understand for other architectures... So, for using huge_pte_alloc() you'd also need some size, maybe iterating over hstates with for_each_hstate() could be an option, if they are already initialized at that point. Then you have the size(s) with huge_page_size(hstate) and can actually call the hugetlb tests for all supported sizes, and with proper pointer from huge_pte_alloc(). ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
On Wed, 09 Sep 2020 11:38:39 +0530 "Aneesh Kumar K.V" wrote: > Gerald Schaefer writes: > > > On Fri, 4 Sep 2020 18:01:15 +0200 > > Gerald Schaefer wrote: > > > > [...] > >> > >> BTW2, a quick test with this change (so far) made the issues on s390 > >> go away: > >> > >> @@ -1069,7 +1074,7 @@ static int __init debug_vm_pgtable(void) > >> spin_unlock(ptl); > >> > >> #ifndef CONFIG_PPC_BOOK3S_64 > >> - hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot); > >> + hugetlb_advanced_tests(mm, vma, (pte_t *) pmdp, pmd_aligned, > >> vaddr, prot); > >> #endif > >> > >> spin_lock(&mm->page_table_lock); > >> > >> That would more match the "pte_t pointer" usage for hugetlb code, > >> i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned, > >> but I think the root cause is the pte_t pointer. > >> > >> Not entirely sure though if that would really be the correct fix. > >> I somehow lost whatever little track I had about what these tests > >> really want to check, and if that would still be valid with that > >> change. > > > > Uh oh, wasn't aware that this (or some predecessor) already went > > upstream, and broke our debug kernel today. > > Not sure i followed the above. Are you finding that s390 kernel crash > after this patch series or the original patchset? As noted in my patch > the hugetlb test is broken and we should fix that. A quick fix is to > comment out that test for s390 too as i have done for PPC64. We see it with both, it basically is broken since there is a hugetlb test using real pte pointers. It doesn't always show, depending on random vaddr, so it slipped through earlier testing. I guess we also would have had one or the other chance to notice that earlier, through better review, or better reading of previous mails. I must admit that I neglected this a bit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
On Wed, 9 Sep 2020 13:38:25 +0530 Anshuman Khandual wrote: > > > On 09/04/2020 08:56 PM, Gerald Schaefer wrote: > > On Fri, 4 Sep 2020 12:18:05 +0530 > > Anshuman Khandual wrote: > > > >> > >> > >> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: > >>> This patch series includes fixes for debug_vm_pgtable test code so that > >>> they follow page table updates rules correctly. The first two patches > >>> introduce > >>> changes w.r.t ppc64. The patches are included in this series for > >>> completeness. We can > >>> merge them via ppc64 tree if required. > >>> > >>> Hugetlb test is disabled on ppc64 because that needs larger change to > >>> satisfy > >>> page table update rules. > >>> > >>> These tests are broken w.r.t page table update rules and results in kernel > >>> crash as below. > >>> > >>> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304! > >>> cpu 0x0: Vector: 700 (Program Check) at [c00c6d1e76c0] > >>> pc: c009a5ec: assert_pte_locked+0x14c/0x380 > >>> lr: c05c: pte_update+0x11c/0x190 > >>> sp: c00c6d1e7950 > >>>msr: 82029033 > >>> current = 0xc00c6d172c80 > >>> paca= 0xc3ba irqmask: 0x03 irq_happened: 0x01 > >>> pid = 1, comm = swapper/0 > >>> kernel BUG at arch/powerpc/mm/pgtable.c:304! > >>> [link register ] c05c pte_update+0x11c/0x190 > >>> [c00c6d1e7950] 0001 (unreliable) > >>> [c00c6d1e79b0] c05eee14 pte_update+0x44/0x190 > >>> [c00c6d1e7a10] c1a2ca9c pte_advanced_tests+0x160/0x3d8 > >>> [c00c6d1e7ab0] c1a2d4fc debug_vm_pgtable+0x7e8/0x1338 > >>> [c00c6d1e7ba0] c00116ec do_one_initcall+0xac/0x5f0 > >>> [c00c6d1e7c80] c19e4fac kernel_init_freeable+0x4dc/0x5a4 > >>> [c00c6d1e7db0] c0012474 kernel_init+0x24/0x160 > >>> [c00c6d1e7e20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c > >>> > >>> With DEBUG_VM disabled > >>> > >>> [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x > >>> [ 20.530183] Faulting instruction address: 0xc00df330 > >>> cpu 0x33: Vector: 380 (Data SLB Access) at [c00c6d19f700] > >>> pc: c00df330: memset+0x68/0x104 > >>> lr: c009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0 > >>> sp: c00c6d19f990 > >>>msr: 82009033 > >>>dar: 0 > >>> current = 0xc00c6d177480 > >>> paca= 0xc0001ec4f400 irqmask: 0x03 irq_happened: 0x01 > >>> pid = 1, comm = swapper/0 > >>> [link register ] c009f6d8 > >>> hash__pmdp_huge_get_and_clear+0xe8/0x1b0 > >>> [c00c6d19f990] c009f748 > >>> hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable) > >>> [c00c6d19fa10] c19ebf30 pmd_advanced_tests+0x1f0/0x378 > >>> [c00c6d19fab0] c19ed088 debug_vm_pgtable+0x79c/0x1244 > >>> [c00c6d19fba0] c00116ec do_one_initcall+0xac/0x5f0 > >>> [c00c6d19fc80] c19a4fac kernel_init_freeable+0x4dc/0x5a4 > >>> [c00c6d19fdb0] c0012474 kernel_init+0x24/0x160 > >>> [c00c6d19fe20] c000cbd0 ret_from_kernel_thread+0x5c/0x6c > >>> > >>> Changes from v3: > >>> * Address review feedback > >>> * Move page table depost and withdraw patch after adding pmdlock to avoid > >>> bisect failure. > >> > >> This version > >> > >> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with > >> DEBUG_VM_PGTABLE) > >> - Runs on arm64 and x86 without any regression, atleast nothing that I > >> have noticed > >> - Will be great if this could get tested on s390, arc, riscv, ppc32 > >> platforms as well > > > > When I quickly tested v3, it worked fine, but now it turned out to > > only work fine "sometimes", both v3 and v4. I need to look into it > > further, but so far it seems related to the hugetlb_advanced_tests(). > > > > I guess there was already some discussion on this test, but we did > > not receive all of the thread(s). Please always add at least > > linux-s...@vger.kernel.org and maybe myself and Vasily Gorbik > > > > for further discussions. > > IIRC, the V3 series previously had all these addresses copied properly > but this version once again missed copying all required addresses. I also had issues with the de.ibm.com address, which might also have made some mails disappear, and others might simply have been overlooked be me. Don't bother, my bad. > > > > > That being said, sorry for duplications, this might already have been > > discussed. Preliminary analysis showed that it only seems to go wrong > > for certain random vaddr values. I cannot make any sense of that yet, > > but what seems strange to me is that the hugetlb_advanced_tests() > > take a (real) pte_t pointer as input, and also use that for all > > kinds of operations (set_huge_pte_at, huge_ptep_get_and_clear, etc.). > > > > Although all the hugetlb code in the kernel is (mis)using pte_t > > pointers instead of the correct pmd/pud_t pointers l
Re: [PATCH] support: user more portable atomic wrappers
On 9/9/20 3:19 AM, Florian Weimer via Libc-alpha wrote: > * Vineet Gupta via Libc-alpha: > >> This came up in a nascent arc64 port, lacking gcc atomics for now > > Can you please change the GCC port to provide atomics instead? Sure, they are added now. > It does not make sense to maintain those atomics in many projects > separately. I agree that gcc atomics should be baseline. I would still propose to carry this patch as it makes code less verbose if nothing else and the wrappers are part of glibc already. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Remove STATFS_IS_STATFS64 conditional as it is zero in all ports
On 08/09/2020 23:48, Vineet Gupta via Libc-alpha wrote:
> From: Vineet Gupta
>
> This seems to be dead code, so remove it.
It could be useful for a possible statfs/statfs64 consolidation, but indeed
it is dead code now.
LGTM, thanks.
Reviewed-by: Adhemerval Zanella
> ---
> sysdeps/unix/sysv/linux/alpha/kernel_stat.h | 1 -
> sysdeps/unix/sysv/linux/fstatfs64.c | 14 --
> sysdeps/unix/sysv/linux/generic/kernel_stat.h | 2 --
> .../unix/sysv/linux/generic/wordsize-32/fstatfs.c | 2 --
> .../unix/sysv/linux/generic/wordsize-32/statfs.c | 2 --
> sysdeps/unix/sysv/linux/hppa/kernel_stat.h| 1 -
> sysdeps/unix/sysv/linux/ia64/kernel_stat.h| 1 -
> sysdeps/unix/sysv/linux/kernel_stat.h | 1 -
> sysdeps/unix/sysv/linux/microblaze/kernel_stat.h | 1 -
> sysdeps/unix/sysv/linux/mips/kernel_stat.h| 1 -
> .../sysv/linux/powerpc/powerpc32/kernel_stat.h| 1 -
> .../sysv/linux/powerpc/powerpc64/kernel_stat.h| 1 -
> .../unix/sysv/linux/s390/s390-64/kernel_stat.h| 1 -
> .../unix/sysv/linux/sparc/sparc32/kernel_stat.h | 1 -
> .../unix/sysv/linux/sparc/sparc64/kernel_stat.h | 1 -
> sysdeps/unix/sysv/linux/statfs64.c| 15 ---
> sysdeps/unix/sysv/linux/x86_64/kernel_stat.h | 1 -
> 17 files changed, 47 deletions(-)
>
> diff --git a/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
> b/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
> index d637e099cfe4..670841140765 100644
> --- a/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
> +++ b/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
> @@ -86,4 +86,3 @@ struct glibc21_stat
>};
>
> #define XSTAT_IS_XSTAT64 1
> -#define STATFS_IS_STATFS64 0
> diff --git a/sysdeps/unix/sysv/linux/fstatfs64.c
> b/sysdeps/unix/sysv/linux/fstatfs64.c
> index 9d22fa228fa5..4a339b548aa7 100644
> --- a/sysdeps/unix/sysv/linux/fstatfs64.c
> +++ b/sysdeps/unix/sysv/linux/fstatfs64.c
> @@ -22,15 +22,6 @@
> #include
> #include
>
> -/* Hide the prototypes for __fstatfs and fstatfs so that GCC will not
> - complain about the different function signatures if they are aliased
> - to __fstat64. If STATFS_IS_STATFS64 is not zero then the statfs and
> - statfs64 structures have an identical layout but different type names. */
> -
> -#if STATFS_IS_STATFS64
> -# define __fstatfs __fstatfs_disable
> -# define fstatfs fstatfs_disable
> -#endif
> #include
>
> #include
> @@ -85,8 +76,3 @@ weak_alias (__fstatfs64, fstatfs64)
>
> #undef __fstatfs
> #undef fstatfs
> -
> -#if STATFS_IS_STATFS64
> -weak_alias (__fstatfs64, __fstatfs)
> -weak_alias (__fstatfs64, fstatfs)
> -#endif
> diff --git a/sysdeps/unix/sysv/linux/generic/kernel_stat.h
> b/sysdeps/unix/sysv/linux/generic/kernel_stat.h
> index 2eed3596c0ed..5a600f188320 100644
> --- a/sysdeps/unix/sysv/linux/generic/kernel_stat.h
> +++ b/sysdeps/unix/sysv/linux/generic/kernel_stat.h
> @@ -26,5 +26,3 @@
> #else
> # define XSTAT_IS_XSTAT64 0
> #endif
> -
> -#define STATFS_IS_STATFS64 0
> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
> index 93d9d94a0a61..bacc1543013a 100644
> --- a/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
> @@ -21,7 +21,6 @@
> #include
> #include
>
> -#if !STATFS_IS_STATFS64
> #include "overflow.h"
>
> /* Return information about the filesystem on which FD resides. */
> @@ -32,4 +31,3 @@ __fstatfs (int fd, struct statfs *buf)
>return rc ?: statfs_overflow (buf);
> }
> weak_alias (__fstatfs, fstatfs)
> -#endif
> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
> index 7421501b4a40..a678e96058ce 100644
> --- a/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
> @@ -21,7 +21,6 @@
> #include
> #include
>
> -#if !STATFS_IS_STATFS64
> #include "overflow.h"
>
> /* Return information about the filesystem on which FILE resides. */
> @@ -33,4 +32,3 @@ __statfs (const char *file, struct statfs *buf)
> }
> libc_hidden_def (__statfs)
> weak_alias (__statfs, statfs)
> -#endif
> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
> b/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
> index a3ac53a1ef2f..9ffa3ba638ea 100644
> --- a/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
> +++ b/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
> @@ -31,4 +31,3 @@ struct kernel_stat {
> #define _HAVE_STAT64_NSEC
>
> #define XSTAT_IS_XSTAT64 0
> -#define STATFS_IS_STATFS64 0
> diff --git a/sysdeps/unix/sysv/linux/ia64/kernel_stat.h
> b/sysdeps/unix/sysv/linux/ia64/kernel_stat.h
> index b38bf741d37b..da8e2a91eff7 100644
> --- a/sysdeps/unix/sysv/linux/ia64/kernel_stat.h
> +++ b/sysdeps/unix/sysv/linux/ia64/kernel_stat.h
> @@ -18,4 +18,3 @@
>
> #define STAT_IS_KERNEL_STAT 1
> #define XSTAT_IS_XS
Re: [PATCH] Remove STATFS_IS_STATFS64 conditional as it is zero in all ports
On 9/9/20 11:36 AM, Adhemerval Zanella via Libc-alpha wrote:
>
>
> On 08/09/2020 23:48, Vineet Gupta via Libc-alpha wrote:
>> From: Vineet Gupta
>>
>> This seems to be dead code, so remove it.
>
> It could be useful for a possible statfs/statfs64 consolidation, but indeed
> it is dead code now.
>
> LGTM, thanks.
>
> Reviewed-by: Adhemerval Zanella
Thx. But it seems this could collide with your series. I'll wait it out and
rebase
after your changes have settled in.
-Vineet
>> ---
>> sysdeps/unix/sysv/linux/alpha/kernel_stat.h | 1 -
>> sysdeps/unix/sysv/linux/fstatfs64.c | 14 --
>> sysdeps/unix/sysv/linux/generic/kernel_stat.h | 2 --
>> .../unix/sysv/linux/generic/wordsize-32/fstatfs.c | 2 --
>> .../unix/sysv/linux/generic/wordsize-32/statfs.c | 2 --
>> sysdeps/unix/sysv/linux/hppa/kernel_stat.h| 1 -
>> sysdeps/unix/sysv/linux/ia64/kernel_stat.h| 1 -
>> sysdeps/unix/sysv/linux/kernel_stat.h | 1 -
>> sysdeps/unix/sysv/linux/microblaze/kernel_stat.h | 1 -
>> sysdeps/unix/sysv/linux/mips/kernel_stat.h| 1 -
>> .../sysv/linux/powerpc/powerpc32/kernel_stat.h| 1 -
>> .../sysv/linux/powerpc/powerpc64/kernel_stat.h| 1 -
>> .../unix/sysv/linux/s390/s390-64/kernel_stat.h| 1 -
>> .../unix/sysv/linux/sparc/sparc32/kernel_stat.h | 1 -
>> .../unix/sysv/linux/sparc/sparc64/kernel_stat.h | 1 -
>> sysdeps/unix/sysv/linux/statfs64.c| 15 ---
>> sysdeps/unix/sysv/linux/x86_64/kernel_stat.h | 1 -
>> 17 files changed, 47 deletions(-)
>>
>> diff --git a/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
>> b/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
>> index d637e099cfe4..670841140765 100644
>> --- a/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
>> +++ b/sysdeps/unix/sysv/linux/alpha/kernel_stat.h
>> @@ -86,4 +86,3 @@ struct glibc21_stat
>>};
>>
>> #define XSTAT_IS_XSTAT64 1
>> -#define STATFS_IS_STATFS64 0
>> diff --git a/sysdeps/unix/sysv/linux/fstatfs64.c
>> b/sysdeps/unix/sysv/linux/fstatfs64.c
>> index 9d22fa228fa5..4a339b548aa7 100644
>> --- a/sysdeps/unix/sysv/linux/fstatfs64.c
>> +++ b/sysdeps/unix/sysv/linux/fstatfs64.c
>> @@ -22,15 +22,6 @@
>> #include
>> #include
>>
>> -/* Hide the prototypes for __fstatfs and fstatfs so that GCC will not
>> - complain about the different function signatures if they are aliased
>> - to __fstat64. If STATFS_IS_STATFS64 is not zero then the statfs and
>> - statfs64 structures have an identical layout but different type names.
>> */
>> -
>> -#if STATFS_IS_STATFS64
>> -# define __fstatfs __fstatfs_disable
>> -# define fstatfs fstatfs_disable
>> -#endif
>> #include
>>
>> #include
>> @@ -85,8 +76,3 @@ weak_alias (__fstatfs64, fstatfs64)
>>
>> #undef __fstatfs
>> #undef fstatfs
>> -
>> -#if STATFS_IS_STATFS64
>> -weak_alias (__fstatfs64, __fstatfs)
>> -weak_alias (__fstatfs64, fstatfs)
>> -#endif
>> diff --git a/sysdeps/unix/sysv/linux/generic/kernel_stat.h
>> b/sysdeps/unix/sysv/linux/generic/kernel_stat.h
>> index 2eed3596c0ed..5a600f188320 100644
>> --- a/sysdeps/unix/sysv/linux/generic/kernel_stat.h
>> +++ b/sysdeps/unix/sysv/linux/generic/kernel_stat.h
>> @@ -26,5 +26,3 @@
>> #else
>> # define XSTAT_IS_XSTAT64 0
>> #endif
>> -
>> -#define STATFS_IS_STATFS64 0
>> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
>> b/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
>> index 93d9d94a0a61..bacc1543013a 100644
>> --- a/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
>> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/fstatfs.c
>> @@ -21,7 +21,6 @@
>> #include
>> #include
>>
>> -#if !STATFS_IS_STATFS64
>> #include "overflow.h"
>>
>> /* Return information about the filesystem on which FD resides. */
>> @@ -32,4 +31,3 @@ __fstatfs (int fd, struct statfs *buf)
>>return rc ?: statfs_overflow (buf);
>> }
>> weak_alias (__fstatfs, fstatfs)
>> -#endif
>> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
>> b/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
>> index 7421501b4a40..a678e96058ce 100644
>> --- a/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
>> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/statfs.c
>> @@ -21,7 +21,6 @@
>> #include
>> #include
>>
>> -#if !STATFS_IS_STATFS64
>> #include "overflow.h"
>>
>> /* Return information about the filesystem on which FILE resides. */
>> @@ -33,4 +32,3 @@ __statfs (const char *file, struct statfs *buf)
>> }
>> libc_hidden_def (__statfs)
>> weak_alias (__statfs, statfs)
>> -#endif
>> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
>> b/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
>> index a3ac53a1ef2f..9ffa3ba638ea 100644
>> --- a/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
>> +++ b/sysdeps/unix/sysv/linux/hppa/kernel_stat.h
>> @@ -31,4 +31,3 @@ struct kernel_stat {
>> #define _HAVE_STAT64_NSEC
>>
>> #define XSTAT_IS_XSTAT64 0
>> -#define STATFS_IS_STATFS64
