Date:   Mon, 20 Dec 2021 21:03:12 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     David Hildenbrand <david@redhat.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Nadav Amit <namit@vmware.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Hugh Dickins <hughd@google.com>,
        David Rientjes <rientjes@google.com>,
        Shakeel Butt <shakeelb@google.com>,
        John Hubbard <jhubbard@nvidia.com>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Mike Rapoport <rppt@linux.ibm.com>,
        Yang Shi <shy828301@gmail.com>,
        "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        Matthew Wilcox <willy@infradead.org>,
        Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
        Michal Hocko <mhocko@kernel.org>,
        Rik van Riel <riel@surriel.com>,
        Roman Gushchin <guro@fb.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Peter Xu <peterx@redhat.com>,
        Donald Dutile <ddutile@redhat.com>,
        Christoph Hellwig <hch@lst.de>,
        Oleg Nesterov <oleg@redhat.com>, Jan Kara <jack@suse.cz>,
        Linux-MM <linux-mm@kvack.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@vger.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via
 FAULT_FLAG_UNSHARE (!hugetlb)
Message-ID: <20211221010312.GC1432915@nvidia.com>
References: <CAHk-=wj7eSOhbWDeADL_BJKLzdDF5s_5R9v7d-4P3L6v1T3mpQ@mail.gmail.com>
 <20211218184233.GB1432915@nvidia.com>
 <5CA1D89F-9DDB-4F91-8929-FE29BB79A653@vmware.com>
 <CAHk-=wh-ETqwd6EC2PR6JJzCFHVxJgdbUcMpW5MS7gCa76EDsQ@mail.gmail.com>
 <4D97206A-3B32-4818-9980-8F24BC57E289@vmware.com>
 <CAHk-=whxvVQReBqZeaV41=sAWfT4xTfn6sMSWDfkHKVS3zX85w@mail.gmail.com>
 <5A7D771C-FF95-465E-95F6-CD249FE28381@vmware.com>
 <CAHk-=wgMuSkumYxeaaxbKFoAbw_gjYo1eRXXSFcBHzNG2xauTA@mail.gmail.com>
 <CAHk-=whYT0Q1F=bxG0yi=LN5gXY64zBwefsbkLoRiP5p598d5A@mail.gmail.com>
 <fca16906-8e7d-5d04-6990-dfa8392bad8b@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fca16906-8e7d-5d04-6990-dfa8392bad8b@redhat.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sog1AC0GyQ1zmyBygL9LTYnum//ZeQeZzHeDbLuY/rtQWy9sx/iHF+rM5fXU?=
 =?us-ascii?Q?dhfiel2TeKg3x+q3JOXVyo/qOisvHBeHmhYceommwGnGfBOpVF+J7f8BvMkf?=
 =?us-ascii?Q?cbvXnncVWeBJFIG1bUnwlmbUyhF3HKNphZckYa3j9su5tNaVxZzNn875wumY?=
 =?us-ascii?Q?0BH5gO59Z9wOJilVaagVAFzUm3/0XymYGwNJonZqbN7Rl9r3dwOtZg1sQXv2?=
 =?us-ascii?Q?eZ7EbiFat/njX0wFAqX6UXsPzJVpVlHWi9k1JCCdtt+u8T2y/Y9QjX9/ezB9?=
 =?us-ascii?Q?Omtmv4e2Br2xzCCrTuxU7WQSL9Gu7kwKLWdNWpHzy8Z1hHAjnVrB0CVvY8ej?=
 =?us-ascii?Q?1SwGM6bKxDQhuGsQFdDPRK3jt8NhhKJ2pQDZSr6YGHLiv7oLa2hnxo50Dsq4?=
 =?us-ascii?Q?1I1dampnKLQbtCH8gLz/DU4Kkc3mGTSziKxbDQQHllTgApS9jkYVZOh4SPr/?=
 =?us-ascii?Q?sn0zIA0LGiiFP+jwIyb+2L92hkWLw3ZSrUJLFmHvdYaKGgo7jFLuv1i1eV+k?=
 =?us-ascii?Q?wEkwlG7qQ2or7ASjB9Cbw9ljHibVEtMuZziVirDFN1JnVcTbq7Ntb6/P6tVO?=
 =?us-ascii?Q?m78cBK1WwqvHW4ApcdE9W2jKk6cLYU2llCV2t0Zf464cFBfsq46IHi2w3x97?=
 =?us-ascii?Q?S54a9n1k4bJ9g/hb14+Q43QCobIfgmpQBWd65xnxaYFsvN6BH4XLTAi58uj+?=
 =?us-ascii?Q?kUfBIKZCmzNEwIftut6FLkMF1xiu9QLBNIfAmbn9MC3jthlYmefI7kxi03zX?=
 =?us-ascii?Q?yPe5FCRV2lNt/jCpNcAZB8no1LUZjVodtsOGqoN1iyJePSl9hzfWtoLPkM1k?=
 =?us-ascii?Q?nKett5Z+Yu3ITbhfgQLV+Ys5p8SpyhLJ+EbpLYacfXyzp67B0xHaHBA6shHP?=
 =?us-ascii?Q?hrbRg5sNSm8+1BJHJZZKGe7bGgWMbbLPb7irnsCTfBfLYZSXKTWP8JzANpdU?=
 =?us-ascii?Q?ZE2OoyQXn8gwaGNlP2NFTTI/UYhohSz+Xb3QokdqXdO+NmBqIZgvADPiywoa?=
 =?us-ascii?Q?EOWgohPfL56OagLasC3E1wBpAL8Hz4gheNoqRTNhlddAatpG2LBHYyNpUP5h?=
 =?us-ascii?Q?zFJPhCpA6wQ9TJMAqwRTjURwInbI60JG+DVOmwVFeG9YUBLKNCaqjH3Ch2s+?=
 =?us-ascii?Q?Q8uWXtVg60ktdE33wgkrjbV1TJJ+vtJS6Vll46ROP8piQhm53OkqM05Xv7s7?=
 =?us-ascii?Q?qzR4nidqlPEl/3Br6X3hZYA8a6Me4gSdmIwr00mrjZA8yum8EEHV289ndDzo?=
 =?us-ascii?Q?r3GmyMW276f6rhxAOfqx+38eNk9MZ0DlICr9QHPggvOxQhOAObA/p4kKMQce?=
 =?us-ascii?Q?KeXzJB7ANLmAARgHt8F72Fie2k8v85aECDSk+sg3DbLMDUYyjwNPwFRcCYvc?=
 =?us-ascii?Q?BPnDuMgZbR/IY4HVxLk3EdjgWmWmGoGy2PbUShw5QYMP1tvXNiogYEVJZ/NL?=
 =?us-ascii?Q?bMbgBN8go62hvjGh0e30zCCOFc+C5o3RXdcI7+k3ycHbPYx8FD7iir2rmZ5i?=
 =?us-ascii?Q?9Yu8SAQTnUO1jVWOc7fxxEk3n7fzGYptnBQmf7sJHRJl5Heamso6UQDh0Uc+?=
 =?us-ascii?Q?JqybZ83zJS1+pJhNVOk=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 613958bc-58f3-404a-1ffa-08d9c41daa58
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Dec 2021 01:03:14.4226
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: wGJEynFzbbzFULNexZ7S0eLwKkXTOKrQUYjJclVvmR7nru6Cv7Jj3uKCuwrxQyNN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5303
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Dec 19, 2021 at 06:59:51PM +0100, David Hildenbrand wrote:

> handler (COW or unshare). Outside of COW/Unshare code, the bit can only
> be set if page_count() == 1 and we sync against fork(). (and that's the
> problem for gup-fast-only that I'm investigating right now, because it
> would then always have to fallback to the slow variant if the bit isn't
> already set)

I'm having a hard time imagining how gup_fast can maintain any sort of
bit - it lacks all forms of locks so how can we do an atomic test and
set between two pieces of data?

I think the point of Linus's plan really is that the new bit is
derived from page_count, we get the set the new bit when we observe
page_count==1 in various situations and we clear the new bit whenever
we write protect with the intent to copy.

GUP doesn't interact with this bit. A writable page would still be the
second way you can say "you clearly have full ownership of the page',
so GUP just checks writability and bumps the refcount. The challenge
of GUP reamins to sanely sequence it with things that are doing WP.

The elevated GUP refcount prevents the page from getting the bit set
again, regardless of what happens to it.

Then on the WP sides.. Obviously we clear the bit when applying a WP
for copy. So all the bad GUP cases are halted now, as with a cleared
bit and a != 1 refcount COW must happen.

Then, it is also the case that most often a read-only page will have
this bit cleared, UFFWD WP being the exception.

UFFWD WP works fine as it will have the bit set in the cases we care
about and COW will not happen.

If the bit is not set then everything works as is today and you get
extra COWs. We still have to fix the things that are missing the extra
COWs to check the page ref to fix this.

It seems this new bit is acting as a 'COW disable', so, the accuracy
of COW vs GUP&speculative pagerefs now relies on setting the bit as
aggressively as possible when it is safe and cheap to do so.

If I got it right this is why it is not just mapcount reduced to 1
bit. It is quite different, even though "this VM owns the page
outright" sure sounds like "mapcount == 1"..

It seems like an interesting direction - the security properties seem
good as we only have to take care of sites applying WP to decide what
to do with the extra bit, and all places that set the bit to 1 do so
after testing refcount under various locks preventing PTE WP.

That just leave the THP splitting.. I suppose we get the PTL, then
compute the current value of the new bit based on refcount and diffuse
it to all tail pages, then update the PMD and release the PTL. Safe
against concurrent WP - don't need DoubleMap horrors because it isn't
a counter.

> Not set it stone, just an idea what I'm playing with right now ... and I
> have to tripple-check if
> * page is PTE mapped in the page table I'm walking
> * page_count() == 1
> Really means that "this is the only reference.". I do strongly believe
> so .. :)

AFAIK the only places that can break this are places putting struct
page memory into special PTEs. Which is horrific and is just bugs, but
I think I've seen it from time to time :(

ZONE_DEVICE is also messed up, of course, but that is just more
reasons ZONE_DEVICE refcounting needs fixing and you should ignore it.

Jason