linux-kernel - Re: [PATCH v34 05/13] mm/damon: Implement primitives for the virtual memory address spaces

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: <358fa060-7702-d523-5169-f25a3de0c22e@redhat.com>
Date:   Thu, 26 Aug 2021 16:09:23 +0200
From:   David Hildenbrand <david@...hat.com>
To:     SeongJae Park <sj38.park@...il.com>, akpm@...ux-foundation.org
Cc:     SeongJae Park <sjpark@...zon.de>, Jonathan.Cameron@...wei.com,
        acme@...nel.org, alexander.shishkin@...ux.intel.com,
        amit@...nel.org, benh@...nel.crashing.org,
        brendanhiggins@...gle.com, corbet@....net, dwmw@...zon.com,
        elver@...gle.com, fan.du@...el.com, foersleo@...zon.de,
        greg@...ah.com, gthelen@...gle.com, guoju.fgj@...baba-inc.com,
        jgowans@...zon.com, joe@...ches.com, mgorman@...e.de,
        mheyne@...zon.de, minchan@...nel.org, mingo@...hat.com,
        namhyung@...nel.org, peterz@...radead.org, riel@...riel.com,
        rientjes@...gle.com, rostedt@...dmis.org, rppt@...nel.org,
        shakeelb@...gle.com, shuah@...nel.org, sieberf@...zon.com,
        snu@...le79.org, vbabka@...e.cz, vdavydov.dev@...il.com,
        zgf574564920@...il.com, linux-damon@...zon.com, linux-mm@...ck.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v34 05/13] mm/damon: Implement primitives for the virtual
 memory address spaces

> +static void damon_va_mkold(struct mm_struct *mm, unsigned long addr)
> +{
> +	pte_t *pte = NULL;
> +	pmd_t *pmd = NULL;
> +	spinlock_t *ptl;
> +

I just stumbled over this, sorry for the dumb questions:


a) What do we know about that region we are messing with?

AFAIU, just like follow_pte() and follow_pfn(), follow_invalidate_pte() 
should only be called on VM_IO and raw VM_PFNMAP mappings in general 
(see the doc of follow_pte()). Do you even know that it's within a 
single VMA and that there are no concurrent modifications?

b) Which locks are we holding?

I hope we're holding the mmap lock in read mode at least. Or how are you 
making sure there are no concurrent modifications to page tables / VMA 
layout ... ?

> +	if (follow_invalidate_pte(mm, addr, NULL, &pte, &pmd, &ptl))



-- 
Thanks,

David / dhildenb