Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 23 Jun 2022 22:34:15 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Alistair Popple <apopple@nvidia.com>
Cc:     Alex Williamson <alex.williamson@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        akpm@linux-foundation.org, minchan@kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, paulmck@kernel.org,
        jhubbard@nvidia.com, joaodias@google.com
Subject: Re: [PATCH] mm: Re-allow pinning of zero pfns
Message-ID: <20220624013415.GI4147@nvidia.com>
References: <165490039431.944052.12458624139225785964.stgit@omen>
 <bb120b4a-e6f6-de81-35f0-9803acf9b0be@redhat.com>
 <20220615155659.GA7684@nvidia.com>
 <cb7efb0f-5537-5ce4-7aec-bb10ea81d5de@redhat.com>
 <20220623142139.462a0841.alex.williamson@redhat.com>
 <20220623204712.GG4147@nvidia.com>
 <87a6a2zyxk.fsf@nvdebian.thelocal>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87a6a2zyxk.fsf@nvdebian.thelocal>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?0VLbJLJBWRrSleQocwc34XUIKDf9/hIBMmu6t0TlG9J+JPIndc9W46bCFCXd?=
 =?us-ascii?Q?Y8oMLHwu1qlLVMHxLz+p7vW5q0cd/9NaPGa+vD3deF+1Bz5711vCVd60sajh?=
 =?us-ascii?Q?+UeUm3mCfdcdJmPeajMH4fqtGAIa+o9KxoErwVqDVm/N5rWxkduYTZLzuhSA?=
 =?us-ascii?Q?1/22ZqYQqRLihN1zzMPNugrVB2zfrDUN75RMn/TbVDSlb8SCqLGNHJauQ8fh?=
 =?us-ascii?Q?Wreivve9ZyHusVXyjz+DfQJsGuRX5PCJQ2wrGixCvbZHvhzrhq5w/tmh63sT?=
 =?us-ascii?Q?O2RHMmgCxkXGR+Bfa7mGgMewqsQkqHlbfnpS4zHmJWaRERHRzRWmL4n8ZjMP?=
 =?us-ascii?Q?oVqAPcJlezk51THa5kjfxgbgMs215UagjtZMXRkuvraRKj3jUpskLac5G5aa?=
 =?us-ascii?Q?/EELWxFDo/cpfRmQxk8EV1E8+YI072ROwUCplVK7tveN7Yqpprd9j3xNKZAS?=
 =?us-ascii?Q?fCPXr0ijl11qxlSuWfzokfKQvo3X/2Yd9+6V7Z19xtANW2pg/2sNaa+wxlv+?=
 =?us-ascii?Q?E6fJM8AYT8P2oE0YcdE/SefngxBpBLitvSZkTM+mOXPBw1A/p+lKQlZIhpBU?=
 =?us-ascii?Q?gt7VPLW5addMs96dhVV2v2IEfDfcDiU20WEQvWKBEPb0rSMELizv5eYAQ2Eq?=
 =?us-ascii?Q?Y5b4beRNalZVBa1YYNk74Hp9julf4tDk5KV3P42E00gpMJOih6ZwDqF812Ne?=
 =?us-ascii?Q?mKg1gEE/TkIgMiR0pyEw1B8vvDVtyxDRagS+0DvSofb3B+jzpy0TdLRl4o4F?=
 =?us-ascii?Q?0a/Rv/eA0RiXRWUSGzl7IGTTtvQ3a35RsuoGRsaSigKqKNTH1/Emd+Hr2T7Y?=
 =?us-ascii?Q?rCXzSHH3u/e7Q0arVhUvMsUYALlTs+H8peB/RJFOsEKrNc+6WLsJZTzzlkML?=
 =?us-ascii?Q?YMXoT2q6t+Lqs8g0NltKr6DrPdI5tVV7BpO4MJyZ+uFmMN6B4x5zGl8srFuO?=
 =?us-ascii?Q?/t8FimzsPPz+55qzX4s6cSCBPOyxB57IFvjGGnjU0DWm6yceHOwfnS2UxEGn?=
 =?us-ascii?Q?7uy2mClVrJuRdbJZS1FgO3OWscE6bJIHw0gPV5yL1Bx5wyWxBaoCqzYtWvj9?=
 =?us-ascii?Q?8tjHrBaJehY5RHVChFDkzwl+eSobrK8hSgCR4g+F5f6VYzlJrqshb2X6gi1v?=
 =?us-ascii?Q?Csf2hRRVzmxF6NIHPTzL5zpkP3QNIqn5Pzj1mDKx5JtdAn2Vu/85f9RV0Ty8?=
 =?us-ascii?Q?56dPDRXR2JFsOA3HTSIn4AdifljZQ2+EgCUyap3CvxBxIlFJey0SeWnBEaPD?=
 =?us-ascii?Q?3UPzlZsFvCqVM6Mhi6nB/QeCMcmxS2nmWQ1hSCrSVdILY5wCn8M7HzvX1Hwn?=
 =?us-ascii?Q?CRtlcC2Cag0CTEnDoNyozY28Sa1RKkhnsHxp05LL2Y4LoiGIqnqKlb7b4pOj?=
 =?us-ascii?Q?oUNVPIgQeZJDZZwXXAWZXTa8m7Tm/EdPfrDKxMpWBym5M+HLZNcMBqYxLAw4?=
 =?us-ascii?Q?vJmIkYIczfJL6kvT1GzMNrBIR0/snlYvrv+E2sKv2DHQvv0TlpOPu7Z+3SzG?=
 =?us-ascii?Q?lr5qavtL+EIwaDMOUGJ5eSV93W3IH+jLCr7cjeqx26SEKNfpPLPzEZzPvhGi?=
 =?us-ascii?Q?hAP2YlFfBgJUlQgG5i880BNZEGwoe1PvOl/MHbJX?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d60226c-bec7-46a4-a28a-08da5581a6f7
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2022 01:34:16.8610
 (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: spN4c48aP7zTKrLFHnwtsL22t4GZ5qTDICcnfRqLoM6liPvC9oJwifyU0EYozy8z
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1838
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jun 24, 2022 at 10:11:01AM +1000, Alistair Popple wrote:

> > Hum.. Alistair, maybe you should look at this as well, I'm struggling
> > alot to understand how it is safe to drop the reference on the page
> > but hold a pointer to it on the movable_page_list - sure it was
> > isolated - but why does that mean it won't be concurrently unmapped
> > and freed?
> 
> folio_isolate_lru() takes a reference on the page so you're safe from it
> being freed. If it gets unmapped it will be freed when the matching
> putback_movable_pages() is called.

Hm, I guess I didn't dig deep enough into that call chain..

> > Anyhow, it looks like the problem is the tortured logic in this
> > function, what do you think about this:
> 
> At a glance it seems reasonable, although I fear it might conflict with
> my changes for device coherent migration. Agree the whole
> check_and_migrate_movable_pages() logic is pretty tortured though, and I
> don't think I'm making it better so would be happy to try cleaning it up
> futher once the device coherent changes are in.

OK, can I leave this patch with you then? I have no way to test it..

Thanks,
Jason