I think the backport is wrong. Let me explain why:
The first filemap_set_next_iovec() finds a {NULL, 0} iovec
Then if "!segment_eq(get_fs(), KERNEL_DS)" (write is from userspace), the variable bytes will be equal to 0 (because cur_iov->iov_len - iov_base == 0).
Then it will goto zero_length_segment
And here the patch changed the behaviour, before the test was ">= 0" so it included the case where the iovec was empty, and then it finished by calling filemap_set_next_iovec() which would advance from at least one iovec before continuing.
Now it test for "> 0" so nothing will happen before the continue instruction. Hence the infinite loop.
If you look at the history for this file: git.kernel. org/?p= linux/kernel/ git/torvalds/ linux-2. 6.git;a= history; f=mm/filemap. c;h=54e96865085 50b198b4779df04 8bbfe46b2ddb08; hb=HEAD
http://
You'll see that http:// git.kernel. org/?p= linux/kernel/ git/torvalds/ linux-2. 6.git;a= commit; h=64649a58919e6 6ec21792dbb6c48 cb3da22cbd7f was backported.
I think the backport is wrong. Let me explain why: set_next_ iovec() finds a {NULL, 0} iovec eq(get_ fs(), KERNEL_DS)" (write is from userspace), the variable bytes will be equal to 0 (because cur_iov->iov_len - iov_base == 0). set_next_ iovec() which would advance from at least one iovec before continuing.
The first filemap_
Then if "!segment_
Then it will goto zero_length_segment
And here the patch changed the behaviour, before the test was ">= 0" so it included the case where the iovec was empty, and then it finished by calling filemap_
Now it test for "> 0" so nothing will happen before the continue instruction. Hence the infinite loop.