On Sun, Aug 27, 2023 at 07:05:59PM +0000, Kasireddy, Vivek wrote: > Hi Jason, David, > > > > > Sure, we can simply always fail when we detect ZONE_MOVABLE or > > > MIGRATE_CMA. > > > > Maybe that keeps at least some use cases working. > > > > > > That seems fairly reasonable > > AFAICS, failing udmabuf_create() if we detect one or more pages are in > > ZONE_MOVABLE or MIGRATE_CMA would not be a recoverable failure -- > > as it would result in the failure of Guest GUI (or compositor). Yes, you can't use whatever this driver is while enabling MOVABLE or CMA in your kernel boot. > > I think it makes sense to have a generic version of > > And, since check_and_migrate_movable_pages() is GUP-specific, would > > it be ok to create a generic version of that (in mm/migrate.c) which can be > > used by udmabuf and/or other drivers in the future? > Sorry, I accidentally sent this earlier email before finishing it. > What I meant to say is since the same situation (inadvertently pinning pages > in movable) may probably arise in the future with another driver, Why? It was a big mistake to design a uAPI around taking in a FD and extracting pages from it, we don't have kernel infrastructure for that, and code liek that does not belong outside the MM at all. > I think it makes sense to have a generic (non-GUP) version of > check_and_migrate_movable_pages() available in migration.h that > drivers can use to ensure that they don't break memory hotunplug > accidentally. Definately not. Either use the VMA and pin_user_pages(), or implement pin_user_pages_fd() in core code. Do not open code something wonky in drivers. Jason
