diff options
| author | Jeff Layton <jlayton@redhat.com> | 2011-10-27 23:53:08 +0200 |
|---|---|---|
| committer | Christoph Hellwig <hch@serles.lst.de> | 2011-10-28 13:55:08 +0200 |
| commit | 39be79c16f2b8eb07dd0d4e965cddfe39cc0534a (patch) | |
| tree | 821611221295d47c671ec72e1fb558efcedff03b | |
| parent | c3b92c8787367a8bb53d57d9789b558f1295cc96 (diff) | |
| download | linux-39be79c16f2b8eb07dd0d4e965cddfe39cc0534a.tar.bz2 | |
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 <npiggin@suse.de>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
| -rw-r--r-- | mm/filemap.c | 3 |
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) { iov++; + nr_segs--; base = 0; } } i->iov = iov; i->iov_offset = base; + i->nr_segs = nr_segs; } } EXPORT_SYMBOL(iov_iter_advance); |