linux-kernel - Re: [PATCH v2 1/2] mm/migrate_device.c: Copy pte dirty bit to page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k06xf70l.fsf@nvdebian.thelocal>
Date:   Thu, 25 Aug 2022 11:24:03 +1000
From:   Alistair Popple <apopple@...dia.com>
To:     Peter Xu <peterx@...hat.com>
Cc:     "Huang, Ying" <ying.huang@...el.com>,
        Nadav Amit <nadav.amit@...il.com>,
        huang ying <huang.ying.caritas@...il.com>,
        Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Sierra Guiza, Alejandro (Alex)" <alex.sierra@....com>,
        Felix Kuehling <Felix.Kuehling@....com>,
        Jason Gunthorpe <jgg@...dia.com>,
        John Hubbard <jhubbard@...dia.com>,
        David Hildenbrand <david@...hat.com>,
        Ralph Campbell <rcampbell@...dia.com>,
        Matthew Wilcox <willy@...radead.org>,
        Karol Herbst <kherbst@...hat.com>,
        Lyude Paul <lyude@...hat.com>, Ben Skeggs <bskeggs@...hat.com>,
        Logan Gunthorpe <logang@...tatee.com>, paulus@...abs.org,
        linuxppc-dev@...ts.ozlabs.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] mm/migrate_device.c: Copy pte dirty bit to page


Alistair Popple <apopple@...dia.com> writes:

> Peter Xu <peterx@...hat.com> writes:

>>> But it's kind of against a pure "optimization" in that if trylock failed,
>>> we'll clear the mpfn so the src[i] will be zero at last.  Then will we
>>> directly give up on this page, or will we try to lock_page() again
>>> somewhere?
>
> That comment is out dated. We used to try locking the page again but
> that was removed by ab09243aa95a ("mm/migrate.c: remove
> MIGRATE_PFN_LOCKED"). See
> https://lkml.kernel.org/r/20211025041608.289017-1-apopple@nvidia.com
>
> Will post a clean-up for it.

By the way it's still an optimisation because in most cases we can avoid
calling try_to_migrate() and walking the rmap altogether if we install
the migration entries here. But I agree the comment is misleading.

>>> The future unmap op is also based on this "cpages", not "npages":
>>>
>>> 	if (args->cpages)
>>> 		migrate_vma_unmap(args);
>>>
>>> So I never figured out how this code really works.  It'll be great if you
>>> could shed some light to it.
>>>
>>> Thanks,
>>>
>>> --
>>> Peter Xu