linux-toradex.git/lib/string.c, branch v5.12-rc6

lib/string: remove unnecessary #undefs

2020-12-16T06:46:16+00:00

A few architecture specific string.h functions used to be implemented in
terms of preprocessor defines to the corresponding compiler builtins.
Since this is no longer the case, remove unused #undefs.

Only memcmp is still defined in terms of builtins for a few arches.

Link: https://github.com/ClangBuiltLinux/linux/issues/428
Link: https://lkml.kernel.org/r/20201120041113.89382-1-ndesaulniers@google.com
Fixes: 5f074f3e192f ("lib/string.c: implement a basic bcmp")
Signed-off-by: Nick Desaulniers 
Cc: Andy Shevchenko 
Cc: Yury Norov 
Cc: Alexandru Ardelean 
Cc: Nathan Chancellor 
Cc: Masahiro Yamada 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string.c: implement stpcpy

2020-09-26T17:33:57+00:00

LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`.

This generally avoids the machinery involved in parsing format strings.
`stpcpy` is just like `strcpy` except it returns the pointer to the new
tail of `dest`.  This optimization was introduced into clang-12.

Implement this so that we don't observe linkage failures due to missing
symbol definitions for `stpcpy`.

Similar to last year's fire drill with: commit 5f074f3e192f
("lib/string.c: implement a basic bcmp")

The kernel is somewhere between a "freestanding" environment (no full
libc) and "hosted" environment (many symbols from libc exist with the
same type, function signature, and semantics).

As Peter Anvin notes, there's not really a great way to inform the
compiler that you're targeting a freestanding environment but would like
to opt-in to some libcall optimizations (see pr/47280 below), rather
than opt-out.

Arvind notes, -fno-builtin-* behaves slightly differently between GCC
and Clang, and Clang is missing many __builtin_* definitions, which I
consider a bug in Clang and am working on fixing.

Masahiro summarizes the subtle distinction between compilers justly:
  To prevent transformation from foo() into bar(), there are two ways in
  Clang to do that; -fno-builtin-foo, and -fno-builtin-bar.  There is
  only one in GCC; -fno-buitin-foo.

(Any difference in that behavior in Clang is likely a bug from a missing
__builtin_* definition.)

Masahiro also notes:
  We want to disable optimization from foo() to bar(),
  but we may still benefit from the optimization from
  foo() into something else. If GCC implements the same transform, we
  would run into a problem because it is not -fno-builtin-bar, but
  -fno-builtin-foo that disables that optimization.

  In this regard, -fno-builtin-foo would be more future-proof than
  -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
  may want to prevent calls from foo() being optimized into calls to
  bar(), but we still may want other optimization on calls to foo().

It seems that compilers today don't quite provide the fine grain control
over which libcall optimizations pseudo-freestanding environments would
prefer.

Finally, Kees notes that this interface is unsafe, so we should not
encourage its use.  As such, I've removed the declaration from any
header, but it still needs to be exported to avoid linkage errors in
modules.

Reported-by: Sami Tolvanen 
Suggested-by: Andy Lavr 
Suggested-by: Arvind Sankar 
Suggested-by: Joe Perches 
Suggested-by: Kees Cook 
Suggested-by: Masahiro Yamada 
Suggested-by: Rasmus Villemoes 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Andrew Morton 
Tested-by: Nathan Chancellor 
Cc: 
Link: https://lkml.kernel.org/r/20200914161643.938408-1-ndesaulniers@google.com
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://bugs.llvm.org/show_bug.cgi?id=47280
Link: https://github.com/ClangBuiltLinux/linux/issues/1126
Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
Link: https://reviews.llvm.org/D85963
Signed-off-by: Linus Torvalds

lib/string.c: update match_string() doc-strings with correct behavior

2020-02-21T19:22:15+00:00

There were a few attempts at changing behavior of the match_string()
helpers (i.e.  'match_string()' & 'sysfs_match_string()'), to change &
extend the behavior according to the doc-string.

But the simplest approach is to just fix the doc-strings.  The current
behavior is fine as-is, and some bugs were introduced trying to fix it.

As for extending the behavior, new helpers can always be introduced if
needed.

The match_string() helpers behave more like 'strncmp()' in the sense
that they go up to n elements or until the first NULL element in the
array of strings.

This change updates the doc-strings with this info.

Link: http://lkml.kernel.org/r/20200213072722.8249-1-alexandru.ardelean@analog.com
Signed-off-by: Alexandru Ardelean 
Acked-by: Andy Shevchenko 
Cc: Kees Cook 
Cc: "Tobin C . Harding" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string: add strnchrnul()

2020-02-04T03:05:26+00:00

Patch series "lib: rework bitmap_parse", v5.

Similarl to the recently revisited bitmap_parselist(), bitmap_parse() is
ineffective and overcomplicated.  This series reworks it, aligns its
interface with bitmap_parselist() and makes it simpler to use.

The series also adds a test for the function and fixes usage of it in
cpumask_parse() according to the new design - drops the calculating of
length of an input string.

bitmap_parse() takes the array of numbers to be put into the map in the BE
order which is reversed to the natural LE order for bitmaps.  For example,
to construct bitmap containing a bit on the position 42, we have to put a
line '400,0'.  Current implementation reads chunk one by one from the
beginning ('400' before '0') and makes bitmap shift after each successful
parse.  It makes the complexity of the whole process as O(n^2).  We can do
it in reverse direction ('0' before '400') and avoid shifting, but it
requires reverse parsing helpers.

This patch (of 7):

New function works like strchrnul() with a length limited string.

Link: http://lkml.kernel.org/r/20200102043031.30357-2-yury.norov@gmail.com
Signed-off-by: Yury Norov 
Reviewed-by: Andy Shevchenko 
Cc: Rasmus Villemoes 
Cc: Amritha Nambiar 
Cc: Willem de Bruijn 
Cc: Kees Cook 
Cc: Matthew Wilcox 
Cc: "Tobin C . Harding" 
Cc: Will Deacon 
Cc: Miklos Szeredi 
Cc: Vineet Gupta 
Cc: Chris Wilson 
Cc: Arnaldo Carvalho de Melo 
Cc: Steffen Klassert 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string: Make memzero_explicit() inline instead of external

2019-10-08T11:27:05+00:00

With the use of the barrier implied by barrier_data(), there is no need
for memzero_explicit() to be extern. Making it inline saves the overhead
of a function call, and allows the code to be reused in arch/*/purgatory
without having to duplicate the implementation.

Tested-by: Hans de Goede 
Signed-off-by: Arvind Sankar 
Reviewed-by: Hans de Goede 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: H . Peter Anvin 
Cc: Herbert Xu 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephan Mueller 
Cc: Thomas Gleixner 
Cc: linux-crypto@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
Link: https://lkml.kernel.org/r/20191007220000.GA408752@rani.riverdale.lan
Signed-off-by: Ingo Molnar

strscpy: reject buffer sizes larger than INT_MAX

2019-09-26T00:51:39+00:00

As already done for snprintf(), add a check in strscpy() for giant (i.e.
likely negative and/or miscalculated) copy sizes, WARN, and error out.

Link: http://lkml.kernel.org/r/201907260928.23DE35406@keescook
Signed-off-by: Kees Cook 
Cc: Joe Perches 
Cc: Rasmus Villemoes 
Cc: Yann Droneaud 
Cc: David Laight 
Cc: Jonathan Corbet 
Cc: Stephen Kitt 
Cc: Jann Horn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel-doc: core-api: include string.h into core-api

2019-09-26T00:51:39+00:00

core-api should show all the various string functions including the newly
added stracpy and stracpy_pad.

Miscellanea:

o Update the Returns: value for strscpy
o fix a defect with %NUL)

[joe@perches.com: correct return of -E2BIG descriptions]
  Link: http://lkml.kernel.org/r/29f998b4c1a9d69fbeae70500ba0daa4b340c546.1563889130.git.joe@perches.com
Link: http://lkml.kernel.org/r/224a6ebf39955f4107c0c376d66155d970e46733.1563841972.git.joe@perches.com
Signed-off-by: Joe Perches 
Reviewed-by: Kees Cook 
Cc: Jonathan Corbet 
Cc: Stephen Kitt 
Cc: Nitin Gote 
Cc: Rasmus Villemoes 
Cc: Jann Horn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string.c: allow searching for NUL with strnchr

2019-07-17T02:23:22+00:00

Patch series "lib/string: search for NUL with strchr/strnchr".

I noticed an inconsistency where strchr and strnchr do not behave the
same with respect to the trailing NUL.  strchr is standardised and the
kernel function conforms, and the kernel relies on the behavior.  So,
naturally strchr stays as-is and strnchr is what I change.

While writing a few tests to verify that my new strnchr loop was sane, I
noticed that the tests for memset16/32/64 had a problem.  Since it's all
about the lib/string.c file I made a short series of it all...

This patch (of 3):

strchr considers the terminating NUL to be part of the string, and NUL
can thus be searched for with that function.  For consistency, do the
same with strnchr.

Link: http://lkml.kernel.org/r/20190506124634.6807-2-peda@axentia.se
Signed-off-by: Peter Rosin 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string: Add strscpy_pad() function

2019-04-08T22:44:21+00:00

We have a function to copy strings safely and we have a function to copy
strings and zero the tail of the destination (if source string is
shorter than destination buffer) but we do not have a function to do
both at once.  This means developers must write this themselves if they
desire this functionality.  This is a chore, and also leaves us open to
off by one errors unnecessarily.

Add a function that calls strscpy() then memset()s the tail to zero if
the source string is shorter than the destination buffer.

Acked-by: Kees Cook 
Signed-off-by: Tobin C. Harding 
Signed-off-by: Shuah Khan

lib/string.c: implement a basic bcmp

2019-04-06T02:02:30+00:00

A recent optimization in Clang (r355672) lowers comparisons of the
return value of memcmp against zero to comparisons of the return value
of bcmp against zero.  This helps some platforms that implement bcmp
more efficiently than memcmp.  glibc simply aliases bcmp to memcmp, but
an optimized implementation is in the works.

This results in linkage failures for all targets with Clang due to the
undefined symbol.  For now, just implement bcmp as a tailcail to memcmp
to unbreak the build.  This routine can be further optimized in the
future.

Other ideas discussed:

 * A weak alias was discussed, but breaks for architectures that define
   their own implementations of memcmp since aliases to declarations are
   not permitted (only definitions). Arch-specific memcmp
   implementations typically declare memcmp in C headers, but implement
   them in assembly.

 * -ffreestanding also is used sporadically throughout the kernel.

 * -fno-builtin-bcmp doesn't work when doing LTO.

Link: https://bugs.llvm.org/show_bug.cgi?id=41035
Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
Link: https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
Link: https://github.com/ClangBuiltLinux/linux/issues/416
Link: http://lkml.kernel.org/r/20190313211335.165605-1-ndesaulniers@google.com
Signed-off-by: Nick Desaulniers 
Reported-by: Nathan Chancellor 
Reported-by: Adhemerval Zanella 
Suggested-by: Arnd Bergmann 
Suggested-by: James Y Knight 
Suggested-by: Masahiro Yamada 
Suggested-by: Nathan Chancellor 
Suggested-by: Rasmus Villemoes 
Acked-by: Steven Rostedt (VMware) 
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor 
Reviewed-by: Masahiro Yamada 
Reviewed-by: Andy Shevchenko 
Cc: David Laight 
Cc: Rasmus Villemoes 
Cc: Namhyung Kim 
Cc: Greg Kroah-Hartman 
Cc: Alexander Shishkin 
Cc: Dan Williams 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds