On Fri, Apr 24, 2015 at 7:04 AM, Andreas Gruenbacher
<andreas.gruenbacher@xxxxxxxxx> wrote:
> When encoding large, variable-length objects such as acls into xdr_bufs, it is
> easier to allocate buffer pages on demand rather than computing the required
> buffer size beforehand.
>
> Signed-off-by: Andreas Gruenbacher <agruenba@xxxxxxxxxx>
> ---
> net/sunrpc/xdr.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c
> index 4439ac4..062951b 100644
> --- a/net/sunrpc/xdr.c
> +++ b/net/sunrpc/xdr.c
> @@ -537,6 +537,14 @@ static __be32 *xdr_get_next_encode_buffer(struct xdr_stream *xdr,
> */
> xdr->scratch.iov_base = xdr->p;
> xdr->scratch.iov_len = frag1bytes;
> +
> + if (!*xdr->page_ptr) {
> + struct page *page = alloc_page(GFP_KERNEL);
> + if (!page)
> + return ERR_PTR(-ENOMEM);
> + *xdr->page_ptr = page;
> + }
> +
> p = page_address(*xdr->page_ptr);
> /*
> * Note this is where the next encode will start after we've
>
xdr_get_next_encode() should return NULL on failure, not ENOMEM.
Why is this trying to do a GFP_KERNEL allocation inside an XDR routine
anyway? That's not an I/O safe sleep.
Trond
--
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
