Joonas Lahtinen <joonas.lahti...@linux.intel.com> 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.kuopp...@linux.intel.com/
v2: https://lore.kernel.org/dri-devel/20241220113108.2386842-1-mika.kuopp...@linux.intel.com/ -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.
