Re: [PATCH 3/3] mm, arch: add generic implementation of pfn_valid() for FLATMEM

On Thu, Jan 26, 2023 at 3:08 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > 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 gene

Re: [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions

On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote: > On Wed, Jan 25, 2023 at 12:38:46AM -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 e

Re: [PATCH v2 2/6] mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK

On Wed, Jan 25, 2023 at 12:38:47AM -0800, Suren Baghdasaryan wrote: > To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(), > replace it with VM_LOCKED_MASK bitmask and convert all users. > > Signed-off-by: Suren Baghdasaryan Acked-by: Mike Rapoport (IBM) > --- > include/linux/mm

Re: [PATCH v2 5/6] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn

On Wed, Jan 25, 2023 at 12:38:50AM -0800, Suren Baghdasaryan wrote: > In cases when VMA flags are modified after VMA was isolated and mmap_lock > was downgraded, flags modifications would result in an assertion because > mmap write lock is not held. > Introduce mod_vm_flags_nolock to be used in suc

Re: [PATCH v2 4/6] mm: replace vma->vm_flags indirect modification in ksm_madvise

On Wed, Jan 25, 2023 at 12:38:49AM -0800, Suren Baghdasaryan wrote: > Replace indirect modifications to vma->vm_flags with calls to modifier > functions to be able to track flag changes and to keep vma locking > correctness. Add a BUG_ON check in ksm_madvise() to catch indirect > vm_flags modificat

Re: [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions

On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote: > On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote: > > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote: > > > +/* Use when VMA is not part of the VMA tree and needs no locking */ > > > +static inline voi

Re: [PATCH v2 3/6] mm: replace vma->vm_flags direct modifications with modifier calls

On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote: > 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. > > Signed-off-by: Suren Baghdasaryan Acked-by: Mike Rapoport (IBM) > -

Re: [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions

On Wed, Jan 25, 2023 at 12:38:46AM -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 > opera

Re: [PATCH v2 6/6] mm: export dump_mm()

On Wed, Jan 25, 2023 at 12:38:51AM -0800, Suren Baghdasaryan wrote: > mmap_assert_write_locked() is used in vm_flags modifiers. Because > mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes > modified from from inside a module, it's necessary to export > dump_mm() function. > > Si

[PATCH] um-virt-pci: Make max delay configurable

unt > UM_VIRT_PCI_MAXDELAY, + ++delay_count > um_pci_max_delay_us, "um virt-pci delay: %d", delay_count)) { ret = -EIO; break; --- base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2

Re: [PATCH 1/3] m68k: use asm-generic/memory_model.h for both MMU and !MMU

On Wed, Jan 25, 2023 at 8:08 PM Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > The MMU variant uses generic definitions of page_to_pfn() and > pfn_to_page(), but !MMU defines them in include/asm/page_no.h for no > good reason. > > Include asm-generic/memory_model.h in the common include/a