On Mon, 15 Aug 2011 14:07:26 -0400
Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> Currently, when you call iov_iter_advance, then the pointer to the kvec
> 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 kvec in an array. Many of the other routines that deal
> with iov_iter have optimized codepaths when nr_segs == 1.
>
> Cc: Nick Piggin <npiggin@xxxxxxx>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ---
> mm/filemap.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
...and of course, I got the description wrong:
s/kvec/iovec/
...I believe the patch itself is fine though.
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 645a080..86508cc 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2113,6 +2113,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
> @@ -2128,11 +2129,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);
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
