From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler. Date: Fri, 4 Jul 2014 01:15:41 +0200 Message-ID: <20140703231541.GR26537@8bytes.org> References: <20140630160604.GF1956@gmail.com> <20140630181623.GE26537@8bytes.org> <20140630183556.GB3280@gmail.com> <20140701091535.GF26537@8bytes.org> <019CCE693E457142B37B791721487FD91806DD8B@storexdag01.amd.com> <20140701110018.GH26537@8bytes.org> <20140701193343.GB3322@gmail.com> <20140701210620.GL26537@8bytes.org> <20140701213208.GC3322@gmail.com> <20140703183024.GA3306@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20140703183024.GA3306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Jerome Glisse Cc: peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, Sherry Cheung , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , "Gabbay, Oded" , "hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org" , "aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , Jatin Kumar , Lucien Dunning , "mgorman-l3A5Bk7waGM@public.gmane.org" , "jweiner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , Subhash Gutti , "riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "Bridgman, John" , John Hubbard , Mark Hairgrove , Cameron Buschardt , Duncan Poole , "Cornwall, Jay" , "Lewycky, Andrew" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" Arvind Gopalakrishnan List-Id: linux-mm.kvack.org Hi Jerome, On Thu, Jul 03, 2014 at 02:30:26PM -0400, Jerome Glisse wrote: > Joerg do you still object to this patch ? Yes. > Again the natural place to call this is from mmput and the fact that many > other subsystem already call in from there to cleanup there own per mm data > structure is a testimony that this is a valid use case and valid design. Device drivers are something different than subsystems. I think the point that the mmu_notifier struct can not be freed in the .release call-back is a weak reason for introducing a new notifier. In the end every user of mmu_notifiers has to call mmu_notifier_register somewhere (file-open/ioctl path or somewhere else where the mm<->device binding is set up) and can call mmu_notifier_unregister in a similar path which destroys the binding. > You pointed out that the cleanup should be done from the device driver file > close call. But as i stressed some of the new user will not necessarily have > a device file open hence no way for them to free the associated structure > except with hackish delayed job. Please tell me more about these 'new users', how does mm<->device binding is set up there if no fd is used? Joerg