Commit 1196bdce authored by Chuck Lever's avatar Chuck Lever
Browse files

SUNRPC: Document validity guarantees of the pointer returned by reserve_space 



A subtlety of this API is that if the @nbytes region traverses a
page boundary, the next __xdr_commit_encode will shift the data item
in the XDR encode buffer. This makes the returned pointer point to
something else, leading to unexpected behavior.

There are a few cases where the caller saves the returned pointer
and then later uses it to insert a computed value into an earlier
part of the stream. This can be safe only if either:

 - the data item is guaranteed to be in the XDR buffer's head, and
   thus is not ever going to be near a page boundary, or
 - the data item is no larger than 4 octets, since XDR alignment
   rules require all data items to start on 4-octet boundaries

But that safety is only an artifact of the current implementation.
It would be less brittle if these "safe" uses were eventually
replaced.

Reviewed-by: default avatarNeilBrown <neilb@suse.de>
Reviewed-by: default avatarJeff Layton <jlayton@kernel.org>
Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
parent 4163ee71

net/sunrpc/xdr.c

+6 −0
Original line number Diff line number Diff line
@@ -1097,6 +1097,12 @@ static noinline __be32 *xdr_get_next_encode_buffer(struct xdr_stream *xdr, 
 * Checks that we have enough buffer space to encode 'nbytes' more

 * bytes of data. If so, update the total xdr_buf length, and

 * adjust the length of the current kvec.

 *

 * The returned pointer is valid only until the next call to

 * xdr_reserve_space() or xdr_commit_encode() on @xdr. The current

 * implementation of this API guarantees that space reserved for a

 * four-byte data item remains valid until @xdr is destroyed, but

 * that might not always be true in the future.

 */

__be32 * xdr_reserve_space(struct xdr_stream *xdr, size_t nbytes)

{