From: Jeff Layton Date: Wed, 5 Oct 2011 00:43:03 +0000 (+1100) Subject: mm: iov_iter: have iov_iter_advance() decrement nr_segs appropriately X-Git-Tag: next-20111007~1^2~174 X-Git-Url: https://git.karo-electronics.de/?a=commitdiff_plain;h=0b20a560b6bf0ca1f3bb70e87b9711c4ff283015;p=karo-tx-linux.git mm: 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. Signed-off-by: Jeff Layton Cc: Nick Piggin Signed-off-by: Andrew Morton --- diff --git a/mm/filemap.c b/mm/filemap.c index e496e6ab6f02..edd58959ec4a 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) { iov++; + nr_segs--; base = 0; } } i->iov = iov; i->iov_offset = base; + i->nr_segs = nr_segs; } } EXPORT_SYMBOL(iov_iter_advance);