[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201221215526.GK6640@xz-x1>
Date: Mon, 21 Dec 2020 16:55:26 -0500
From: Peter Xu <peterx@...hat.com>
To: Nadav Amit <nadav.amit@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Yu Zhao <yuzhao@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
linux-mm <linux-mm@...ck.org>,
lkml <linux-kernel@...r.kernel.org>,
Pavel Emelyanov <xemul@...nvz.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
stable <stable@...r.kernel.org>,
Minchan Kim <minchan@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Mon, Dec 21, 2020 at 12:23:06PM -0800, Nadav Amit wrote:
> 2. Copy the page in cow_user_page() while holding the PTL and after flushing
> has been done. I am not sure if there are potential problems with
> special-pages (2 flushes might be necessary for special pages).
This seems to be a good thing irrelevant of userfaultfd.
Frankly speaking I don't know why it's always safe to do data copy without the
pgtable lock in wp_page_copy(), since I don't know what guaranteed us from data
changing on the original page due to any reason. We check and make sure pte
hasn't changed, but is that really enough?
So the safe way to me is that wp_page_copy() not only check pte_same() but also
data_same() on the old/new pages, then with that it's even easier if we just
move the data copy into the ptl as what Nadav said here. But I have no idea on
the penalty to the rest of the world, especially on non-modern hosts.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists