On Tue, Aug 22, 2023 at 8:54 PM Hugh Dickins wrote:
> But rather than reworking it, please let's just go with v1 for now.
Sounds good to me.
On Tue, Aug 22, 2023 at 5:23 PM Matthew Wilcox wrote:
> On Tue, Aug 22, 2023 at 04:39:43PM +0200, Jann Horn wrote:
> > > Perhaps something else will want that same behaviour in future (it's
> > > tempting, but difficult to guarantee correctness); for now, it is j
On Tue, Aug 22, 2023 at 4:51 AM Hugh Dickins wrote:
> On Mon, 21 Aug 2023, Jann Horn wrote:
> > On Mon, Aug 21, 2023 at 9:51 PM Hugh Dickins wrote:
> > > Just for this case, take the pmd_lock() two steps earlier: not because
> > > it gives any protection against th
On Mon, Aug 21, 2023 at 9:51 PM Hugh Dickins wrote:
> Jann Horn demonstrated how userfaultfd ioctl UFFDIO_COPY into a private
> shmem mapping can add valid PTEs to page table collapse_pte_mapped_thp()
> thought it had emptied: page lock on the huge page is enough to protect
> again
On Wed, Jul 12, 2023 at 6:42 AM Hugh Dickins wrote:
> Bring collapse_and_free_pmd() back into collapse_pte_mapped_thp().
> It does need mmap_read_lock(), but it does not need mmap_write_lock(),
> nor vma_start_write() nor i_mmap lock nor anon_vma lock. All racing
> paths are relying on
On Fri, Jun 2, 2023 at 6:37 AM Hugh Dickins wrote:
> On Wed, 31 May 2023, Jann Horn wrote:
> > On Mon, May 29, 2023 at 8:11 AM Hugh Dickins wrote:
> > > Here is the third series of patches to mm (and a few architectures), based
> > > on v6.4-rc3 with the preceding t
On Fri, Jun 2, 2023 at 4:50 AM Hugh Dickins wrote:
> On Wed, 31 May 2023, Jann Horn wrote:
> > On Mon, May 29, 2023 at 8:15 AM Hugh Dickins wrote:
> > > Before putting them to use (several commits later), add rcu_read_lock()
> > > to pte_offset_map(), and rcu_read_unl
On Mon, May 29, 2023 at 8:23 AM Hugh Dickins wrote:
> Add the generic pte_free_defer(), to call pte_free() via call_rcu().
> pte_free_defer() will be called inside khugepaged's retract_page_tables()
> loop, where allocating extra memory cannot be relied upon. This version
> suits all those
On Wed, May 31, 2023 at 10:54 PM Peter Xu wrote:
> On Wed, May 31, 2023 at 05:34:58PM +0200, Jann Horn wrote:
> > On Mon, May 29, 2023 at 8:25 AM Hugh Dickins wrote:
> > > -static int retract_page_tables(struct address_space *mapping, pg
On Mon, May 29, 2023 at 8:11 AM Hugh Dickins wrote:
> Here is the third series of patches to mm (and a few architectures), based
> on v6.4-rc3 with the preceding two series applied: in which khugepaged
> takes advantage of pte_offset_map[_lock]() allowing for pmd transitions.
To clarify: Part of
On Mon, May 29, 2023 at 8:26 AM Hugh Dickins wrote:
> Bring collapse_and_free_pmd() back into collapse_pte_mapped_thp().
> It does need mmap_read_lock(), but it does not need mmap_write_lock(),
> nor vma_start_write() nor i_mmap lock nor anon_vma lock. All racing
> paths are relying on
On Mon, May 29, 2023 at 8:15 AM Hugh Dickins wrote:
> Before putting them to use (several commits later), add rcu_read_lock()
> to pte_offset_map(), and rcu_read_unlock() to pte_unmap(). Make this a
> separate commit, since it risks exposing imbalances: prior commits have
> fixed all the known
On Mon, May 29, 2023 at 8:25 AM Hugh Dickins wrote:
> -static int retract_page_tables(struct address_space *mapping, pgoff_t pgoff,
> - struct mm_struct *target_mm,
> - unsigned long target_addr, struct page *hpage,
> -
On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
> On Tue 17-01-23 19:02:55, Jann Horn wrote:
> > +locking maintainers
> >
> > On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> > > Introduce a per-VMA rw_semaphore to be used during page fault handl
On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> 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 fault handlers that would hold VMA locks.
> VMAs are locked
On Wed, Jan 18, 2023 at 10:40 AM Michal Hocko wrote:
> On Tue 17-01-23 21:28:06, Jann Horn wrote:
> > On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> > > On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > > > Protect VMA from concurrent page fault h
On Tue, Jan 17, 2023 at 10:28 PM Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 10:03 AM Jann Horn wrote:
> >
> > +locking maintainers
>
> Thanks! I'll CC the locking maintainers in the next posting.
>
> >
> > On Mon, Jan 9, 2023 at 9:54 PM Suren Baghda
On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> Introduce lock_vma_under_rcu function to lookup and lock a VMA during
> page fault handling. When VMA is not found, can't be locked or changes
> after being locked, the function returns NULL. The lookup is performed
> under RCU protection
On Tue, Jan 17, 2023 at 8:51 PM Jann Horn wrote:
> On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> > Due to the possibility of handle_userfault dropping mmap_lock, avoid fault
> > handling under VMA lock and retry holding mmap_lock. This can be handled
>
On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > Protect VMA from concurrent page fault handler while collapsing a huge
> > page. Page fault handler needs a stable PMD to use PTL and relies on
> > per-VMA lock to prevent concurrent PMD
On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> Due to the possibility of handle_userfault dropping mmap_lock, avoid fault
> handling under VMA lock and retry holding mmap_lock. This can be handled
> more gracefully in the future.
>
> Signed-off-by: Suren Baghdasaryan
> Suggested-by:
; > > >
> > > > On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> > > > > On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
> > > > > >
> > > > > > On Mon, Jan 9, 2023 at 9:55 PM Suren
On Tue, Jan 17, 2023 at 7:31 PM Matthew Wilcox wrote:
>
> On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
> > >
> > > On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan
> > > w
On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> vma->lock being part of the vm_area_struct causes performance regression
> during page faults because during contention its count and owner fields
> are constantly updated and having other parts of vm_area_struct used
> during page fault
On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> rw_semaphore is a sizable structure of 40 bytes and consumes
> considerable space for each vm_area_struct. However vma_lock has
> two important specifics which can be used to replace rw_semaphore
> with a simpler structure:
[...]
>
+locking maintainers
On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> Introduce a per-VMA rw_semaphore to be used during page fault handling
> instead of mmap_lock. Because there are cases when multiple VMAs need
> to be exclusively locked during VMA tree modifications, instead of the
On Thu, Jun 10, 2021 at 10:35 AM 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 optimization of
yet (?), I
think it's useful to try to write a manpage for this API, partly to
figure out how usable that API actually is, and partly because when this
hardware does ship, it'd be nice if distro manpages had information about
how to use it.
Signed-off-by: Jann Horn
---
This patch goes on top of the pat
b78 7c7f1b78 fb610048 38a10028 38810020
> fb810050 7f8802a6
> bad-bctr[2996]: code: 3860001c f8010080 48242371 6000 <7c7b1b79>
> 4082002c e8010080 eb610048
>
> This was discovered on x86 by Jann Horn and fixed in commit
> 342db04ae712 ("x86/dumpstack: Don't dump kerne
29 matches
Mail list logo
