linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

      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).