From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Trond Myklebust <trondmy@gmail.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Trond Myklebust <trond.myklebust@hammerspace.com>
Subject: Re: linux-next: manual merge of the cel tree with the nfs tree
Date: Thu, 17 Dec 2020 12:52:00 +1100 [thread overview]
Message-ID: <20201217125200.2700c85e@canb.auug.org.au> (raw)
In-Reply-To: <20201215114150.61178713@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 5267 bytes --]
Hi all,
On Tue, 15 Dec 2020 11:41:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the cel tree got a conflict in:
>
> include/linux/sunrpc/xdr.h
>
> between commits:
>
> 9a20f6f4e6ba ("SUNRPC: Fixes for xdr_align_data()")
> c4f2f591f02c ("SUNRPC: Fix xdr_expand_hole()")
> f8d0e60f1056 ("SUNRPC: Cleanup - constify a number of xdr_buf helpers")
>
> from the nfs tree and commits:
>
> 5a7e702670ad ("SUNRPC: Adjust synopsis of xdr_buf_subsegment()")
> c1346a1216ab ("NFSD: Replace the internals of the READ_BUF() macro")
>
> from the cel tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
>
> diff --cc include/linux/sunrpc/xdr.h
> index 68d49fdc4ee9,9b35ce50cf2b..000000000000
> --- a/include/linux/sunrpc/xdr.h
> +++ b/include/linux/sunrpc/xdr.h
> @@@ -182,14 -182,15 +182,15 @@@ xdr_adjust_iovec(struct kvec *iov, __be
> * XDR buffer helper functions
> */
> extern void xdr_shift_buf(struct xdr_buf *, size_t);
> -extern void xdr_buf_from_iov(struct kvec *, struct xdr_buf *);
> +extern void xdr_buf_from_iov(const struct kvec *, struct xdr_buf *);
> - extern int xdr_buf_subsegment(const struct xdr_buf *, struct xdr_buf *, unsigned int, unsigned int);
> + extern int xdr_buf_subsegment(const struct xdr_buf *buf, struct xdr_buf *subbuf,
> + unsigned int base, unsigned int len);
> extern void xdr_buf_trim(struct xdr_buf *, unsigned int);
> -extern int read_bytes_from_xdr_buf(struct xdr_buf *, unsigned int, void *, unsigned int);
> -extern int write_bytes_to_xdr_buf(struct xdr_buf *, unsigned int, void *, unsigned int);
> +extern int read_bytes_from_xdr_buf(const struct xdr_buf *, unsigned int, void *, unsigned int);
> +extern int write_bytes_to_xdr_buf(const struct xdr_buf *, unsigned int, void *, unsigned int);
>
> -extern int xdr_encode_word(struct xdr_buf *, unsigned int, u32);
> -extern int xdr_decode_word(struct xdr_buf *, unsigned int, u32 *);
> +extern int xdr_encode_word(const struct xdr_buf *, unsigned int, u32);
> +extern int xdr_decode_word(const struct xdr_buf *, unsigned int, u32 *);
>
> struct xdr_array2_desc;
> typedef int (*xdr_xcode_elem_t)(struct xdr_array2_desc *desc, void *elem);
> @@@ -250,10 -251,54 +251,54 @@@ extern void xdr_init_decode_pages(struc
> extern __be32 *xdr_inline_decode(struct xdr_stream *xdr, size_t nbytes);
> extern unsigned int xdr_read_pages(struct xdr_stream *xdr, unsigned int len);
> extern void xdr_enter_page(struct xdr_stream *xdr, unsigned int len);
> -extern int xdr_process_buf(struct xdr_buf *buf, unsigned int offset, unsigned int len, int (*actor)(struct scatterlist *, void *), void *data);
> -extern uint64_t xdr_align_data(struct xdr_stream *, uint64_t, uint32_t);
> -extern uint64_t xdr_expand_hole(struct xdr_stream *, uint64_t, uint64_t);
> +extern int xdr_process_buf(const struct xdr_buf *buf, unsigned int offset, unsigned int len, int (*actor)(struct scatterlist *, void *), void *data);
> +extern unsigned int xdr_align_data(struct xdr_stream *, unsigned int offset, unsigned int length);
> +extern unsigned int xdr_expand_hole(struct xdr_stream *, unsigned int offset, unsigned int length);
> + extern bool xdr_stream_subsegment(struct xdr_stream *xdr, struct xdr_buf *subbuf,
> + unsigned int len);
> +
> + /**
> + * xdr_set_scratch_buffer - Attach a scratch buffer for decoding data.
> + * @xdr: pointer to xdr_stream struct
> + * @buf: pointer to an empty buffer
> + * @buflen: size of 'buf'
> + *
> + * The scratch buffer is used when decoding from an array of pages.
> + * If an xdr_inline_decode() call spans across page boundaries, then
> + * we copy the data into the scratch buffer in order to allow linear
> + * access.
> + */
> + static inline void
> + xdr_set_scratch_buffer(struct xdr_stream *xdr, void *buf, size_t buflen)
> + {
> + xdr->scratch.iov_base = buf;
> + xdr->scratch.iov_len = buflen;
> + }
> +
> + /**
> + * xdr_set_scratch_page - Attach a scratch buffer for decoding data
> + * @xdr: pointer to xdr_stream struct
> + * @page: an anonymous page
> + *
> + * See xdr_set_scratch_buffer().
> + */
> + static inline void
> + xdr_set_scratch_page(struct xdr_stream *xdr, struct page *page)
> + {
> + xdr_set_scratch_buffer(xdr, page_address(page), PAGE_SIZE);
> + }
> +
> + /**
> + * xdr_reset_scratch_buffer - Clear scratch buffer information
> + * @xdr: pointer to xdr_stream struct
> + *
> + * See xdr_set_scratch_buffer().
> + */
> + static inline void
> + xdr_reset_scratch_buffer(struct xdr_stream *xdr)
> + {
> + xdr_set_scratch_buffer(xdr, NULL, 0);
> + }
>
> /**
> * xdr_stream_remaining - Return the number of bytes remaining in the stream
This is now a conflict between the nfs tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2020-12-17 1:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-15 0:41 linux-next: manual merge of the cel tree with the nfs tree Stephen Rothwell
2020-12-17 1:52 ` Stephen Rothwell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201217125200.2700c85e@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=chuck.lever@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
--cc=trondmy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).