linux-stable.git/kernel/gcov, branch v5.4.166

gcov: re-fix clang-11+ support

2021-04-14T06:24:10+00:00

commit 9562fd132985ea9185388a112e50f2a51557827d upstream.

LLVM changed the expected function signature for llvm_gcda_emit_function()
in the clang-11 release.  Users of clang-11 or newer may have noticed
their kernels producing invalid coverage information:

  $ llvm-cov gcov -a -c -u -f -b .gcda -- gcno=.gcno
  1 : checksum mismatch, \
    (, ) != (, )
  2 Invalid .gcda File!
  ...

Fix up the function signatures so calling this function interprets its
parameters correctly and computes the correct cfg checksum.  In
particular, in clang-11, the additional checksum is no longer optional.

Link: https://reviews.llvm.org/rG25544ce2df0daa4304c07e64b9c8b0f7df60c11d
Link: https://lkml.kernel.org/r/20210408184631.1156669-1-ndesaulniers@google.com
Reported-by: Prasad Sodagudi 
Tested-by: Prasad Sodagudi 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Nathan Chancellor 
Cc: 	[5.4+]
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

gcov: fix clang-11+ support

2021-03-30T12:35:23+00:00

commit 60bcf728ee7c60ac2a1f9a0eaceb3a7b3954cd2b upstream.

LLVM changed the expected function signatures for llvm_gcda_start_file()
and llvm_gcda_emit_function() in the clang-11 release.  Users of
clang-11 or newer may have noticed their kernels failing to boot due to
a panic when enabling CONFIG_GCOV_KERNEL=y +CONFIG_GCOV_PROFILE_ALL=y.
Fix up the function signatures so calling these functions doesn't panic
the kernel.

Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
Link: https://lkml.kernel.org/r/20210312224132.3413602-2-ndesaulniers@google.com
Signed-off-by: Nick Desaulniers 
Reported-by: Prasad Sodagudi 
Suggested-by: Nathan Chancellor 
Reviewed-by: Fangrui Song 
Tested-by: Nathan Chancellor 
Acked-by: Peter Oberparleiter 
Reviewed-by: Nathan Chancellor 
Cc: 	[5.4+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

gcov: add support for GCC 10.1

2020-09-17T11:47:56+00:00

[ Upstream commit 40249c6962075c040fd071339acae524f18bfac9 ]

Using gcov to collect coverage data for kernels compiled with GCC 10.1
causes random malfunctions and kernel crashes.  This is the result of a
changed GCOV_COUNTERS value in GCC 10.1 that causes a mismatch between
the layout of the gcov_info structure created by GCC profiling code and
the related structure used by the kernel.

Fix this by updating the in-kernel GCOV_COUNTERS value.  Also re-enable
config GCOV_KERNEL for use with GCC 10.

Reported-by: Colin Ian King 
Reported-by: Leon Romanovsky 
Signed-off-by: Peter Oberparleiter 
Tested-by: Leon Romanovsky 
Tested-and-Acked-by: Colin Ian King 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

gcov: Disable gcov build with GCC 10

2020-09-17T11:47:49+00:00

[ Upstream commit cfc905f158eaa099d6258031614d11869e7ef71c ]

GCOV built with GCC 10 doesn't initialize n_function variable.  This
produces different kernel panics as was seen by Colin in Ubuntu and me
in FC 32.

As a workaround, let's disable GCOV build for broken GCC 10 version.

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891288
Link: https://lore.kernel.org/lkml/20200827133932.3338519-1-leon@kernel.org
Link: https://lore.kernel.org/lkml/CAHk-=whbijeSdSvx-Xcr0DPMj0BiwhJ+uiNnDSVZcr_h_kg7UA@mail.gmail.com/
Cc: Colin Ian King 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

kernel/gcov/fs.c: gcov_seq_next() should increase position index

2020-04-29T14:33:00+00:00

[ Upstream commit f4d74ef6220c1eda0875da30457bef5c7111ab06 ]

If seq_file .next function does not change position index, read after
some lseek can generate unexpected output.

https://bugzilla.kernel.org/show_bug.cgi?id=206283
Signed-off-by: Vasily Averin 
Signed-off-by: Andrew Morton 
Acked-by: Peter Oberparleiter 
Cc: Al Viro 
Cc: Davidlohr Bueso 
Cc: Ingo Molnar 
Cc: Manfred Spraul 
Cc: NeilBrown 
Cc: Steven Rostedt 
Cc: Waiman Long 
Link: http://lkml.kernel.org/r/f65c6ee7-bd00-f910-2f8a-37cc67e4ff88@virtuozzo.com
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

Revert "um: Enable CONFIG_CONSTRUCTORS"

2020-02-01T09:34:53+00:00

commit 87c9366e17259040a9118e06b6dc8de986e5d3d1 upstream.

This reverts commit 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS").

There are two issues with this commit, uncovered by Anton in tests
on some (Debian) systems:

1) I completely forgot to call any constructors if CONFIG_CONSTRUCTORS
   isn't set. Don't recall now if it just wasn't needed on my system, or
   if I never tested this case.

2) With that fixed, it works - with CONFIG_CONSTRUCTORS *unset*. If I
   set CONFIG_CONSTRUCTORS, it fails again, which isn't totally
   unexpected since whatever wanted to run is likely to have to run
   before the kernel init etc. that calls the constructors in this case.

Basically, some constructors that gcc emits (libc has?) need to run
very early during init; the failure mode otherwise was that the ptrace
fork test already failed:

----------------------
$ ./linux mem=512M
Core dump limits :
	soft - 0
	hard - NONE
Checking that ptrace can change system call numbers...check_ptrace : child exited with exitcode 6, while expecting 0; status 0x67f
Aborted
----------------------

Thinking more about this, it's clear that we simply cannot support
CONFIG_CONSTRUCTORS in UML. All the cases we need now (gcov, kasan)
involve not use of the __attribute__((constructor)), but instead
some constructor code/entry generated by gcc. Therefore, we cannot
distinguish between kernel constructors and system constructors.

Thus, revert this commit.

Cc: stable@vger.kernel.org [5.4+]
Fixes: 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS")
Reported-by: Anton Ivanov 
Signed-off-by: Johannes Berg 
Acked-by: Anton Ivanov 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Richard Weinberger

um: Enable CONFIG_CONSTRUCTORS

2019-09-15T19:37:13+00:00

We do need to call the constructors for *modules*, and
at least for KASAN in the future, we must call even the
kernel constructors only later when the kernel has been
initialized.

Instead of relying on libc to call them, emit an empty
section for libc and let the kernel's CONSTRUCTORS code
do the rest of the job.

Tested that it indeed doesn't work in modules, and does
work after the fixes in both, with a few functions with
__attribute__((constructor)) in both dynamic and static
builds.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

gcov: no need to check return value of debugfs_create functions

2019-06-03T14:18:12+00:00

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Also delete the dentry variable as it is never needed.

Acked-by: Peter Oberparleiter 
Signed-off-by: Greg Kroah-Hartman

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46+00:00

Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

gcov: clang support

2019-05-15T02:52:51+00:00

LLVM uses profiling data that's deliberately similar to GCC, but has a
very different way of exporting that data.  LLVM calls llvm_gcov_init()
once per module, and provides a couple of callbacks that we can use to
ask for more data.

We care about the "writeout" callback, which in turn calls back into
compiler-rt/this module to dump all the gathered coverage data to disk:

   llvm_gcda_start_file()
     llvm_gcda_emit_function()
     llvm_gcda_emit_arcs()
     llvm_gcda_emit_function()
     llvm_gcda_emit_arcs()
     [... repeats for each function ...]
   llvm_gcda_summary_info()
   llvm_gcda_end_file()

This design is much more stateless and unstructured than gcc's, and is
intended to run at process exit.  This forces us to keep some local
state about which module we're dealing with at the moment.  On the other
hand, it also means we don't depend as much on how LLVM represents
profiling data internally.

See LLVM's lib/Transforms/Instrumentation/GCOVProfiling.cpp for more
details on how this works, particularly GCOVProfiler::emitProfileArcs(),
GCOVProfiler::insertCounterWriteout(), and GCOVProfiler::insertFlush().

[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20190417225328.208129-1-trong@android.com
Signed-off-by: Greg Hackmann 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Tri Vo 
Co-developed-by: Nick Desaulniers 
Co-developed-by: Tri Vo 
Tested-by: Trilok Soni 
Tested-by: Prasad Sodagudi 
Tested-by: Tri Vo 
Tested-by: Daniel Mentz 
Tested-by: Petri Gynther 
Reviewed-by: Peter Oberparleiter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds