[..] > > I'm not suggesting to busy the whole "virtio" range, just the portion > > that's about to be passed to add_memory_driver_managed(). > > I'm afraid I don't get your point. For virtio-mem: > > Before: > > 1. Create virtio0 container resource > > 2. (somewhen in the future) add_memory_driver_managed() > - Create resource (System RAM (virtio_mem)), marking it busy/driver > managed > > After: > > 1. Create virtio0 container resource > > 2. (somewhen in the future) Create resource (System RAM (virtio_mem)), > marking it busy/driver managed > 3. add_memory_driver_managed() > > Not helpful or simpler IMHO. The concern I'm trying to address is the theoretical race window and layering violation in this sequence in the kmem driver: 1/ res = request_mem_region(...); 2/ res->flags = IORESOURCE_MEM; 3/ add_memory_driver_managed(); Between 2/ and 3/ something can race and think that it owns the region. Do I think it will happen in practice, no, but it's still a pattern that deserves come cleanup. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
