linux-stable.git/lib, branch v3.16.71

lib/div64.c: off by one in shift

2019-07-09T21:04:14+00:00

commit cdc94a37493135e355dfc0b0e086d84e3eadb50d upstream.

fls counts bits starting from 1 to 32 (returns 0 for zero argument).  If
we add 1 we shift right one bit more and loose precision from divisor,
what cause function incorect results with some numbers.

Corrected code was tested in user-space, see bugzilla:
   https://bugzilla.kernel.org/show_bug.cgi?id=202391

Link: http://lkml.kernel.org/r/1548686944-11891-1-git-send-email-sgruszka@redhat.com
Fixes: 658716d19f8f ("div64_u64(): improve precision on 32bit platforms")
Signed-off-by: Stanislaw Gruszka 
Reported-by: Siarhei Volkau 
Tested-by: Siarhei Volkau 
Acked-by: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

devres: always use dev_name() in devm_ioremap_resource()

2019-07-09T21:03:52+00:00

commit 8d84b18f5678d3adfdb9375dfb0d968da2dc753d upstream.

devm_ioremap_resource() prefers calling devm_request_mem_region() with a
resource name instead of a device name -- this looks pretty iff a resource
name isn't specified via a device tree with a "reg-names" property (in this
case, a resource name is set to a device node's full name), but if it is,
it doesn't really scale since these names are only unique to a given device
node, not globally; so, looking at the output of 'cat /proc/iomem', you do
not have an idea which memory region belongs to which device (see "dirmap",
"regs", and "wbuf" lines below):

08000000-0bffffff : dirmap
48000000-bfffffff : System RAM
  48000000-48007fff : reserved
  48080000-48b0ffff : Kernel code
  48b10000-48b8ffff : reserved
  48b90000-48c7afff : Kernel data
  bc6a4000-bcbfffff : reserved
  bcc0f000-bebfffff : reserved
  bec0e000-bec0efff : reserved
  bec11000-bec11fff : reserved
  bec12000-bec14fff : reserved
  bec15000-bfffffff : reserved
e6050000-e605004f : gpio@e6050000
e6051000-e605104f : gpio@e6051000
e6052000-e605204f : gpio@e6052000
e6053000-e605304f : gpio@e6053000
e6054000-e605404f : gpio@e6054000
e6055000-e605504f : gpio@e6055000
e6060000-e606050b : pin-controller@e6060000
e6e60000-e6e6003f : e6e60000.serial
e7400000-e7400fff : ethernet@e7400000
ee200000-ee2001ff : regs
ee208000-ee2080ff : wbuf

I think that devm_request_mem_region() should be called with dev_name()
despite the region names won't look as pretty as before (however, we gain
more consistency with e.g. the serial driver:

08000000-0bffffff : ee200000.rpc
48000000-bfffffff : System RAM
  48000000-48007fff : reserved
  48080000-48b0ffff : Kernel code
  48b10000-48b8ffff : reserved
  48b90000-48c7afff : Kernel data
  bc6a4000-bcbfffff : reserved
  bcc0f000-bebfffff : reserved
  bec0e000-bec0efff : reserved
  bec11000-bec11fff : reserved
  bec12000-bec14fff : reserved
  bec15000-bfffffff : reserved
e6050000-e605004f : e6050000.gpio
e6051000-e605104f : e6051000.gpio
e6052000-e605204f : e6052000.gpio
e6053000-e605304f : e6053000.gpio
e6054000-e605404f : e6054000.gpio
e6055000-e605504f : e6055000.gpio
e6060000-e606050b : e6060000.pin-controller
e6e60000-e6e6003f : e6e60000.serial
e7400000-e7400fff : e7400000.ethernet
ee200000-ee2001ff : ee200000.rpc
ee208000-ee2080ff : ee200000.rpc

Fixes: 72f8c0bfa0de ("lib: devres: add convenience function to remap a resource")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

x86/cpufeature: Carve out X86_FEATURE_*

2019-05-22T22:15:08+00:00

commit cd4d09ec6f6c12a2cc3db5b7d8876a325a53545b upstream.

Move them to a separate header and have the following
dependency:

  x86/cpufeatures.h <- x86/processor.h <- x86/cpufeature.h

This makes it easier to use the header in asm code and not
include the whole cpufeature.h and add guards for asm.

Suggested-by: H. Peter Anvin 
Signed-off-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1453842730-28463-5-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16 to avoid a dependency loop:
 - Drop some inapplicable changes
 - Move all the previously backported feature and bug flags across
 - Also change  and lib/retpoline.S to use
   
 - Also include  in , as the vdso fails to
   build without that
 - Adjust context]
Signed-off-by: Ben Hutchings

x86/headers: Don't include asm/processor.h in asm/atomic.h

2019-05-22T22:15:07+00:00

commit 153a4334c439cfb62e1d31cee0c790ba4157813d upstream.

asm/atomic.h doesn't really need asm/processor.h anymore. Everything
it uses has moved to other header files. So remove that include.

processor.h is a nasty header that includes lots of
other headers and makes it prone to include loops. Removing the
include here makes asm/atomic.h a "leaf" header that can
be safely included in most other headers.

The only fallout is in the lib/atomic tester which relied on
this implicit include. Give it an explicit include.
(the include is in ifdef because the user is also in ifdef)

Signed-off-by: Andi Kleen 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1449018060-1742-1-git-send-email-andi@firstfloor.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16 to avoid a dependency loop; adjusted context]
Signed-off-by: Ben Hutchings

assoc_array: Fix shortcut creation

2019-05-02T20:41:56+00:00

commit bb2ba2d75a2d673e76ddaf13a9bd30d6a8b1bb08 upstream.

Fix the creation of shortcuts for which the length of the index key value
is an exact multiple of the machine word size.  The problem is that the
code that blanks off the unused bits of the shortcut value malfunctions if
the number of bits in the last word equals machine word size.  This is due
to the "<<" operator being given a shift of zero in this case, and so the
mask that should be all zeros is all ones instead.  This causes the
subsequent masking operation to clear everything rather than clearing
nothing.

Ordinarily, the presence of the hash at the beginning of the tree index key
makes the issue very hard to test for, but in this case, it was encountered
due to a development mistake that caused the hash output to be either 0
(keyring) or 1 (non-keyring) only.  This made it susceptible to the
keyctl/unlink/valid test in the keyutils package.

The fix is simply to skip the blanking if the shift would be 0.  For
example, an index key that is 64 bits long would produce a 0 shift and thus
a 'blank' of all 1s.  This would then be inverted and AND'd onto the
index_key, incorrectly clearing the entire last word.

Fixes: 3cb989501c26 ("Add a generic associative array implementation.")
Signed-off-by: David Howells 
Signed-off-by: James Morris 
Signed-off-by: Ben Hutchings

lib/string.c: remove duplicated function

2019-04-04T15:13:44+00:00

commit cd514e727b18ff4d189b8e268db13729a4175091 upstream.

lib/string.c contains two functions, strnicmp and strncasecmp, which do
roughly the same thing, namely compare two strings case-insensitively up
to a given bound.  They have slightly different implementations, but the
only important difference is that strncasecmp doesn't handle len==0
appropriately; it effectively becomes strcasecmp in that case.  strnicmp
correctly says that two strings are always equal in their first 0
characters.

strncasecmp is the POSIX name for this functionality.  So rename the
non-broken function to the standard name.  To minimize the impact on the
rest of the kernel (and since both are exported to modules), make strnicmp
a wrapper for strncasecmp.

Signed-off-by: Rasmus Villemoes 
Cc: Grant Likely 
Cc: Andi Kleen 
Cc: Dan Carpenter 
Cc: "H. Peter Anvin" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

swiotlb: clean up reporting

2019-03-25T17:32:32+00:00

commit 7d63fb3af87aa67aa7d24466e792f9d7c57d8e79 upstream.

This removes needless use of '%p', and refactors the printk calls to
use pr_*() helpers instead.

Signed-off-by: Kees Cook 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Christoph Hellwig 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

percpu_counter: batch size aware __percpu_counter_compare()

2018-12-16T22:08:36+00:00

commit 80188b0d77d7426b494af739ac129e0e684acb84 upstream.

XFS uses non-stanard batch sizes for avoiding frequent global
counter updates on it's allocated inode counters, as they increment
or decrement in batches of 64 inodes. Hence the standard percpu
counter batch of 32 means that the counter is effectively a global
counter. Currently Xfs uses a batch size of 128 so that it doesn't
take the global lock on every single modification.

However, Xfs also needs to compare accurately against zero, which
means we need to use percpu_counter_compare(), and that has a
hard-coded batch size of 32, and hence will spuriously fail to
detect when it is supposed to use precise comparisons and hence
the accounting goes wrong.

Add __percpu_counter_compare() to take a custom batch size so we can
use it sanely in XFS and factor percpu_counter_compare() to use it.

Signed-off-by: Dave Chinner 
Acked-by: Tejun Heo 
Signed-off-by: Dave Chinner 
Signed-off-by: Ben Hutchings

string: provide strscpy()

2018-10-21T07:46:12+00:00

commit 30035e45753b708e7d47a98398500ca005e02b86 upstream.

The strscpy() API is intended to be used instead of strlcpy(),
and instead of most uses of strncpy().

- Unlike strlcpy(), it doesn't read from memory beyond (src + size).

- Unlike strlcpy() or strncpy(), the API provides an easy way to check
  for destination buffer overflow: an -E2BIG error return value.

- The provided implementation is robust in the face of the source
  buffer being asynchronously changed during the copy, unlike the
  current implementation of strlcpy().

- Unlike strncpy(), the destination buffer will be NUL-terminated
  if the string in the source buffer is too long.

- Also unlike strncpy(), the destination buffer will not be updated
  beyond the NUL termination, avoiding strncpy's behavior of zeroing
  the entire tail end of the destination buffer.  (A memset() after
  the strscpy() can be used if this behavior is desired.)

- The implementation should be reasonably performant on all
  platforms since it uses the asm/word-at-a-time.h API rather than
  simple byte copy.  Kernel-to-kernel string copy is not considered
  to be performance critical in any case.

Signed-off-by: Chris Metcalf 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

509: fix printing uninitialized stack memory when OID is empty

2018-03-03T15:51:49+00:00

commit 8dfd2f22d3bf3ab7714f7495ad5d897b8845e8c1 upstream.

Callers of sprint_oid() do not check its return value before printing
the result.  In the case where the OID is zero-length, -EBADMSG was
being returned without anything being written to the buffer, resulting
in uninitialized stack memory being printed.  Fix this by writing
"(bad)" to the buffer in the cases where -EBADMSG is returned.

Fixes: 4f73175d0375 ("X.509: Add utility functions to render OIDs as strings")
Signed-off-by: Eric Biggers 
Signed-off-by: David Howells 
Signed-off-by: Ben Hutchings