path: root/mm/filemap.c
diff options
authorJeff Layton <>2011-10-27 23:53:08 +0200
committerChristoph Hellwig <>2011-10-28 13:55:08 +0200
commit39be79c16f2b8eb07dd0d4e965cddfe39cc0534a (patch)
tree821611221295d47c671ec72e1fb558efcedff03b /mm/filemap.c
parentc3b92c8787367a8bb53d57d9789b558f1295cc96 (diff)
vfs: iov_iter: have iov_iter_advance decrement nr_segs appropriately
Currently, when you call iov_iter_advance, then the pointer to the iovec array can be incremented, but it does not decrement the nr_segs value in the iov_iter struct. The result is a iov_iter struct with a nr_segs value that goes beyond the end of the array. While I'm not aware of anything that's specifically broken by this, it seems odd and a bit dangerous not to decrement that value. If someone were to trust the nr_segs value to be correct, then they could end up walking off the end of the array. Changing this might also provide some micro-optimization when dealing with the last iovec in an array. Many of the other routines that deal with iov_iter have optimized codepaths when nr_segs == 1. Cc: Nick Piggin <> Signed-off-by: Jeff Layton <> Signed-off-by: Christoph Hellwig <>
Diffstat (limited to 'mm/filemap.c')
1 files changed, 3 insertions, 0 deletions
diff --git a/mm/filemap.c b/mm/filemap.c
index 7771871fa353..5cf820a7c8ec 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2115,6 +2115,7 @@ void iov_iter_advance(struct iov_iter *i, size_t bytes)
} else {
const struct iovec *iov = i->iov;
size_t base = i->iov_offset;
+ unsigned long nr_segs = i->nr_segs;
* The !iov->iov_len check ensures we skip over unlikely
@@ -2130,11 +2131,13 @@ void iov_iter_advance(struct iov_iter *i, size_t bytes)
base += copy;
if (iov->iov_len == base) {
+ nr_segs--;
base = 0;
i->iov = iov;
i->iov_offset = base;
+ i->nr_segs = nr_segs;