linux-stable.git/scripts, branch linux-5.3.y Linux kernel stable tree scripts/gdb: fix debugging modules compiled with hot/cold partitioning 2019-12-04T21:33:49+00:00 Ilya Leoshkevich iii@linux.ibm.com 2019-11-06T05:17:06+00:00 ee3b7b35cb0dbb0683730ce86a84d6636f853ca4 [ Upstream commit 8731acc5068eb3f422a45c760d32198175c756f8 ] gcc's -freorder-blocks-and-partition option makes it group frequently and infrequently used code in .text.hot and .text.unlikely sections respectively. At least when building modules on s390, this option is used by default. gdb assumes that all code is located in .text section, and that .text section is located at module load address. With such modules this is no longer the case: there is code in .text.hot and .text.unlikely, and either of them might precede .text. Fix by explicitly telling gdb the addresses of code sections. It might be tempting to do this for all sections, not only the ones in the white list. Unfortunately, gdb appears to have an issue, when telling it about e.g. loadable .note.gnu.build-id section causes it to think that non-loadable .note.Linux section is loaded at address 0, which in turn causes NULL pointers to be resolved to bogus symbols. So keep using the white list approach for the time being. Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8731acc5068eb3f422a45c760d32198175c756f8 ]

gcc's -freorder-blocks-and-partition option makes it group frequently
and infrequently used code in .text.hot and .text.unlikely sections
respectively.  At least when building modules on s390, this option is
used by default.

gdb assumes that all code is located in .text section, and that .text
section is located at module load address.  With such modules this is no
longer the case: there is code in .text.hot and .text.unlikely, and
either of them might precede .text.

Fix by explicitly telling gdb the addresses of code sections.

It might be tempting to do this for all sections, not only the ones in
the white list.  Unfortunately, gdb appears to have an issue, when
telling it about e.g. loadable .note.gnu.build-id section causes it to
think that non-loadable .note.Linux section is loaded at address 0,
which in turn causes NULL pointers to be resolved to bogus symbols.  So
keep using the white list approach for the time being.

Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.com
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
namespace: fix namespace.pl script to support relative paths 2019-10-29T08:21:46+00:00 Jacob Keller jacob.e.keller@intel.com 2019-09-27T23:30:27+00:00 88d2c8c76d01d65010d8a4068caad3d733dd6635 [ Upstream commit 82fdd12b95727640c9a8233c09d602e4518e71f7 ] The namespace.pl script does not work properly if objtree is not set to an absolute path. The do_nm function is run from within the find function, which changes directories. Because of this, appending objtree, $File::Find::dir, and $source, will return a path which is not valid from the current directory. This used to work when objtree was set to an absolute path when using "make namespacecheck". It appears to have not worked when calling ./scripts/namespace.pl directly. This behavior was changed in 7e1c04779efd ("kbuild: Use relative path for $(objtree)", 2014-05-14) Rather than fixing the Makefile to set objtree to an absolute path, just fix namespace.pl to work when srctree and objtree are relative. Also fix the script to use an absolute path for these by default. Use the File::Spec module for this purpose. It's been part of perl 5 since 5.005. The curdir() function is used to get the current directory when the objtree and srctree aren't set in the environment. rel2abs() is used to convert possibly relative objtree and srctree environment variables to absolute paths. Finally, the catfile() function is used instead of string appending paths together, since this is more robust when joining paths together. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 82fdd12b95727640c9a8233c09d602e4518e71f7 ]

The namespace.pl script does not work properly if objtree is not set to
an absolute path. The do_nm function is run from within the find
function, which changes directories.

Because of this, appending objtree, $File::Find::dir, and $source, will
return a path which is not valid from the current directory.

This used to work when objtree was set to an absolute path when using
"make namespacecheck". It appears to have not worked when calling
./scripts/namespace.pl directly.

This behavior was changed in 7e1c04779efd ("kbuild: Use relative path
for $(objtree)", 2014-05-14)

Rather than fixing the Makefile to set objtree to an absolute path, just
fix namespace.pl to work when srctree and objtree are relative. Also fix
the script to use an absolute path for these by default.

Use the File::Spec module for this purpose. It's been part of perl
5 since 5.005.

The curdir() function is used to get the current directory when the
objtree and srctree aren't set in the environment.

rel2abs() is used to convert possibly relative objtree and srctree
environment variables to absolute paths.

Finally, the catfile() function is used instead of string appending
paths together, since this is more robust when joining paths together.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
randstruct: Check member structs in is_pure_ops_struct() 2019-10-05T13:12:15+00:00 Joonwon Kang kjw1627@gmail.com 2019-07-27T15:58:41+00:00 cb526d1c5326fa0683d5ef1ea4db5ae12377fcab commit 60f2c82ed20bde57c362e66f796cf9e0e38a6dbb upstream. While no uses in the kernel triggered this case, it was possible to have a false negative where a struct contains other structs which contain only function pointers because of unreachable code in is_pure_ops_struct(). Signed-off-by: Joonwon Kang <kjw1627@gmail.com> Link: https://lore.kernel.org/r/20190727155841.GA13586@host Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 60f2c82ed20bde57c362e66f796cf9e0e38a6dbb upstream.

While no uses in the kernel triggered this case, it was possible to have
a false negative where a struct contains other structs which contain only
function pointers because of unreachable code in is_pure_ops_struct().

Signed-off-by: Joonwon Kang <kjw1627@gmail.com>
Link: https://lore.kernel.org/r/20190727155841.GA13586@host
Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE 2019-10-05T13:11:43+00:00 Mark Rutland mark.rutland@arm.com 2019-08-14T14:31:57+00:00 c44f658d1731f0ebb48397cda27a36291959833c [ Upstream commit 34b5560db40d2941cfbe82eca1641353d5aed1a9 ] The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC. Since commit: 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET") ... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time splats due to KASAN_SHADOW_OFFSET not being set: | [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang | scripts/kconfig/conf --syncconfig Kconfig | CC scripts/mod/empty.o | clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument! | scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed | make[1]: *** [scripts/mod/empty.o] Error 1 | Makefile:1123: recipe for target 'prepare0' failed | make: *** [prepare0] Error 2 Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing common definition of +CFLAGS_KASAN_NOSANITIZE to the top of Makefile.kasan. Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Tested-by Steve Capper <steve.capper@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 34b5560db40d2941cfbe82eca1641353d5aed1a9 ]

The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC.

Since commit:

  6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")

... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than
defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if
CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time
splats due to KASAN_SHADOW_OFFSET not being set:

| [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0  make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
| scripts/kconfig/conf  --syncconfig Kconfig
|   CC      scripts/mod/empty.o
| clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
| scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
| make[1]: *** [scripts/mod/empty.o] Error 1
| Makefile:1123: recipe for target 'prepare0' failed
| make: *** [prepare0] Error 2

Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing
common definition of +CFLAGS_KASAN_NOSANITIZE to the top of
Makefile.kasan.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Tested-by Steve Capper <steve.capper@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'spdx-5.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx 2019-08-18T16:26:16+00:00 Linus Torvalds torvalds@linux-foundation.org 2019-08-18T16:26:16+00:00 5bba5c9c86b31895f5cb67f2db2b0f0cddc96dc6 Pull SPDX fixes from Greg KH: "Here are four small SPDX fixes for 5.3-rc5. A few style fixes for some SPDX comments, added an SPDX tag for one file, and fix up some GPL boilerplate for another file. All of these have been in linux-next for a few weeks with no reported issues (they are comment changes only, so that's to be expected...)" * tag 'spdx-5.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx: i2c: stm32: Use the correct style for SPDX License Identifier intel_th: Use the correct style for SPDX License Identifier coccinelle: api/atomic_as_refcounter: add SPDX License Identifier kernel/configs: Replace GPL boilerplate code with SPDX identifier 
Pull SPDX fixes from Greg KH:
 "Here are four small SPDX fixes for 5.3-rc5.

  A few style fixes for some SPDX comments, added an SPDX tag for one
  file, and fix up some GPL boilerplate for another file.

  All of these have been in linux-next for a few weeks with no reported
  issues (they are comment changes only, so that's to be expected...)"

* tag 'spdx-5.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx:
  i2c: stm32: Use the correct style for SPDX License Identifier
  intel_th: Use the correct style for SPDX License Identifier
  coccinelle: api/atomic_as_refcounter: add SPDX License Identifier
  kernel/configs: Replace GPL boilerplate code with SPDX identifier
kbuild: show hint if subdir-y/m is used to visit module Makefile 2019-08-09T16:45:31+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2019-08-08T11:21:11+00:00 c07d8d47bca1b325102fa2be3a463075f7b051d9 Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), a module is no longer built in the following pattern: [Makefile] subdir-y := some-module [some-module/Makefile] obj-m := some-module.o You cannot write Makefile this way in upstream because modules.order is not correctly generated. subdir-y is used to descend to a sub-directory that builds tools, device trees, etc. For external modules, the modules order does not matter. So, the Makefile above was known to work. I believe the Makefile should be re-written as follows: [Makefile] obj-m := some-module/ [some-module/Makefile] obj-m := some-module.o However, people will have no idea if their Makefile suddenly stops working. In fact, I received questions from multiple people. Show a warning for a while if obj-m is specified in a Makefile visited by subdir-y or subdir-m. I touched the %/ rule to avoid false-positive warnings for the single target. Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Tom Stonecypher <thomas.edwardx.stonecypher@intel.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> 
Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead
of $(MODVERDIR)/*.mod"), a module is no longer built in the following
pattern:

  [Makefile]
  subdir-y := some-module

  [some-module/Makefile]
  obj-m := some-module.o

You cannot write Makefile this way in upstream because modules.order is
not correctly generated. subdir-y is used to descend to a sub-directory
that builds tools, device trees, etc.

For external modules, the modules order does not matter. So, the
Makefile above was known to work.

I believe the Makefile should be re-written as follows:

  [Makefile]
  obj-m := some-module/

  [some-module/Makefile]
  obj-m := some-module.o

However, people will have no idea if their Makefile suddenly stops
working. In fact, I received questions from multiple people.

Show a warning for a while if obj-m is specified in a Makefile visited
by subdir-y or subdir-m.

I touched the %/ rule to avoid false-positive warnings for the single
target.

Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Tom Stonecypher <thomas.edwardx.stonecypher@intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
kbuild: generate modules.order only in directories visited by obj-y/m 2019-08-09T16:45:31+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2019-08-06T10:03:22+00:00 4f2c8f3089f538f556c86f26603a062865e4aa94 The modules.order files in directories visited by the chain of obj-y or obj-m are merged to the upper-level ones, and become parts of the top-level modules.order. On the other hand, there is no need to generate modules.order in directories visited by subdir-y or subdir-m since they would become orphan anyway. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 
The modules.order files in directories visited by the chain of obj-y
or obj-m are merged to the upper-level ones, and become parts of the
top-level modules.order. On the other hand, there is no need to
generate modules.order in directories visited by subdir-y or subdir-m
since they would become orphan anyway.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
kbuild: fix false-positive need-builtin calculation 2019-08-09T16:45:31+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2019-08-06T10:03:21+00:00 d9f78edfd81b9e484423534360350ef7253cc888 The current implementation of need-builtin is false-positive, for example, in the following Makefile: obj-m := foo/ obj-y := foo/bar/ ..., where foo/built-in.a is not required. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 
The current implementation of need-builtin is false-positive,
for example, in the following Makefile:

  obj-m := foo/
  obj-y := foo/bar/

..., where foo/built-in.a is not required.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
kbuild: revive single target %.ko 2019-08-09T16:40:25+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2019-08-02T10:23:58+00:00 47801c97deb71b9e279c15a02a44cf00aa11e7d9 I removed the single target %.ko in commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod") because the modpost stage does not work reliably. For instance, the module dependency, modversion, etc. do not work if we lack symbol information from the other modules. Yet, some people still want to build only one module in their interest, and it may be still useful if it is used within those limitations. Fixes: ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod") Reported-by: Don Brace <don.brace@microsemi.com> Reported-by: Arend Van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 
I removed the single target %.ko in commit ff9b45c55b26 ("kbuild:
modpost: read modules.order instead of $(MODVERDIR)/*.mod") because
the modpost stage does not work reliably. For instance, the module
dependency, modversion, etc. do not work if we lack symbol information
from the other modules.

Yet, some people still want to build only one module in their interest,
and it may be still useful if it is used within those limitations.

Fixes: ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod")
Reported-by: Don Brace <don.brace@microsemi.com>
Reported-by: Arend Van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
kconfig: Clear "written" flag to avoid data loss 2019-08-04T03:44:15+00:00 M. Vefa Bicakci m.v.b@runbox.com 2019-08-03T10:02:12+00:00 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce Prior to this commit, starting nconfig, xconfig or gconfig, and saving the .config file more than once caused data loss, where a .config file that contained only comments would be written to disk starting from the second save operation. This bug manifests itself because the SYMBOL_WRITTEN flag is never cleared after the first call to conf_write, and subsequent calls to conf_write then skip all of the configuration symbols due to the SYMBOL_WRITTEN flag being set. This commit resolves this issue by clearing the SYMBOL_WRITTEN flag from all symbols before conf_write returns. Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf") Cc: linux-stable <stable@vger.kernel.org> # 4.19+ Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 
Prior to this commit, starting nconfig, xconfig or gconfig, and saving
the .config file more than once caused data loss, where a .config file
that contained only comments would be written to disk starting from the
second save operation.

This bug manifests itself because the SYMBOL_WRITTEN flag is never
cleared after the first call to conf_write, and subsequent calls to
conf_write then skip all of the configuration symbols due to the
SYMBOL_WRITTEN flag being set.

This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
from all symbols before conf_write returns.

Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf")
Cc: linux-stable <stable@vger.kernel.org> # 4.19+
Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>