linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the nvdimm tree with the vfs tree
@ 2020-09-24  6:45 Stephen Rothwell
  2020-09-24 14:10 ` Dan Williams
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Rothwell @ 2020-09-24  6:45 UTC (permalink / raw)
  To: Dan Williams, Al Viro
  Cc: Josh Poimboeuf, Vishal Verma, Linux Next Mailing List,
	Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Hi all,

Today's linux-next merge of the nvdimm tree got a conflict in:

  lib/iov_iter.c

between commit:

  e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess speculation")

from the vfs tree and commit:

  0a78de3d4b7b ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()")

from the nvdimm tree.

I fixed it up (I just used the latter, but I suspect that more work is
needed) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: linux-next: manual merge of the nvdimm tree with the vfs tree
  2020-09-24  6:45 linux-next: manual merge of the nvdimm tree with the vfs tree Stephen Rothwell
@ 2020-09-24 14:10 ` Dan Williams
  2020-09-24 14:31   ` Dan Williams
  0 siblings, 1 reply; 5+ messages in thread
From: Dan Williams @ 2020-09-24 14:10 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Josh Poimboeuf, Vishal Verma, Linux Next Mailing List,
	Linux Kernel Mailing List

On Wed, Sep 23, 2020 at 11:45 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
>   lib/iov_iter.c
>
> between commit:
>
>   e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess speculation")
>
> from the vfs tree and commit:
>
>   0a78de3d4b7b ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()")
>
> from the nvdimm tree.
>
> I fixed it up (I just used the latter, but I suspect that more work is
> needed) 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.

I messed up, this shouldn't be present in -next, yet. Will remove.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: linux-next: manual merge of the nvdimm tree with the vfs tree
  2020-09-24 14:10 ` Dan Williams
@ 2020-09-24 14:31   ` Dan Williams
  0 siblings, 0 replies; 5+ messages in thread
From: Dan Williams @ 2020-09-24 14:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Josh Poimboeuf, Vishal Verma, Linux Next Mailing List,
	Linux Kernel Mailing List, Ingo Molnar

[ add Ingo ]

On Thu, Sep 24, 2020 at 7:10 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Wed, Sep 23, 2020 at 11:45 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the nvdimm tree got a conflict in:
> >
> >   lib/iov_iter.c
> >
> > between commit:
> >
> >   e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess speculation")
> >
> > from the vfs tree and commit:
> >
> >   0a78de3d4b7b ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()")
> >
> > from the nvdimm tree.
> >
> > I fixed it up (I just used the latter, but I suspect that more work is
> > needed) 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.
>
> I messed up, this shouldn't be present in -next, yet. Will remove.

Oh, wait, this isn't from a new push this was back from the v5.9 merge
attempt and is only just now causing conflicts. Ingo, how does tip.git
usually coordinate with vfs.git? Should I rebase on vfs / work the
copy_mc_to_{user,kernel} patches through Al, or?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* linux-next: manual merge of the nvdimm tree with the vfs tree
@ 2020-09-24  6:38 Stephen Rothwell
  0 siblings, 0 replies; 5+ messages in thread
From: Stephen Rothwell @ 2020-09-24  6:38 UTC (permalink / raw)
  To: Dan Williams, Al Viro
  Cc: Vishal Verma, Josh Poimboeuf, Linux Next Mailing List,
	Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Hi all,

Today's linux-next merge of the nvdimm tree got conflicts in:

  arch/x86/include/asm/uaccess_64.h

between commit:

  e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess speculation")

from the vfs tree and commit:

  0a78de3d4b7b ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()")

from the nvdimm tree.

I fixed it up (the latter just removed copy_to_user_mcsafe from this file,
so I did that) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* linux-next: manual merge of the nvdimm tree with the vfs tree
@ 2017-07-03  6:41 Stephen Rothwell
  0 siblings, 0 replies; 5+ messages in thread
From: Stephen Rothwell @ 2017-07-03  6:41 UTC (permalink / raw)
  To: Dan Williams, Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi Dan,

Today's linux-next merge of the nvdimm tree got conflicts in:

  include/linux/uio.h
  lib/iov_iter.c

between commit:

  aa28de275a24 ("iov_iter/hardening: move object size checks to inlined part")

from the vfs tree and commit:

  0aed55af8834 ("x86, uaccess: introduce copy_from_iter_flushcache for pmem / cache-bypass operations")

from the nvdimm 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.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/uio.h
index 243e2362fe1a,55cd54a0e941..000000000000
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@@ -92,58 -91,26 +92,74 @@@ size_t copy_page_to_iter(struct page *p
  			 struct iov_iter *i);
  size_t copy_page_from_iter(struct page *page, size_t offset, size_t bytes,
  			 struct iov_iter *i);
 -size_t copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i);
 -size_t copy_from_iter(void *addr, size_t bytes, struct iov_iter *i);
 -bool copy_from_iter_full(void *addr, size_t bytes, struct iov_iter *i);
 -size_t copy_from_iter_nocache(void *addr, size_t bytes, struct iov_iter *i);
 +
 +size_t _copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i);
 +size_t _copy_from_iter(void *addr, size_t bytes, struct iov_iter *i);
 +bool _copy_from_iter_full(void *addr, size_t bytes, struct iov_iter *i);
 +size_t _copy_from_iter_nocache(void *addr, size_t bytes, struct iov_iter *i);
 +bool _copy_from_iter_full_nocache(void *addr, size_t bytes, struct iov_iter *i);
 +
 +static __always_inline __must_check
 +size_t copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i)
 +{
 +	if (unlikely(!check_copy_size(addr, bytes, true)))
 +		return bytes;
 +	else
 +		return _copy_to_iter(addr, bytes, i);
 +}
 +
 +static __always_inline __must_check
 +size_t copy_from_iter(void *addr, size_t bytes, struct iov_iter *i)
 +{
 +	if (unlikely(!check_copy_size(addr, bytes, false)))
 +		return bytes;
 +	else
 +		return _copy_from_iter(addr, bytes, i);
 +}
 +
 +static __always_inline __must_check
 +bool copy_from_iter_full(void *addr, size_t bytes, struct iov_iter *i)
 +{
 +	if (unlikely(!check_copy_size(addr, bytes, false)))
 +		return false;
 +	else
 +		return _copy_from_iter_full(addr, bytes, i);
 +}
 +
 +static __always_inline __must_check
 +size_t copy_from_iter_nocache(void *addr, size_t bytes, struct iov_iter *i)
 +{
 +	if (unlikely(!check_copy_size(addr, bytes, false)))
 +		return bytes;
 +	else
 +		return _copy_from_iter_nocache(addr, bytes, i);
 +}
 +
 +static __always_inline __must_check
 +bool copy_from_iter_full_nocache(void *addr, size_t bytes, struct iov_iter *i)
 +{
 +	if (unlikely(!check_copy_size(addr, bytes, false)))
 +		return false;
 +	else
 +		return _copy_from_iter_full_nocache(addr, bytes, i);
 +}
 +
+ #ifdef CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE
+ /*
+  * Note, users like pmem that depend on the stricter semantics of
+  * copy_from_iter_flushcache() than copy_from_iter_nocache() must check for
+  * IS_ENABLED(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) before assuming that the
+  * destination is flushed from the cache on return.
+  */
+ size_t copy_from_iter_flushcache(void *addr, size_t bytes, struct iov_iter *i);
+ #else
+ static inline size_t copy_from_iter_flushcache(void *addr, size_t bytes,
+ 				       struct iov_iter *i)
+ {
+ 	return copy_from_iter_nocache(addr, bytes, i);
+ }
+ #endif
 -bool copy_from_iter_full_nocache(void *addr, size_t bytes, struct iov_iter *i);
++
  size_t iov_iter_zero(size_t bytes, struct iov_iter *);
  unsigned long iov_iter_alignment(const struct iov_iter *i);
  unsigned long iov_iter_gap_alignment(const struct iov_iter *i);
diff --cc lib/iov_iter.c
index d48f0976b8b4,c9a69064462f..000000000000
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@@ -639,9 -613,31 +639,31 @@@ size_t _copy_from_iter_nocache(void *ad
  
  	return bytes;
  }
 -EXPORT_SYMBOL(copy_from_iter_nocache);
 +EXPORT_SYMBOL(_copy_from_iter_nocache);
  
+ #ifdef CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE
+ size_t copy_from_iter_flushcache(void *addr, size_t bytes, struct iov_iter *i)
+ {
+ 	char *to = addr;
+ 	if (unlikely(i->type & ITER_PIPE)) {
+ 		WARN_ON(1);
+ 		return 0;
+ 	}
+ 	iterate_and_advance(i, bytes, v,
+ 		__copy_from_user_flushcache((to += v.iov_len) - v.iov_len,
+ 					 v.iov_base, v.iov_len),
+ 		memcpy_page_flushcache((to += v.bv_len) - v.bv_len, v.bv_page,
+ 				 v.bv_offset, v.bv_len),
+ 		memcpy_flushcache((to += v.iov_len) - v.iov_len, v.iov_base,
+ 			v.iov_len)
+ 	)
+ 
+ 	return bytes;
+ }
+ EXPORT_SYMBOL_GPL(copy_from_iter_flushcache);
+ #endif
+ 
 -bool copy_from_iter_full_nocache(void *addr, size_t bytes, struct iov_iter *i)
 +bool _copy_from_iter_full_nocache(void *addr, size_t bytes, struct iov_iter *i)
  {
  	char *to = addr;
  	if (unlikely(i->type & ITER_PIPE)) {

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-09-24 14:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-24  6:45 linux-next: manual merge of the nvdimm tree with the vfs tree Stephen Rothwell
2020-09-24 14:10 ` Dan Williams
2020-09-24 14:31   ` Dan Williams
  -- strict thread matches above, loose matches on Subject: below --
2020-09-24  6:38 Stephen Rothwell
2017-07-03  6:41 Stephen Rothwell

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