Description of problem: There's a possible deadlock in generic_file_splice_write(), splice_from_pipe() and ocfs2_file_splice_write(): - task A calls generic_file_splice_write() - this calls inode_double_lock(), which locks i_mutex on both pipe->inode and target inode - ordering depends on inode pointers, can happen that pipe->inode is locked first - __splice_from_pipe() needs more data, calls pipe_wait() - this releases lock on pipe->inode, goes to interruptible sleep - task B calls generic_file_splice_write(), similarly to the first - this locks pipe->inode, then tries to lock inode, but that is already held by task A - task A is interrupted, it tries to lock pipe->inode, but fails, as it is already held by task B - ABBA deadlock Fix this by explicitly ordering locks: the outer lock must be on target inode and the inner lock (which is later unlocked and relocked) must be on pipe->inode. This is OK, pipe inodes and target inodes form two nonoverlapping sets, generic_file_splice_write() and friends are not called with a target which is a pipe. Upstream commits: http://git.kernel.org/linus/7bfac9ecf0585962fe13584f5cf526d8c8e76f17 http://git.kernel.org/linus/b3c2d2ddd63944ef2a1e4a43077b602288107e01 http://git.kernel.org/linus/2933970b960223076d6affcf7a77e2bc546b8102 http://git.kernel.org/linus/eb443e5a25d43996deb62b9bcee1a4ce5dea2ead http://git.kernel.org/linus/328eaaba4e41a04c1dc4679d65bea3fee4349d86 Reference: http://article.gmane.org/gmane.comp.security.oss.general/1809
inode_double_{lock,unlock}() were introduced in commit 62752ee198dca9209 (v2.6.19-rc3).
This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2009:1157 https://rhn.redhat.com/errata/RHSA-2009-1157.html
Statement: This issue does not affect versions of Linux kernel as shipped with Red Hat Enterprise Linux 5, 6 and Red Hat Enterprise Linux MRG 2. This issue was fixed in Red Hat Enterprise Linux MRG 1 via https://rhn.redhat.com/errata/RHSA-2009-1157.html.