Hi all,
On Tue, 9 Jul 2024 17:40:53 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>
> Today's linux-next merge of the random tree got a conflict in:
>
> mm/rmap.c
>
> between commits:
>
> 26d21b18d971 ("mm/rmap: remove duplicated exit code in pagewalk loop")
> 15bde4abab73 ("mm: extend rmap flags arguments for folio_add_new_anon_rmap")
>
> from the mm-stable tree and commit:
>
> 94beef29e110 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings")
>
> from the random tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc mm/rmap.c
> index 8616308610b9,1f9b5a9cb121..000000000000
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@@ -1394,27 -1384,26 +1394,30 @@@ void folio_add_anon_rmap_pmd(struct fol
> *
> * Like folio_add_anon_rmap_*() but must only be called on *new* folios.
> * This means the inc-and-test can be bypassed.
> - * The folio does not have to be locked.
> + * The folio doesn't necessarily need to be locked while it's exclusive
> + * unless two threads map it concurrently. However, the folio must be
> + * locked if it's shared.
> *
> - * If the folio is pmd-mappable, it is accounted as a THP. As the folio
> - * is new, it's assumed to be mapped exclusively by a single process.
> + * If the folio is pmd-mappable, it is accounted as a THP.
> */
> void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
> - unsigned long address)
> + unsigned long address, rmap_t flags)
> {
> - int nr = folio_nr_pages(folio);
> + const int nr = folio_nr_pages(folio);
> + const bool exclusive = flags & RMAP_EXCLUSIVE;
> + int nr_pmdmapped = 0;
>
> VM_WARN_ON_FOLIO(folio_test_hugetlb(folio), folio);
> + VM_WARN_ON_FOLIO(!exclusive && !folio_test_locked(folio), folio);
> VM_BUG_ON_VMA(address < vma->vm_start ||
> address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
> -
> - if (!folio_test_swapbacked(folio))
> + /*
> + * VM_DROPPABLE mappings don't swap; instead they're just dropped when
> + * under memory pressure.
> + */
> - if (!(vma->vm_flags & VM_DROPPABLE))
> ++ if (!folio_test_swapbacked(folio) && !(vma->vm_flags & VM_DROPPABLE))
> __folio_set_swapbacked(folio);
> - __folio_set_anon(folio, vma, address, true);
> + __folio_set_anon(folio, vma, address, exclusive);
>
> if (likely(!folio_test_large(folio))) {
> /* increment count (starts at -1) */
> @@@ -1858,8 -1862,15 +1867,13 @@@ static bool try_to_unmap_one(struct fol
> * discarded. Remap the page to page table.
> */
> set_pte_at(mm, address, pvmw.pte, pteval);
> - folio_set_swapbacked(folio);
> + /*
> + * Unlike MADV_FREE mappings, VM_DROPPABLE ones
> + * never get swap backed on failure to drop.
> + */
> + if (!(vma->vm_flags & VM_DROPPABLE))
> + folio_set_swapbacked(folio);
> - ret = false;
> - page_vma_mapped_walk_done(&pvmw);
> - break;
> + goto walk_abort;
> }
>
> if (swap_duplicate(entry) < 0) {
This is now a conflict between the random tree and Linus' tree.
--
Cheers,
Stephen Rothwell
Attachment:
pgpwdxLsASIuR.pgp
Description: OpenPGP digital signature
