Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2014-07-07 at 12:11 +0200, joro@xxxxxxxxxx wrote:
> On Sun, Jul 06, 2014 at 07:25:18PM +0000, Gabbay, Oded wrote:
> > Once we can agree on that, than I think we can agree that kfd and hmm
> > can and should be bounded to mm struct and not file descriptors.
> 
> The file descriptor concept is the way it works in the rest of the
> kernel. It works for numerous drivers and subsystems (KVM, VFIO, UIO,
> ...), when you close a file descriptor handed out from any of those
> drivers (already in the kernel) all related resources will be freed. I
> don't see a reason why HSA drivers should break these expectations and
> be different.
> 
> 
> 	Joerg
> 
> 
As Jerome pointed out, there are a couple of subsystems/drivers who
don't rely on file descriptors but on the tear-down of mm struct, e.g.
aio, ksm, uprobes, khugepaged

So, based on this fact, I don't think that the argument of "The file
descriptor concept is the way it works in the rest of the kernel" and
only HSA/HMM now wants to change the rules, is a valid argument.

Jerome and I are saying that HMM and HSA, respectively, are additional
use cases of binding to mm struct. If you don't agree with that, than I
would like to hear why, but you can't say that no one else in the kernel
needs notification of mm struct tear-down.

As for the reasons why HSA drivers should follow aio,ksm,etc. and not
other drivers, I will repeat that our ioctls operate on a process
context and not on a device context. Moreover, the calling process
actually is sometimes not aware on which device it runs! 

A prime example of why HSA is not a regular device-driver, and operates
in context of a process and not a specific device is the fact that in
the near future (3-4 months), kfd_open() will actually bind a process
address space to a *set* of devices, each of which could have its *own*
device driver (eg radeon for the CI device, other amd drivers for future
devices). I Assume HMM can be considered in the same way. 

	Oded




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]