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;
From:   "Teterevkov, Ivan" <Ivan.Teterevkov@amd.com>
To:     "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "jhubbard@nvidia.com" <jhubbard@nvidia.com>,
        "jack@suse.cz" <jack@suse.cz>,
        "rppt@linux.ibm.com" <rppt@linux.ibm.com>,
        "jglisse@redhat.com" <jglisse@redhat.com>,
        "ira.weiny@intel.com" <ira.weiny@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: find_get_page() VS pin_user_pages()
Thread-Topic: find_get_page() VS pin_user_pages()
Thread-Index: AdlsqyEC2Ib370amRP6esQRt2dSqSw==
Date:   Tue, 11 Apr 2023 19:43:16 +0000
Message-ID: <PH0PR12MB5606D4611050BC8B1CC430FEF09A9@PH0PR12MB5606.namprd12.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?J2i+Jkgzbq0ITEcE+XxFSzeUwcEFewJl4Ieh67ys6vwlqw1GQH0Ck0fmOikk?=
 =?us-ascii?Q?OYstwTheix7bgG5koMn2ss3MuP5bSL3YESQRO6Zh5eU3GVy3Hpop4/glwrvw?=
 =?us-ascii?Q?eOQ3J82Ii0eO7sPJLMKpnFRBWq+0rgbgP6WgJlsaZDKtUFLgs8rExi5Zzf5R?=
 =?us-ascii?Q?mxGwxl6Q1wR3Jn/Kd2nFMxBlaIM1SMBTeeoDLjQohnv0ssQmHwPmHf267eJG?=
 =?us-ascii?Q?1FMoa8etFtNnmobETDcSptjWrzrXgf7gx3HYSYlzNjYleRC5eJ979p55weWo?=
 =?us-ascii?Q?V4NsE+67ES+qLVEdGf5ITZQT/HrwVxDp7gVGVRx2oAQDB3AYvZMY7UcsYBSw?=
 =?us-ascii?Q?VeiVUtHDRoFoYR5hFKadSF7+vUN9zE2c6NSoQiYQ5EgH/tatTIAKJvgJodwv?=
 =?us-ascii?Q?/ZiN1FYHVzg8rUbDJrhlvbdX392dFzEMTGTdX81TtcY6nvSgfDyWTDR0RTZi?=
 =?us-ascii?Q?x2otKAMV800E/8/ItGNN6gTldZXCLMkz3cmeXYaekYxMGSAePT0f8GslK6Xc?=
 =?us-ascii?Q?QGeaw2j+j71oZHWwSccriWwl/r005577PKNjwqNvkdYqEPIPIXSILuAEDkfI?=
 =?us-ascii?Q?gMpD5aTQisU8WIUURH9QRl+gB0Hdy7y9prFB7eEhBFbPKlhOQAGWGFdCW6ef?=
 =?us-ascii?Q?WEHurPEo6Uaab43alN6yqjYzWEi5BAEurSu1QYqrMgrvvtYibnI4QTJvkLuy?=
 =?us-ascii?Q?LiqB6zDM0gawlj0i7raR2p3pMWkn2iv2kRN33jytAOx0WvXLaWKoilQfkpZC?=
 =?us-ascii?Q?zv+B3XqliSInyKankWVyHvDsoEutj3UE4WlogTKwVrzZCK9Hsj4KUkQXVR8X?=
 =?us-ascii?Q?EQZZ0Dh4zBKM+m85n0VgJxxp8cbBzYPnE10Sdg43cDnafdDrTjqkpmJys6ok?=
 =?us-ascii?Q?r4kZkdu2EHuuHXrPQdwrbuPj7ZAOQhmPEROoYhrGzhtgMMFag7gYf6MfYVmD?=
 =?us-ascii?Q?gvaKG7zlBBbERWm9ejmTi+kevNwAWpLz3CM91PF5uDwfCIzgFLnLsBCPdKD4?=
 =?us-ascii?Q?ZJ91gjawiWSlZY/dYaAxKdOUGtvQKeKSlFev+AAb2aDB5mZNPXbKh6tPfu8+?=
 =?us-ascii?Q?/z6tRoRzNKu8/uXTdKitin6DWoz/PmAGtbLHVwp2U10oXNLYcAQJ7E15imNN?=
 =?us-ascii?Q?/C/8drRXKQDPYLxuU2yYqjlmKG8LxP8TiJ5XAIf5Rx8ONjcB6fC3NRt2nj+O?=
 =?us-ascii?Q?KTOPGXpryBmygUOCbnWU0/Tq70frAfNDSq/uM8ZofkJ5WPLkaQqC9bYcKZOj?=
 =?us-ascii?Q?yjus6WUiSVTvIL3+YThJPcBE9k0hR046fdHzAbFRAxyN6ly/22ac2VYJNJUY?=
 =?us-ascii?Q?IDsg1W2rV7Sp5l82fJAL2am7E1y4KHa6Vm2Am3TR7XR15qzemrNsUTJSnWxk?=
 =?us-ascii?Q?Jn6pjjQMKDWNhUKY1jrh3uEqd+p/HxvTwgjL6pg0l+V3DyNZ2E73wq87imXg?=
 =?us-ascii?Q?tdf77Vw72BTapLbQpGcUCREPaItT0AePzpf/7iNvX7xwuu8cknYP+JwmaKZx?=
 =?us-ascii?Q?O59+bHcyi3tqTLwobhfRfvm0/H4nG4MsfSkZi1qpHVCNJjGT5zTebp9rpkaS?=
 =?us-ascii?Q?xvqMBBEiKIN/aYUFs7U=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR12MB5606.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fcfd9e41-946f-49cd-adb8-08db3ac4fefc
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2023 19:43:16.8807
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /kaWX3TK3QKBkKmBotMDHo679IsG6hg3sJ6/J6ebBqT2wkZwacJqoYaQhX4VwwGRk+Eyk2LhulUN7OYlBfeprw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8664
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,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
        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

Hello folks,

I work with an application which aims to share memory in the userspace and
interact with the NIC DMA. The memory allocation workflow begins in the
userspace, which creates a new file backed by 2MiB hugepages with
memfd_create(MFD_HUGETLB, MFD_HUGE_2MB) and fallocate(). Then the userspace
makes an IOCTL to the kernel module with the file descriptor and size so th=
at
the kernel module can get the struct page with find_get_page(). Then the ke=
rnel
module calls dma_map_single(page_address(page)) for NIC, which concludes th=
e
datapath. The allocated memory may (significantly) outlive the originating
userspace application. The hugepages stay mapped with NIC, and the kernel
module wants to continue using them and map to other applications that come=
 and
go with vm_mmap().

I am studying the pin_user_pages*() family of functions, and I wonder if th=
e
outlined workflow requires it. The hugepages do not page out, but they can =
move
as they may be allocated with GFP_HIGHUSER_MOVABLE. However, find_get_page(=
)
must increment the page reference counter without mapping and prevent it fr=
om
moving. In particular, https://docs.kernel.org/mm/page_migration.html:

> How migrate_pages() works
> ...
> Steps:
> ...
> 4. All the page table references to the page are converted to migration
>    entries. This decreases the mapcount of a page. If the resulting mapco=
unt
>    is not zero then we do not migrate the page.

Does find_get_page() achieve that condition or does the outlined workflow
still requires pin_user_pages*() for safe DMA?

Thanks in advance,
Ivan