linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell <sfr@canb.auug.org.au>]

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

Hi all,

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

  Documentation/process/deprecated.rst

between commit:

  d8401f504b49 ("docs: deprecated.rst: Add %p to the list")
  76136e028d3b ("docs: deprecated.rst: Clean up fall-through details")
  7929b9836ed0 ("docs: Remove :c:func: from process/deprecated.rst")

from the jc_docs tree and commit:

  eacc9a8c9c2d ("Documentation/checkpatch: prefer stracpy/strscpy over strcpy/strlcpy/strncpy.")

from the akpm-current 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 Documentation/process/deprecated.rst
index e924d3197761,a0ffdc8daef3..000000000000
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@@ -93,44 -93,22 +93,44 @@@ will be NUL terminated. This can lead t
  and other misbehavior due to the missing termination. It also NUL-pads the
  destination buffer if the source contents are shorter than the destination
  buffer size, which may be a needless performance penalty for callers using
- only NUL-terminated strings. The safe replacement is strscpy().
- (Users of strscpy() still needing NUL-padding should instead
- use strscpy_pad().)
+ only NUL-terminated strings. In this case, the safe replacement is
+ stracpy() or strscpy(). If, however, the destination buffer still needs
+ NUL-padding, the safe replacement is stracpy_pad().
  
 -If a caller is using non-NUL-terminated strings, :c:func:`strncpy()` can
 +If a caller is using non-NUL-terminated strings, strncpy()() can
  still be used, but destinations should be marked with the `__nonstring
  <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
  attribute to avoid future compiler warnings.
  
  strlcpy()
  ---------
 -:c:func:`strlcpy` reads the entire source buffer first, possibly exceeding
 +strlcpy() reads the entire source buffer first, possibly exceeding
  the given limit of bytes to copy. This is inefficient and can lead to
  linear read overflows if a source string is not NUL-terminated. The
- safe replacement is strscpy().
+ safe replacement is stracpy() or strscpy().
  
 +%p format specifier
 +-------------------
 +Traditionally, using "%p" in format strings would lead to regular address
 +exposure flaws in dmesg, proc, sysfs, etc. Instead of leaving these to
 +be exploitable, all "%p" uses in the kernel are being printed as a hashed
 +value, rendering them unusable for addressing. New uses of "%p" should not
 +be added to the kernel. For text addresses, using "%pS" is likely better,
 +as it produces the more useful symbol name instead. For nearly everything
 +else, just do not add "%p" at all.
 +
 +Paraphrasing Linus's current `guidance <https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/>`_:
 +
 +- If the hashed "%p" value is pointless, ask yourself whether the pointer
 +  itself is important. Maybe it should be removed entirely?
 +- If you really think the true pointer value is important, why is some
 +  system state or user privilege level considered "special"? If you think
 +  you can justify it (in comments and commit log) well enough to stand
 +  up to Linus's scrutiny, maybe you can use "%px", along with making sure
 +  you have sensible permissions.
 +
 +And finally, know that a toggle for "%p" hashing will `not be accepted <https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@mail.gmail.com/>`_.
 +
  Variable Length Arrays (VLAs)
  -----------------------------
  Using stack VLAs produces much worse machine code than statically

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