On 02/26, Cyrill Gorcunov wrote: > > On Thu, Feb 26, 2015 at 11:36:57AM -0800, Davidlohr Bueso wrote: > > We currently use the mmap_sem to serialize the mm exe_file. > > This is atrocious and a clear example of the misuses this > > lock has all over the place, making any significant changes > > to the address space locking that much more complex and tedious. > > This also has to do of how we used to check for the vma's vm_file > > being VM_EXECUTABLE (much of which was replaced by 2dd8ad81e31). > > > > This patch, therefore, removes the mmap_sem dependency and > > introduces a specific lock for the exe_file (rwlock_t, as it is > > read mostly and protects a trivial critical region). As mentioned, > > the motivation is to cleanup mmap_sem (as opposed to exe_file > > performance). Well, I didn't see the patch, can't really comment. But I have to admit that this looks as atrocious and a clear example of "lets add yet another random lock which we will regret about later" ;) rwlock_t in mm_struct just to serialize access to exe_file? > A nice side effect of this is that we avoid taking > > the mmap_sem (shared) in fork paths for the exe_file handling > > (note that readers block when the rwsem is taken exclusively by > > another thread). Yes, this is ugly. Can't we kill this dup_mm_exe_file() and copy change dup_mmap() to also dup ->exe_file ? > Hi Davidlohr, it would be interesting to know if the cleanup > bring some performance benefit? To me the main question is whether the patch makes this code simpler or uglier ;) Oleg. -- 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>