On Thu, 9 Jan 2025 23:05:56 -0800 Dan Williams wrote:
> > - Remove PTE_DEVMAP definitions from Loongarch which were added since
> >this series was initially written.
> [..]
> >
> > base-commit: e25c8d66f6786300b680866c0e0139981273feba
>
> If this is going to go through nvdimm.git I will ne
On Thu, 9 Jan 2025 09:42:14 +0530 Sourabh Jain
wrote:
> Hello Baoquan and Eric,
>
>
> On 12/12/24 08:25, Baoquan he wrote:
> > On 12/10/24 at 02:43pm, Sourabh Jain wrote:
> >> kexec_elf_load() loads an ELF executable and sets the address of the
> >> lowest PT_LOAD section to the address held b
On Tue, 7 Jan 2025 14:42:16 +1100 Alistair Popple wrote:
> Device and FS DAX pages have always maintained their own page
> reference counts without following the normal rules for page reference
> counting. In particular pages are considered free when the refcount
> hits one rather than zero and
On Mon, 30 Dec 2024 17:07:35 +0800 Qi Zheng wrote:
> Changes in v4:
> - remove [PATCH v3 15/17] and [PATCH v3 16/17] (Mike Rapoport)
>(the tlb_remove_page_ptdesc() and tlb_remove_ptdesc() are intermediate
> products of the project: https://kernelnewbies.org/MatthewWilcox/Memdescs,
>
On Mon, 30 Dec 2024 11:12:00 +0800 Qi Zheng wrote:
> > For now struct ptdesc overlaps struct page, but the goal is to have them
> > separate and always operate on struct ptdesc when working with page tables.
>
> OK, so tlb_remove_page_ptdesc() and tlb_remove_ptdesc() are somewhat
> intermediate
On Fri, 20 Dec 2024 17:26:38 +0800 Guo Weikang
wrote:
> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediate
> panic is required. To simplify this behavior and reduce repetitive checks,
> introduce `mem
On Tue, 17 Dec 2024 12:53:22 -0800 Easwar Hariharan
wrote:
> There have been a couple of comments[1][2] that came in after you queued
> the series to mm. Would you rather I send individual patches addressing
> these, or just send a v4 of the entire series (-netdev of course) so you
> can replace
On Mon, 16 Dec 2024 11:55:30 +1100 Alistair Popple wrote:
> The remainder are more -mm focussed. However they do depend on the fs/dax
> cleanups in the first half so the trick would be making sure Andrew only takes
> them if the nvdimm.git changes have made it into -next. I'm happy with either
>
On Thu, 12 Dec 2024 16:40:10 -0500 "Liam R. Howlett"
wrote:
> * 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
On Thu, 12 Dec 2024 22:51:34 + Lorenzo Stoakes
wrote:
> You've fundamentally violated kernel process and etiquette. I'd be more
> forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is
> totally unacceptable. See [0] if you are unsure of how to do so.
This feels excessi
On Tue, 10 Dec 2024 18:41:29 -0800 Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > > I'll just grab everything and see if anyone complains ;)
> > >
> > > I may, if this leads to a conflict :(
> >
> > Ve
On Tue, 10 Dec 2024 17:35:48 -0800 Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > > I have the same question as before: How do you expect these to land?
> > > Do you now have a maintainer who will take all of them?
> > > Or do y
On Tue, 10 Dec 2024 22:02:31 + Easwar Hariharan
wrote:
> This is a series that follows up on my previous series to introduce
> secs_to_jiffies() and convert a few initial users.
Thanks, I added this to mm.git. I suppressed the usual added-to-mm
emails because s many cc's!
I'd ask rele
On Tue, 10 Dec 2024 15:14:22 -0800 Jeff Johnson
wrote:
> On 12/10/2024 2:02 PM, Easwar Hariharan wrote:
> > This is a series that follows up on my previous series to introduce
> > secs_to_jiffies() and convert a few initial users.[1] In the review for
> > that series, Anna-Maria requested conver
On Fri, 11 Oct 2024 20:26:09 +0530 "Ritesh Harjani (IBM)"
wrote:
> cma_init_reserved_mem() checks base and size alignment with
> CMA_MIN_ALIGNMENT_BYTES. However, some users might call this during
> early boot when pageblock_order is 0.
This sounds like "some users" are in error. Please tell u
On Wed, 13 Nov 2024 07:23:43 +0530 Ritesh Harjani (IBM)
wrote:
> "Ritesh Harjani (IBM)" writes:
>
> > cma_init_reserved_mem() checks base and size alignment with
> > CMA_MIN_ALIGNMENT_BYTES. However, some users might call this during
> > early boot when pageblock_order is 0. That means if base
On Sun, 13 Oct 2024 11:43:41 +0300 Mike Rapoport wrote:
> > > The idea is to keep everything together and have execmem_info describe all
> > > that architecture needs.
> >
> > But why? That's pretty different from our normal style of arch hooks,
> > and introduces an indirect call in a securit
On Wed, 9 Oct 2024 21:08:15 +0300 Mike Rapoport wrote:
> Using large pages to map text areas reduces iTLB pressure and improves
> performance.
Are there any measurable performance improvements?
What are the effects of this series upon overall memory consumption?
The lack of acks is a bit surp
On Mon, 02 Sep 2024 21:06:48 +0200 Sven Schnelle wrote:
> So uprobe_clear_state() in the beginning free's the memory area
> containing the vm_special_mapping data, but exit_mmap() uses this
> address later via vma->vm_private_data (which was set in
> _install_special_mapping().
>
> The followin
On Tue, 20 Aug 2024 16:14:29 -0700 Linus Torvalds
wrote:
> Andrew - I think this is good, but there may be other issues lurking.
> Do with it as you see fit,
Hey you know me, I'll merge any old thing if I think it'll help nurture
newbies.
On Mon, 19 Aug 2024 13:16:32 -0700 Linus Torvalds
wrote:
> On Mon, 19 Aug 2024 at 13:15, Linus Torvalds
> wrote:
> >
> > Ok, I did a quick hack-job to remove that disgusting
> > install_special_mapping() legacy case.
> >
> > With this [..]
>
> I forgot to actually attach that "this". Here it i
On Tue, 13 Aug 2024 09:32:07 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> The following commit is also in the mm-hotfixes tree as a different commit
> (but the same patch):
>
> e7a9af8c93aa ("powerpc/mm: Fix size of allocated PGDIR")
>
> This is commit
>
> 6cd04a440f57 ("powerpc/mm: fix s
On Wed, 7 Aug 2024 17:34:10 -0400 Peter Xu wrote:
> The problem is mprotect() will skip the dax 1G PUD while it shouldn't;
> meanwhile it'll dump some bad PUD in dmesg. Both of them look like (corner
> case) bugs to me.. where:
>
> - skipping the 1G pud means mprotect() will succeed even if t
On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu wrote:
>
> Tests
> =
>
> What I did test:
>
> - cross-build tests that I normally cover [1]
>
> - smoke tested on x86_64 the simplest program [2] on dev_dax 1G PUD
> mprotect() using QEMU's nvdimm emulations [3] and ndctl to create
> namespa
On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu wrote:
>
> Dax supports pud pages for a while, but mprotect on puds was missing since
> the start. This series tries to fix that by providing pud handling in
> mprotect(). The goal is to add more types of pud mappings like hugetlb or
> pfnmaps. This
On Fri, 2 Aug 2024 10:49:22 +0100 Jonathan Cameron
wrote:
> > --- a/mm/mm_init.c
> > +++ b/mm/mm_init.c
> > @@ -1838,11 +1838,10 @@ void __init free_area_init(unsigned long
> > *max_zone_pfn)
> >
> > if (!node_online(nid)) {
> > /* Allocator not initialized yet
On Wed, 22 May 2024 16:38:01 -0400 Eric Chanudet wrote:
> x86_64 is already using the node's cpu as maximum threads. Make that the
> default for all archs setting DEFERRED_STRUCT_PAGE_INIT.
>
> This returns to the behavior prior making the function arch-specific
> with commit ecd096506922 ("mm:
On Mon, 15 Apr 2024 14:51:32 -0500 Maxwell Bland wrote:
> ptdump can now note non-leaf descriptor entries, a useful addition for
> debugging table descriptor permissions when working on related code
>
> Signed-off-by: Maxwell Bland
> ---
> arch/arm64/mm/ptdump.c | 6 --
> arch/po
On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> Please review! Also feel free to take the KVM patches through the mm
> tree, as I don't expect any conflicts.
It's mainly a KVM thing and the MM changes are small and simple.
I'd say that the KVM tree would be a better home?
On Wed, 3 Apr 2024 16:37:58 +0800 Kefeng Wang
wrote:
> After VMA lock-based page fault handling enabled, if bad access met
> under per-vma lock, it will fallback to mmap_lock-based handling,
> so it leads to unnessary mmap lock and vma find again. A test from
> lmbench shows 34% improve after th
On Thu, 28 Mar 2024 11:10:59 +0100 David Hildenbrand wrote:
> @Andrew, you properly adjusted the code to remove the
> gup_fast_folio_allowed() call instead of the folio_fast_pin_allowed()
> call, but
>
> (1) the commit subject
> (2) comment for gup_huge_pd()
>
> Still mention folio_fast_pin_a
On Wed, 27 Mar 2024 13:00:43 -0700 Samuel Holland
wrote:
> Now that all previously-supported architectures select
> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
> of the existing list of architectures. It can also take advantage of the
> common kernel-mode FPU API and
On Fri, 26 Jan 2024 14:44:51 +0800 Huang Shijie
wrote:
> During the kernel booting, the generic cpu_to_node() is called too early in
> arm64, powerpc and riscv when CONFIG_NUMA is enabled.
>
> There are at least four places in the common code where
> the generic cpu_to_node() is called before i
On Thu, 21 Mar 2024 18:08:02 -0400 pet...@redhat.com wrote:
> 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
> retiremen
On Thu, 22 Feb 2024 10:47:29 +0530 Hari Bathini wrote:
>
>
> On 22/02/24 2:27 am, Andrew Morton wrote:
> > On Wed, 21 Feb 2024 11:15:00 +0530 Hari Bathini
> > wrote:
> >
> >> On 04/02/24 8:56 am, Baoquan He wrote:
> >>>>> Hope Hari
On Wed, 21 Feb 2024 11:15:00 +0530 Hari Bathini wrote:
> On 04/02/24 8:56 am, Baoquan He wrote:
> >>> Hope Hari and Pingfan can help have a look, see if
> >>> it's doable. Now, I make it either have both kexec and crash enabled, or
> >>> disable both of them altogether.
> >>
> >> Sure. I will tak
On Wed, 21 Feb 2024 22:59:47 +0530 Sourabh Jain
wrote:
> > config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> > - def_bool CRASH_CORE
> > + def_bool CRASH_RESEERVE
>
> %s/CRASH_RESEERVE/CRASH_RESERVE?
Yes, thanks, this has been addressed in a followon fixup patch
in the mm.git tree.
On Mon, 29 Jan 2024 13:43:39 +0530 "Aneesh Kumar K.V"
wrote:
> > return (pud_val(pud) & (_PAGE_PSE|_PAGE_DEVMAP)) == _PAGE_PSE;
> > }
> > #endif
> >
> > #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> > static inline int pud_devmap(pud_t pud)
> > {
> > return !!(pud_val(pud)
On Mon, 22 Jan 2024 22:43:05 -0800 Suren Baghdasaryan wrote:
> The change [1] missed ARM architecture when fixing major fault accounting
> for page fault retry under per-VMA lock. Add missing code to fix ARM
> architecture fault accounting.
>
> [1] 46e714c729c8 ("arch/mm/fault: fix major fault a
(cc Muchun)
On Wed, 10 Jan 2024 14:03:35 +0530 Donet Tom
wrote:
> The kernel sefltest mm/hugepage-vmemmap fails on architectures
> which has different page size other than 4K. In hugepage-vmemmap
> page size used is 4k so the pfn calculation will go wrong on systems
> which has different page si
On Wed, 20 Dec 2023 12:22:29 +0800 Baoquan He wrote:
> Could you help fix the typo in subject?
>
> [PATCH v4 5/7] kexec_file, ricv: print out debugging message if required
>~~~ s/ricv/riscv/
I made that change.
On Fri, 01 Dec 2023 09:39:20 +1100 Michael Ellerman wrote:
> > I am still carrying this patch (it should probably go into the mm
> > tree). Is someone going to pick it up (assuming it is correct)?
>
> I applied it to my next a few days ago, but I must have forgotten to
> push. It's in there now
On Fri, 1 Dec 2023 09:04:39 +1100 Stephen Rothwell
wrote:
> Hi all,
>
> > > diff --git a/arch/powerpc/mm/book3s64/pgtable.c
> > > b/arch/powerpc/mm/book3s64/pgtable.c
> > > index be229290a6a7..3438ab72c346 100644
> > > --- a/arch/powerpc/mm/book3s64/pgtable.c
> > > +++ b/arch/powerpc/mm/book3s
On Thu, 2 Nov 2023 16:03:18 +0800 Baoquan He wrote:
> > > CONFIG_KEXEC_FILE, but still get purgatory code built in which is
> > > totally useless.
> > >
> > > Not sure if I think too much over this.
> >
> > I see your point here, and I would suggest changing the
> > CONFIG_ARCH_SUPPORTS_KEXEC_PU
On Tue, 14 Nov 2023 17:16:57 +0800 Baoquan He wrote:
> This function, being a variant of walk_system_ram_res() introduced in
> commit 8c86e70acead ("resource: provide new functions to walk through
> resources"), walks through a list of all the resources of System RAM
> in reversed order, i.e., fr
On Fri, 10 Nov 2023 02:22:27 + "Daniel Walker (danielwa)"
wrote:
> On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> > On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> >
> > > This release is an up-rev of the v5 patches. No additio
On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a numbe
On Sun, 08 Oct 2023 09:54:22 +1100 Michael Ellerman wrote:
> > I don't know why powerpc's PTE_INDEX_SIZE is variable.
>
> To allow a single vmlinux to boot using either the Hashed Page Table
> MMU, or Radix Tree MMU, which have different page table geometry.
>
> That's a pretty crucial feature
On Fri, 29 Sep 2023 12:44:15 +0100 Ryan Roberts wrote:
> In preparation for adding support for anonymous large folios that are
> smaller than the PMD-size, introduce 2 new sysfs files that will be used
> to control the new behaviours via the transparent_hugepage interface.
> For now, the kernel s
On Thu, 21 Sep 2023 17:19:59 +0100 Ryan Roberts wrote:
> Hi All,
>
> This series fixes a bug in arm64's implementation of set_huge_pte_at(), which
> can result in an unprivileged user causing a kernel panic. The problem was
> triggered when running the new uffd poison mm selftest for HUGETLB mem
On Wed, 26 Jul 2023 10:59:32 +0530 Aneesh Kumar K V
wrote:
> On 7/26/23 12:59 AM, Andrew Morton wrote:
> > On Tue, 25 Jul 2023 00:37:46 +0530 "Aneesh Kumar K.V"
> > wrote:
> >
> >> This patch series implements changes required to support DAX vmemmap
On Tue, 25 Jul 2023 00:37:46 +0530 "Aneesh Kumar K.V"
wrote:
> This patch series implements changes required to support DAX vmemmap
> optimization for ppc64.
Do we have any measurements to help us understand the magnitude
of this optimization?
And any documentation which helps users understand
On Mon, 24 Jul 2023 23:59:27 +0530 "Aneesh Kumar K.V"
wrote:
> Please take this diff on top of this patch when adding this series to
> -mm .
"[10/13] powerpc/book3s64/vmemmap: Switch radix to use a different
vmemmap handling function" has a conflict with "mm: move
is_ioremap_addr() into new hea
On Fri, 21 Jul 2023 18:49:50 +0530 "Aneesh Kumar K.V"
wrote:
> Signed-off-by: Aneesh Kumar K.V
> ---
> This is dependent on patches posted at
> https://lore.kernel.org/linux-mm/20230718024409.95742-1-aneesh.ku...@linux.ibm.com/
It appears that the above-linked series is to be updated, so
would
On Tue, 18 Jul 2023 14:57:12 -0300 Jason Gunthorpe wrote:
> On Tue, Jul 18, 2023 at 05:56:15PM +1000, Alistair Popple wrote:
> > diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> > index b466172..48c81b9 100644
> > --- a/include/asm-generic/tlb.h
> > +++ b/include/asm-generic/t
On Tue, 18 Jul 2023 17:56:17 +1000 Alistair Popple wrote:
> The arch_invalidate_secondary_tlbs() is an architecture specific mmu
> notifier used to keep the TLB of secondary MMUs such as an IOMMU in
> sync with the CPU page tables. Currently it is called from separate
> code paths to the main CPU
On Sat, 8 Jul 2023 10:29:42 -0700 Linus Torvalds
wrote:
> On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
> wrote:
> >
> > The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> > latest patch that does this is this one afaics:
>
> Bah.
>
> Both marking it as broken and the
On Wed, 5 Jul 2023 10:51:57 +0200 "Linux regression tracking (Thorsten
Leemhuis)" wrote:
> >>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
> >>> fix rather than disabling the feature in -stable.
>
> Andrew, how long will you remain in "wait-a-few-days-mode"? Given wha
On Tue, 4 Jul 2023 13:22:54 -0700 Suren Baghdasaryan wrote:
> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton
> wrote:
> >
> > On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH
> > wrote:
> >
> > > > > > > Thanks! I'll investigate this later tod
On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH wrote:
> > > > > Thanks! I'll investigate this later today. After discussing with
> > > > > Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> > > > > the issue is fixed. I'll post a patch shortly.
> > > >
> > > > Posted at:
> > > >
On Sat, 24 Jun 2023 20:22:27 +0530 "Aneesh Kumar K.V"
wrote:
> > 28 files changed, 1032 insertions(+), 77 deletions(-)
> > create mode 100644 Documentation/powerpc/vmemmap_dedup.rst
> >
>
> Michael Ellerman merged some of the ppc64 patches. How do
> you like to merge the mm changes? Do you li
On Thu, 22 Jun 2023 10:40:11 +0200 Petr Mladek wrote:
> On Wed 2023-06-21 16:48:19, Douglas Anderson wrote:
> > The powerpc architecture was the only one that defined
> > arch_trigger_cpumask_backtrace() in asm/nmi.h instead of
> > asm/irq.h. Move it to be consistent.
> >
> > This fixes compile
On Fri, 5 May 2023 16:02:17 + David Laight wrote:
> From: Michael Ellerman
> > Sent: 05 May 2023 04:51
> >
> > Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> > __kfence_alloc() and __kfence_free()"), kfence reports failures in
> > random places at boot on big endian mac
On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas
wrote:
> > It sounds nice in theory. In practice. EXPERT hides too much. When you
> > flip expert, you expose over a 175ish new config options which are
> > hidden behind EXPERT. You don't have to know what you are doing just
> > with the MAX_O
On Mon, 27 Feb 2023 10:47:27 +0100 Marco Elver wrote:
> With appropriate compiler support [1], KASAN builds use __asan prefixed
> meminstrinsics, and KASAN no longer overrides memcpy/memset/memmove.
>
> If compiler support is detected (CC_HAS_KASAN_MEMINTRINSIC_PREFIX),
> define memintrinsics no
On Fri, 3 Feb 2023 17:18:37 +1000 Nicholas Piggin wrote:
> On a 16-socket 192-core POWER8 system, the context_switch1_threads
> benchmark from will-it-scale (see earlier changelog), upstream can
> achieve a rate of about 1 million context switches per second, due to
> contention on the mm refcou
On Tue, 31 Jan 2023 13:08:19 -0800 Suren Baghdasaryan wrote:
> On Tue, Jan 31, 2023 at 12:54 PM Andrew Morton
> wrote:
> >
> > On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan
> > wrote:
> >
> > > > > - vma->vm_flags &= ~VM_
On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan wrote:
> > > - vma->vm_flags &= ~VM_MAYWRITE;
> > > + vm_flags_clear(vma, VM_MAYSHARE);
> > > }
> >
> > I think it should be:
> > s/VM_MAYSHARE/VM_MAYWRITE/
>
I added the fixup. Much better than resendi
On Fri, 27 Jan 2023 11:40:37 -0800 Suren Baghdasaryan wrote:
> Per-vma locks idea that was discussed during SPF [1] discussion at LSF/MM
> last year [2], which concluded with suggestion that “a reader/writer
> semaphore could be put into the VMA itself; that would have the effect of
> using the V
On Fri, 27 Jan 2023 09:27:08 +0100 Luca Ceresoli
wrote:
> > On Thu, 26 Jan 2023 16:22:05 +0100 Luca Ceresoli wrote:
> > > Fix typos and add the following to the scripts/spelling.txt:
> > >
> > > exsits||exists
> > >
> > > Signed-off-by: Luca Ceresoli
> >
> > You need to split this up per
On Thu, 26 Jan 2023 08:04:47 +0100 Christophe Leroy
wrote:
> On powerpc64, you can build a kernel with KASAN as soon as you build it
> with RADIX MMU support. However if the CPU doesn't have RADIX MMU,
> KASAN isn't enabled at init and the following Oops is encountered.
Should we backport to -s
On Wed, 25 Jan 2023 21:07:57 +0200 Mike Rapoport wrote:
> Every architecture that supports FLATMEM memory model defines its own
> version of pfn_valid() that essentially compares a pfn to max_mapnr.
>
> Use mips/powerpc version implemented as static inline as a generic
> implementation of pfn_va
On Wed, 25 Jan 2023 16:50:01 -0800 Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 4:22 PM Andrew Morton
> wrote:
> >
> > On Wed, 25 Jan 2023 15:35:48 -0800 Suren Baghdasaryan
> > wrote:
> >
> > > Convert vma assignment in vm_area_dup() to a memcpy(
On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan wrote:
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,15 @@ struct vm_area_struct {
>* See vmf_insert_mixed_prot() for discussion.
>*/
> pgprot_t vm_page_prot;
> - unsigned long vm_
On Wed, 25 Jan 2023 15:35:49 -0800 Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
> operations
On Wed, 25 Jan 2023 15:35:48 -0800 Suren Baghdasaryan wrote:
> Convert vma assignment in vm_area_dup() to a memcpy() to prevent compiler
> errors when we add a const modifier to vma->vm_flags.
>
> ...
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -482,7 +482,7 @@ struct vm_area_struct *vm_a
On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda
wrote:
> Hi all,
>
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
So to clarify, the intent here is a simple readability cleanup for
exi
On Thu, 17 Nov 2022 16:26:47 +0800 Yicong Yang wrote:
> From: Anshuman Khandual
>
> The entire scheme of deferred TLB flush in reclaim path rests on the
> fact that the cost to refill TLB entries is less than flushing out
> individual entries by sending IPI to remote CPUs. But architecture
> ca
On Mon, 28 Nov 2022 09:18:47 +0100 David Hildenbrand wrote:
> > Less chances of things going wrong that way.
> >
> > Just mention in the v2 cover letter that the first patch was added to
> > make it easy to backport that fix without being hampered by merge
> > conflicts if it was added after you
On Wed, 7 Sep 2022 11:01:43 -0700 Yang Shi wrote:
> Since general RCU GUP fast was introduced in commit 2667f50e8b81 ("mm:
> introduce a general RCU get_user_pages_fast()"), a TLB flush is no longer
> sufficient to handle concurrent GUP-fast in all cases, it only handles
> traditional IPI-based
On Thu, 21 Jul 2022 20:55:09 +0100 Ben Dooks wrote:
> The setup_profiling_timer() is mostly un-implemented by many
> architectures. In many places it isn't guarded by CONFIG_PROFILE
> which is needed for it to be used. Make it a weak symbol in
> kernel/profile.c and remove the 'return -EINVAL' im
On Mon, 11 Jul 2022 12:35:34 +0530 Anshuman Khandual
wrote:
> This series drops __SXXX/__PXXX macros from across platforms in the tree.
I've updated mm-unstable to this version, thanks. I skipped the added-to-mm
emails to avoid wearing out people's inboxes.
Reissuing a 26-patch series N times
On Fri, 20 May 2022 14:25:05 -0500 "Eric W. Biederman"
wrote:
> > I am not strongly against taking off __weak, just wondering if there's
> > chance to fix it in recordmcount, and the cost comparing with kernel fix;
> > except of this issue, any other weakness of __weak. Noticed Andrew has
> > pi
On Thu, 19 May 2022 23:17:48 +0800 kernel test robot wrote:
> Hi "Naveen,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on f993aed406eaf968ba3867a76bb46c95336a33d0]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Naveen-N-Rao/kexec_file-Drop-weak-att
On Wed, 18 May 2022 23:48:28 +0530 "Naveen N. Rao"
wrote:
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This isn't an issue in general, but with
> kexec_file.c, gcc is placing
On Wed, 11 May 2022 09:19:17 +0800 kernel test robot wrote:
> Hi Baolin,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on akpm-mm/mm-everything]
> [cannot apply to hnaz-mm/master arm64/for-next/core linus/master v5.18-rc6]
> [If your patch is applied to the wrong g
On Tue, 10 May 2022 16:17:39 -0700 Andrew Morton
wrote:
> > +
> > +static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> > + unsigned long addr, pte_t *ptep)
> > +{
> > + return ptep_get(ptep);
> &
On Tue, 10 May 2022 11:45:59 +0800 Baolin Wang
wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When migratin
On Tue, 10 May 2022 11:45:57 +0800 Baolin Wang
wrote:
> Hi,
>
> Now migrating a hugetlb page or unmapping a poisoned hugetlb page, we'll
> use ptep_clear_flush() and set_pte_at() to nuke the page table entry
> and remap it, and this is incorrect for CONT-PTE or CONT-PMD size hugetlb
> page,
It
;re in
fixes-only mode.
If there's a case to be made that these patches are needed by 5.18
users then please let's make that case. Otherwise, this is 5.19-rc1 material.
And if it is indeed all 5.19-rc1 material, then please carry all four
in the powerpc tree with Acked-by: Andrew Morto
On Thu, 7 Apr 2022 16:02:44 +0530 Anshuman Khandual
wrote:
> protection_map[] is an array based construct that translates given vm_flags
> combination. This array contains page protection map, which is populated by
> the platform via [__S000 .. __S111] and [__P000 .. __P111] exported macros.
>
On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman 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 pic
On Thu, 17 Feb 2022 14:05:36 +0530 "Aneesh Kumar K.V"
wrote:
> Avoid code duplication by adding util.h. No functional change
> in this patch.
Sorry, but changes in linux-next have messed this patch up a bit more
than I'm prepared to fix. Could you please redo these two against
linux-next after
On Fri, 10 Dec 2021 21:36:00 +0800 Tiezhu Yang wrote:
> In arch/*/kernel/crash_dump*.c, there exist similar code about
> copy_oldmem_page(), move copy_to() from vmcore.c to uaccess.h,
> and then we can use copy_to() to simplify the related code.
>
> ...
>
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc
On Fri, 01 Oct 2021 17:14:41 +1000 Daniel Axtens wrote:
> > #ifdef __KERNEL__
> > +/*
> > + * Check if an address is part of freed initmem. After initmem is freed,
> > + * memory can be allocated from it, and such allocations would then have
> > + * addresses within the range [_stext, _end].
> >
On Tue, 28 Sep 2021 09:15:35 +0200 Christophe Leroy
wrote:
> Commit 7a5da02de8d6 ("locking/lockdep: check for freed initmem in
> static_obj()") added arch_is_kernel_initmem_freed() which is supposed
> to report whether an object is part of already freed init memory.
>
> For the time being, the
On Tue, 27 Jul 2021 15:59:55 +0100 Christoph Hellwig wrote:
> On Tue, Jul 27, 2021 at 04:48:53PM +0200, Arnd Bergmann wrote:
> > Since these patches are now all that remains, it would be nice to
> > merge it all through Andrew's Linux-mm tree, which is already based
> > on top of linux-next.
>
>
On Fri, 25 Jun 2021 05:10:12 + (UTC) Christophe Leroy
wrote:
> Pagewalk ignores hugepd entries and walk down the tables
> as if it was traditionnal entries, leading to crazy result.
>
> Add walk_hugepd_range() and use it to walk hugepage tables.
More details, please? I assume "crazy resul
On Wed, 16 Jun 2021 10:22:39 +0530 "Aneesh Kumar K.V"
wrote:
> To avoid a race between rmap walk and mremap, mremap does take_rmap_locks().
> The lock was taken to ensure that rmap walk don't miss a page table entry due
> to
> PTE moves via move_pagetables(). The kernel does further optimizatio
On Wed, 16 Jun 2021 10:22:33 +0530 "Aneesh Kumar K.V"
wrote:
> This patch series is split out series from [PATCH v7 00/11] Speedup mremap on
> ppc64
> (https://lore.kernel.org/linux-mm/20210607055131.156184-1-aneesh.ku...@linux.ibm.com)
> dropping ppc64 specific changes.
>
> This patchset is d
1 - 100 of 648 matches
Mail list logo
