Re: WARN: Interrupts were enabled early [bisected cfeb6ae8bcb9 ("maple_tree: disable mas_wr_append() when other readers are possible")]

* Christophe Leroy [230912 06:56]: > Hi, > > With pmac32_defconfig on QEMU I get the following WARN with 6.6-rc1 > > Bisected to cfeb6ae8bcb9 ("maple_tree: disable mas_wr_append() when > other readers are possible") > > I have absolutely no idea what it can be, do you ? Please see the discuss

Re: [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible

3e6a7e5 Mon Sep 17 00:00:00 2001 From: "Liam R. Howlett" Date: Tue, 12 Sep 2023 13:45:29 -0400 Subject: [PATCH] init/main: Clear boot task idle flag Initial booting was setting the task flag to idle (PF_IDLE) by the call path sched_init() -> init_idle(). Having the task idle and call

Re: [Bisected] PowerMac G4 getting "BUG: Unable to handle kernel data access on write at 0x00001ff0" at boot with CONFIG_VMAP_STACK=y on kernels 6.5.x (regression over 6.4.x)

isected to the same commit [1]. Can you try applying this fix [2] which is on its way upstream? [1] https://lore.kernel.org/linux-mm/3f86d58e-7f36-c6b4-c43a-2a7bcffd...@linux-m68k.org/ [2] https://lore.kernel.org/lkml/2023091517.2835306-1-liam.howl...@oracle.com/ > > > The bisect reveale

Re: [Bisected] PowerMac G4 getting "BUG: Unable to handle kernel data access on write at 0x00001ff0" at boot with CONFIG_VMAP_STACK=y on kernels 6.5.x (regression over 6.4.x)

[3540] 0x3540 > > Code: 39490999 7d4901a4 39290aaa 7d2a01a4 4c00012c 4b20 9421ffe0 > > 7c08002a6 3d20c0d4 93e1001c 90010024 83e95278 <943f1ff0> 7fe1fb78 48840c6d > > 8021 > > ---[ end trace ]--- > > > > Kernel panic - not s

Re: [PATCH 39/41] kernel/fork: throttle call_rcu() calls in vm_area_free

* Matthew Wilcox [230120 11:50]: > On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote: > > On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan > > wrote: > > > > > > On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote: > > > > > > > > On Thu 19-01-23 10:52:03, Suren Baghdasaryan

Re: [PATCH 39/41] kernel/fork: throttle call_rcu() calls in vm_area_free

* Suren Baghdasaryan [230120 12:50]: > On Fri, Jan 20, 2023 at 9:32 AM Matthew Wilcox wrote: > > > > On Fri, Jan 20, 2023 at 09:17:46AM -0800, Suren Baghdasaryan wrote: > > > On Fri, Jan 20, 2023 at 9:08 AM Liam R. Howlett > > > wrote: > > >

Re: [PATCH 39/41] kernel/fork: throttle call_rcu() calls in vm_area_free

* Michal Hocko [230123 15:00]: > On Mon 23-01-23 19:30:43, Matthew Wilcox wrote: > > On Mon, Jan 23, 2023 at 08:18:37PM +0100, Michal Hocko wrote: > > > On Mon 23-01-23 18:23:08, Matthew Wilcox wrote: > > > > On Mon, Jan 23, 2023 at 09:46:20AM -0800, Suren Baghdasaryan wrote: > > > [...] > > > > >

Re: [PATCH v4 4/7] mm: replace vma->vm_flags direct modifications with modifier calls

* Suren Baghdasaryan [230126 14:38]: > Replace direct modifications to vma->vm_flags with calls to modifier > functions to be able to track flag changes and to keep vma locking > correctness. > That was long, but it all looks good! Reviewed-by: Liam R. Howlett > Si

Re: [PATCH v3 21/35] mm/mmap: write-lock adjacent VMAs if they can grow into unmapped area

First, sorry I didn't see this before v3.. * Suren Baghdasaryan [230216 00:18]: > While unmapping VMAs, adjacent VMAs might be able to grow into the area > being unmapped. In such cases write-lock adjacent VMAs to prevent this > growth. > > Signed-off-by: Suren Baghdasaryan > --- > mm/mmap.c

Re: [PATCH v3 21/35] mm/mmap: write-lock adjacent VMAs if they can grow into unmapped area

* Suren Baghdasaryan [230216 14:36]: > On Thu, Feb 16, 2023 at 7:34 AM Liam R. Howlett > wrote: > > > > > > First, sorry I didn't see this before v3.. > > Feedback at any time is highly appreciated! > > > > > * Suren Baghdasaryan [230216

Re: [PATCH v3 23/35] mm/mmap: prevent pagefault handler from racing with mmu_notifier registration

* Suren Baghdasaryan [230216 00:18]: > Page fault handlers might need to fire MMU notifications while a new > notifier is being registered. Modify mm_take_all_locks to write-lock all > VMAs and prevent this race with page fault handlers that would hold VMA > locks. VMAs are locked before i_mmap_rw

Re: [PATCH v3 24/35] mm: introduce vma detached flag

Can we change this to active/inactive? I think there is potential for reusing this functionality to even larger degrees and that name would fit better and would still make sense in this context. ie: vma_mark_active() and vma_mark_inactive() ? * Suren Baghdasaryan [230216 00:18]: > Per-vma loc

Re: [PATCH v3 17/35] mm/mmap: write-lock VMA before shrinking or expanding it

Reviewed-by: Liam R. Howlett * Suren Baghdasaryan [230216 00:18]: > vma_expand and vma_shrink change VMA boundaries. Expansion might also > result in freeing of an adjacent VMA. Write-lock affected VMAs to prevent > concurrent page faults. > > Signed-off-by: Suren Baghdasary

Re: [PATCH v3 17/35] mm/mmap: write-lock VMA before shrinking or expanding it

Wait, I figured a better place to do this. init_multi_vma_prep() should vma_start_write() on any VMA that is passed in.. that we we catch any modifications here & in vma_merge(), which I think is missed in this patch set? * Liam R. Howlett [230223 15:20]: > Reviewed-by: Liam R.

Re: [PATCH v3 17/35] mm/mmap: write-lock VMA before shrinking or expanding it

* Suren Baghdasaryan [230223 16:16]: > On Thu, Feb 23, 2023 at 12:28 PM Liam R. Howlett > wrote: > > > > > > Wait, I figured a better place to do this. > > > > init_multi_vma_prep() should vma_start_write() on any VMA that is passed > > in.. that we we c

Re: [PATCH v3 17/35] mm/mmap: write-lock VMA before shrinking or expanding it

* Suren Baghdasaryan [230223 21:06]: > On Thu, Feb 23, 2023 at 5:46 PM Liam R. Howlett > wrote: > > > > * Suren Baghdasaryan [230223 16:16]: > > > On Thu, Feb 23, 2023 at 12:28 PM Liam R. Howlett > > > wrote: > > > > > >

Re: [PATCH v3 1/3] mm/hugetlb: Allow arch to override and call the weak function

* Aneesh Kumar K.V [170727 02:18]: > For ppc64, we want to call this function when we are not running as guest. > Also, if we failed to allocate hugepages, let the user know. > [...] > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index bc48ee783dd9..a3a7a7e6339e 100644 > --- a/mm/hugetlb.c > +++ b/

Re: [PATCH v3 1/3] mm/hugetlb: Allow arch to override and call the weak function

* Aneesh Kumar K.V [170727 12:12]: > > > On 07/27/2017 08:55 PM, Liam R. Howlett wrote: > > * Aneesh Kumar K.V [170727 02:18]: > > > For ppc64, we want to call this function when we are not running as guest. > > > Also, if we failed to allo

Re: [PATCH v3 16/16] mm/mmap: Move may_expand_vm() check in mmap_region()

* LEROY Christophe [240710 08:59]: > ... > > Assuming the removal of the vdso does not cause the application to seg > fault, then the user visible change is that any vdso call after a failed > mmap(MAP_FIXED) call would result in a seg fault. The only reason it > would f

[PATCH v4 17/21] mm/mmap: Drop arch_unmap() call from all archs

From: "Liam R. Howlett" The arch_unmap call was previously moved above the rbtree modifications in commit 5a28fc94c914 ("x86/mpx, mm/core: Fix recursive munmap() corruption"). The move was motivated by an issue with calling arch_unmap() after the rbtree was modified. Si

Re: [PATCH v4 17/21] mm/mmap: Drop arch_unmap() call from all archs

* LEROY Christophe [240710 17:02]: > > > Le 10/07/2024 à 21:22, Liam R. Howlett a écrit : > > From: "Liam R. Howlett" > > > > The arch_unmap call was previously moved above the rbtree modifications > > in commit 5a28fc94c914 ("x86/mpx, mm/cor

Re: [PATCH v4 17/21] mm/mmap: Drop arch_unmap() call from all archs

* LEROY Christophe [240711 04:28]: > > > Le 11/07/2024 à 01:26, Liam R. Howlett a écrit : > > * LEROY Christophe [240710 17:02]: > >> > >> > >> Le 10/07/2024 à 21:22, Liam R. Howlett a écrit : > >>> From: "Liam R. Howlett" >

[PATCH v5 17/21] mm/mmap: Relocate arch_unmap() to vms_complete_munmap_vmas()

From: "Liam R. Howlett" The arch_unmap call was previously moved above the rbtree modifications in commit 5a28fc94c914 ("x86/mpx, mm/core: Fix recursive munmap() corruption"). The move was motivated by an issue with calling arch_unmap() after the rbtree was modified. Si

Re: [PATCH v5 17/21] mm/mmap: Relocate arch_unmap() to vms_complete_munmap_vmas()

* Lorenzo Stoakes [240722 10:25]: > On Wed, Jul 17, 2024 at 04:07:05PM GMT, Liam R. Howlett wrote: > > From: "Liam R. Howlett" > > > > The arch_unmap call was previously moved above the rbtree modifications > > in commit 5a28fc94c914 ("x86/mpx, mm/c

Re: [PATCH 1/4] mm: Add optional close() to struct vm_special_mapping

* Michael Ellerman [240807 08:41]: > Add an optional close() callback to struct vm_special_mapping. It will > be used, by powerpc at least, to handle unmapping of the VDSO. > > Suggested-by: Linus Torvalds > Signed-off-by: Michael Ellerman > --- > include/linux/mm_types.h | 2 ++ > mm/mmap.c

Re: [PATCH 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap()

* Jeff Xu [240807 11:44]: > On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman wrote: > > > > Add a close() callback to the VDSO special mapping to handle unmapping > > of the VDSO. That will make it possible to remove the arch_unmap() hook > > entirely in a subsequent patch. > > > > Suggested-by: L

Re: [PATCH 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap()

* Jeff Xu [240807 12:37]: > On Wed, Aug 7, 2024 at 8:56 AM Liam R. Howlett > wrote: > > > > * Jeff Xu [240807 11:44]: > > > On Wed, Aug 7, 2024 at 5:41 AM Michael Ellerman > > > wrote: > > > > > > > > Add a close() callback to the

Re: [PATCH 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap()

* Jeff Xu [240807 16:12]: > On Wed, Aug 7, 2024 at 10:11 AM Liam R. Howlett > wrote: > > > > * Jeff Xu [240807 12:37]: > > > On Wed, Aug 7, 2024 at 8:56 AM Liam R. Howlett > > > wrote: > > > > > > > > * Jeff Xu [240807 11:44

Re: [PATCH 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap()

* Linus Torvalds [240807 23:21]: > On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett wrote: > > ... > > That said, I don't love how special powerpc is here. I think more (all?) archs should be doing something like ppc when the vdso is removed. If someone removes the vds

Re: [PATCH 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap()

* Jeff Xu [240807 23:37]: > On Wed, Aug 7, 2024 at 8:21 PM Linus Torvalds > wrote: > > > > On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett > > wrote: > > > > > > Okay, I'm going to try one more time here. You are suggesting to have a > > >

Re: [PATCH 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap()

* Jeff Xu [240808 14:37]: > On Thu, Aug 8, 2024 at 11:08 AM Liam R. Howlett > wrote: > > > > * Jeff Xu [240807 23:37]: > > > On Wed, Aug 7, 2024 at 8:21 PM Linus Torvalds > > > wrote: > > > > > > > > On Wed, 7 Aug 2024 at 16:20, Li

Re: [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping

handling [4], which could be revived. > > See [5] for further discussion. Thank you for tackling this issue, it's much improved. For the whole series: Reviewed-by: Liam R. Howlett > > [1]: commit 83d3f0e90c6c ("powerpc/mm: tracking vDSO remap") > [2]: >

Re: [PATCH 00/16] mm: Introduce MAP_BELOW_HINT

> > To: Arnd Bergmann > To: Paul Walmsley > To: Palmer Dabbelt > To: Albert Ou > To: Catalin Marinas > To: Will Deacon > To: Michael Ellerman > To: Nicholas Piggin > To: Christophe Leroy > To: Naveen N Rao > To: Muchun Song > To: Andrew Morton > To: L

Re: [PATCH 00/16] mm: Introduce MAP_BELOW_HINT

* Dave Hansen [240829 12:54]: > On 8/28/24 13:15, Charlie Jenkins wrote: > > A way to restrict mmap() to return LAM compliant addresses in an entire > > address space also doesn't have to be mutually exclusive with this flag. > > This flag allows for the greatest degree of control from application

Re: [PATCH 1/3] mm: Make arch_get_unmapped_area() take vm_flags by default

for the x86 implementation and the wrapper used > on other architectures this is modified to supply no flags. > > No functional changes. > > Signed-off-by: Mark Brown I don't love sparc32/sparc64 requires a wide screen monitor, but it already broke the 80 char limit. Reviewed-by: L

Re: [PATCH 2/3] mm: Pass vm_flags to generic_get_unmapped_area()

the generic implementation in the radix_enabled() case. > > Signed-off-by: Mark Brown It is interesting that book3s64 ppc is special in this regard. Reviewed-by: Liam R. Howlett > --- > arch/powerpc/mm/book3s64/slice.c | 4 ++-- > include/linux/sched/mm.h

Re: [PATCH 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

* Mark Brown [240902 15:09]: > As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow > stack guard gap during placement") our current mmap() implementation does > not take care to ensure that a new mapping isn't placed with existing > mappings inside it's own guard gaps. This i

Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits

* Catalin Marinas [240906 07:44]: > On Fri, Sep 06, 2024 at 09:55:42AM +, Arnd Bergmann wrote: > > On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote: > > > On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann wrote: > > >> It's also unclear to me how we want this flag to interact with > > >> the existing

Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

* Steven Price [241021 09:23]: > On 09/09/2024 10:46, Kirill A. Shutemov wrote: > > On Thu, Sep 05, 2024 at 10:26:52AM -0700, Charlie Jenkins wrote: > >> On Thu, Sep 05, 2024 at 09:47:47AM +0300, Kirill A. Shutemov wrote: > >>> On Thu, Aug 29, 2024 at 12:15:57AM -0700, Charlie Jenkins wrote: > >>>

Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

* Steven Price [241023 05:31]: > >> * Box64 seems to have a custom allocator based on reading > >> /proc/self/maps to allocate a block of VA space with a low enough > >> address [1] > >> > >> * PHP has code reading /proc/self/maps - I think this is to find a > >> segment which i

Re: [PATCH v3 7/8] execmem: add support for cache of large ROX pages

* Mike Rapoport [240909 02:49]: > From: "Mike Rapoport (Microsoft)" > > Using large pages to map text areas reduces iTLB pressure and improves > performance. > > Extend execmem_alloc() with an ability to use huge pages with ROX > permissions as a cache for smaller allocations. > > To populate

Re: [PATCH] xarray: port tests to kunit

* Geert Uytterhoeven [250130 08:26]: > Hi Liam, > > On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett wrote: > > * Geert Uytterhoeven [250130 03:21]: > > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett > > > wrote: > > > > I've never used the k

Re: [PATCH] xarray: port tests to kunit

* Geert Uytterhoeven [250130 09:25]: > Hi Liam, Hi Geert, I'd like to say sorry for getting upset about this. > > On Thu, 30 Jan 2025 at 15:06, Liam R. Howlett wrote: > > > > I'll await your patch to link all this together. Please Cc the authors. > >

Re: [PATCH] xarray: port tests to kunit

* Geert Uytterhoeven [250130 03:21]: > Hi Liam, > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett wrote: > > I've never used the kunit testing of xarray and have used the userspace > > testing instead, so I can't speak to the obscure invocation as both >

Re: [PATCH mm-unstable v2 06/16] mm: csky: Introduce arch_mmap_hint()

* Kalesh Singh [241211 18:28]: > Introduce csky arch_mmap_hint() and define HAVE_ARCH_MMAP_HINT. > This is a preparatory patch, no functional change is introduced. This also looks like it has changed the validation order and potentially introduced functional changes? All these stem from the same

Re: [PATCH mm-unstable v2 05/16] mm: arc: Use generic_mmap_hint()

* Kalesh Singh [241211 18:28]: > Introduce arc arch_mmap_hint() and define HAVE_ARCH_MMAP_HINT. > This is a preparatory patch, no functional change is introduced. You have changed the order of the map fixed check and the len check. I *think* what you have done is correct, but your comment is cer

Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()

+ Lorenzo Can you please Cc the people listed in the maintainers on the files you are submitting against? You seemed to Cc everyone but the mmap.c file maintainers? * Kalesh Singh [241211 18:28]: > Hi all, > > This is v2 othe the arch_mmap_hint() series. > > Changes in v2: > - MAP_FIXED

Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()

* Lorenzo Stoakes [241213 10:16]: > On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote: > > On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes > > wrote: ... > > > > On the technical side, Liam is right that the copy-pasted arch code > > has inconsistencies (missing checks, order of chec

Re: [PATCH] xarray: port tests to kunit

* Tamir Duberstein [250129 16:29]: > On Wed, Jan 29, 2025 at 4:26 PM Liam R. Howlett > wrote: > > > > * Sidhartha Kumar [250129 16:02]: > > > + Liam, Matthew > > > > + linux-mm > > > > Thank you Sid. > > > > > > > >

Re: [PATCH] xarray: port tests to kunit

* Sidhartha Kumar [250129 16:02]: > + Liam, Matthew + linux-mm Thank you Sid. > > Hello, > > I believe this patch needs to be reverted for now as it breaks the > user-space build of /tools/testing/radix-tree with: > > In file included from xarray.c:11: > ../../../lib/test_xarray.c:9:10: fata