I'm not sure what the best way to fix this is. One option is to
always make
a copy of the iovec and pass that down. Any other thoughts ?
Can we use this as another motivation to introduce an iovec container
struct instead of passing a raw iov/seg? The transition could turn
hand-rolled functions like pipe_iov_copy_to_user() into functions
that this iovec struct API provides.
I don't know if this would specifically help aio_rw_vect_retry() to
know if it should advance the iovec on behalf of its callee who
returned positive result codes.
Maybe it could use the API to discover a case where ret < size &&
cur_pos(iov_struct) == initial_pos(iov_struct) via some iovec pos
query before rw_op is called?
Or maybe the introduction of the API could normalize where the
responsibility of advancing the iovec lies. That might be a bit much.
Just talkin' here.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
