Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> writes: > Quoting Joonas Lahtinen (2024-12-11 14:59:33) >> Quoting Christian König (2024-12-10 16:03:14) > > <SNIP> > >> > If you really want to expose an interface to userspace which walks the process >> > page table, installs an MMU notifier, kmaps the resulting page and then memcpy >> > to/from it then you absolutely *must* run that by guys like Christoph Hellwig, >> > Andrew and even Linus. > >> > I'm pretty sure that those guys will note that a device driver should >> > absolutely not mess with such stuff. > > <SNIP> > >> > But that seems like a high-overhead thing to do due to the overhead of >> > setting up a transfer per data word and going over the PCI bus twice >> > compared to accessing the memory directly by CPU when it trivially can. >> > >> > >> > Understandable, but that will create another way of accessing process memory. > > Based on this feedback and some further discussion, we now have an alternative > implementation for this interface via access_process_vm function posted by Mika: > > https://lore.kernel.org/dri-devel/20241216141721.2051279-1-mika.kuoppala@xxxxxxxxxxxxxxx/ v2: https://lore.kernel.org/dri-devel/20241220113108.2386842-1-mika.kuoppala@xxxxxxxxxxxxxxx/ -Mika > > It's a couple of dozen lines don't need to do any open-coded kmapping, only utilizing > the pre-existing memory access functions. > > Hopefully that would address the above concerns? > > Regards, Joonas > > PS. It could still be optimized further to directly use the struct mm > from within the mm notifier, and go with access_remote_vm using that, > but would require new symbol export. > > For demonstration it is implemented by grabbing the task_struct and using > the already exported access_process_vm function.
