On Thu, Mar 08, 2012 at 01:40:50PM -0800, Andrew Morton wrote: > OK, thanks, yup. Taking i_mutex in file_operations.mmap() is wrong. ... or in .release() (munmap() does fput() under mmap_sem). > Is hugetlbfs actually deadlockable because of this, or is it the case > that the i_mutex->mmap_sem ordering happens to never happen for this > filesystem? Yes, it is. Look at read(2) on hugetlbfs; it copies userland data while holding ->i_mutex. So we have read(2): mutex_lock(&A) down_read(&B) mmap(2): down_write(&B); mutex_lock(&A); which is an obvious deadlock. > So we need to pull the i_mutex out of hugetlbfs_file_mmap(). IIRC, you have a patch in your tree doing just that... -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>