On Mon, Aug 08, 2022 at 08:10:22AM +0200, Greg Kroah-Hartman wrote: > On Sun, Aug 07, 2022 at 02:25:33PM +0300, Oded Gabbay wrote: > > 2. Common code to handle drivers that want to allow a single user at a > > time to run open the device char file. > > Note, that's an impossible request, and one that the kernel should never > worry about, so don't even try it. Think about userspace doing an call > to dup() on an open char file descriptor and then passing that off > somewhere else. Oded is talking about a model like VFIO has where the HW has a limited number of concurrent state registers - lets say in this case the ASID translation mapping the accelerator into DMA. Each 'struct file' that is created owns one of those HW state registers, and each struct file is completely isolated from all others. eg someone controlling the accelerator through struct file A cannot access memory mapped into the accelerator through struct file B. So, the number of struct files that can be created is capped at the number of HW state registers the device can support (eg one for Habana). This is different from the number of FDs pointing at the struct file. Userpsace can open a HW state and point a lot of FDs at it, that is userspace's problem. From a kernel view they all share one struct file and thus one HW state. Jason
