On Mon, 27 Feb 2012 15:11:35 -0800, Andrew Morton [off-list ref] wrote:

On Sun, 26 Feb 2012 23:49:58 +0530
"Aneesh Kumar K.V" [off-list ref] wrote:

quoted

From: "Aneesh Kumar K.V" <redacted>

Drop using inode->i_mutex from read, since that can result in deadlock with
mmap. Ideally we can extend the patch to make sure we don't increase i_size
in mmap. But that will break userspace, because application will have to now
use truncate(2) to increase i_size in hugetlbfs.

AFAIU i_mutex was added in hugetlbfs_read as per
http://lkml.indiana.edu/hypermail/linux/kernel/0707.2/3066.html

This patch comes somewhat out of the blue and I'm unsure what's going on.

You say there's some (potential?) deadlock with mmap, but it is
undescribed.  Have people observed this deadlock?  Has it caused
lockdep warnings?  Please update the changelog to fully describe the
bug.

Viro explained the deadlock in detail here:

http://mid.gmane.org/20120217002726.GL23916@ZenIV.linux.org.uk

I will also update the commit message with this information.

Also, the new truncate_sem is undoumented.  This leaves readers to work
out for themselves what it might be for.  Please let's add code
comments which completely describe the race, and how this lock prevents
it.

We should also document our locking rules.  When should code take this
lock?  What are its ranking rules with respect to i_mutex, i_mmap_mutex
and possibly others?

Will update the patch with these details

Thanks
-aneesh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>