On Tue, Dec 13, 2022 at 11:49:13PM +0000, Huang, Kai wrote: > > > > memfd_restricted() itself is implemented as a shim layer on top of real > > memory file systems (currently tmpfs). Pages in restrictedmem are marked > > as unmovable and unevictable, this is required for current confidential > > usage. But in future this might be changed. > > > > > I didn't dig full histroy, but I interpret this as we don't support page > migration and swapping for restricted memfd for now. IMHO "page marked as > unmovable" can be confused with PageMovable(), which is a different thing from > this series. It's better to just say something like "those pages cannot be > migrated and swapped". Yes, if that helps some clarification. > > [...] > > > + > > + /* > > + * These pages are currently unmovable so don't place them into movable > > + * pageblocks (e.g. CMA and ZONE_MOVABLE). > > + */ > > + mapping = memfd->f_mapping; > > + mapping_set_unevictable(mapping); > > + mapping_set_gfp_mask(mapping, > > + mapping_gfp_mask(mapping) & ~__GFP_MOVABLE); > > But, IIUC removing __GFP_MOVABLE flag here only makes page allocation from non- > movable zones, but doesn't necessarily prevent page from being migrated. My > first glance is you need to implement either a_ops->migrate_folio() or just > get_page() after faulting in the page to prevent. The current api restrictedmem_get_page() already does this, after the caller calling it, it holds a reference to the page. The caller then decides when to call put_page() appropriately. > > So I think the comment also needs improvement -- IMHO we can just call out > currently those pages cannot be migrated and swapped, which is clearer (and the > latter justifies mapping_set_unevictable() clearly). Good to me. Thanks, Chao > >
