user/sven/linux.git/scripts, branch v5.8.11

kconfig: qconf: use delete[] instead of delete to free array (again)

2020-09-23T10:59:58Z

[ Upstream commit a608b6a646e8816bc0db156baad2e0679fa4d137 ] Commit c9b09a9249e6 ("kconfig: qconf: use delete[] instead of delete to free array") fixed two lines, but there is one more. (cppcheck does not report it for some reason...) This was detected by Clang. "make HOSTCXX=clang++ xconfig" reports the following: scripts/kconfig/qconf.cc:1279:2: warning: 'delete' applied to a pointer that was allocated with 'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete] delete data; ^ [] scripts/kconfig/qconf.cc:1239:15: note: allocated with 'new[]' here char *data = new char[count + 1]; ^ Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Fixes: c9b09a9249e6 ("kconfig: qconf: use delete[] instead of delete to free array") Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin

checkpatch: fix the usage of capture group ( ... )

2020-09-09T17:14:33Z

commit 13e45417cedbfc44b1926124b1846f5ee8c6ba4a upstream. The usage of "capture group (...)" in the immediate condition after `&&` results in `$1` being uninitialized. This issues a warning "Use of uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl line 2638". I noticed this bug while running checkpatch on the set of commits from v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in their commit message. This bug was introduced in the script by commit e518e9a59ec3 ("checkpatch: emit an error when there's a diff in a changelog"). It has been in the script since then. The author intended to store the match made by capture group in variable `$1`. This should have contained the name of the file as `[\w/]+` matched. However, this couldn't be accomplished due to usage of capture group and `$1` in the same regular expression. Fix this by placing the capture group in the condition before `&&`. Thus, `$1` can be initialized to the text that capture group matches thereby setting it to the desired and required value. Fixes: e518e9a59ec3 ("checkpatch: emit an error when there's a diff in a changelog") Signed-off-by: Mrinal Pandey Signed-off-by: Andrew Morton Tested-by: Lukas Bulwahn Reviewed-by: Lukas Bulwahn Cc: Joe Perches Link: https://lkml.kernel.org/r/20200714032352.f476hanaj2dlmiot@mrinalpandey Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

kconfig: streamline_config.pl: check defined(ENV variable) before using it

2020-09-09T17:14:33Z

commit a73fbfce2cc28883f659414d598e6e60ca2214b4 upstream. A user reported: 'Use of uninitialized value $ENV{"LMC_KEEP"} in split at ./scripts/kconfig/streamline_config.pl line 596.' so first check that $ENV{LMC_KEEP} is defined before trying to use it. Fixes: c027b02d89fd ("streamline_config.pl: add LMC_KEEP to preserve some kconfigs") Signed-off-by: Randy Dunlap Acked-by: Steven Rostedt (VMware) Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kconfig: qconf: remove qInfo() to get back Qt4 support

2020-08-26T09:49:16Z

[ Upstream commit 53efe2e76ca2bfad7f35e0b5330e2ccd44a643e3 ] qconf is supposed to work with Qt4 and Qt5, but since commit c4f7398bee9c ("kconfig: qconf: make debug links work again"), building with Qt4 fails as follows: HOSTCXX scripts/kconfig/qconf.o scripts/kconfig/qconf.cc: In member function ‘void ConfigInfoView::clicked(const QUrl&)’: scripts/kconfig/qconf.cc:1241:3: error: ‘qInfo’ was not declared in this scope; did you mean ‘setInfo’? 1241 | qInfo() << "Clicked link is empty"; | ^~~~~ | setInfo scripts/kconfig/qconf.cc:1254:3: error: ‘qInfo’ was not declared in this scope; did you mean ‘setInfo’? 1254 | qInfo() << "Clicked symbol is invalid:" << data; | ^~~~~ | setInfo make[1]: *** [scripts/Makefile.host:129: scripts/kconfig/qconf.o] Error 1 make: *** [Makefile:606: xconfig] Error 2 qInfo() does not exist in Qt4. In my understanding, these call-sites should be unreachable. Perhaps, qWarning(), assertion, or something is better, but qInfo() is not the right one to use here, I think. Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Reported-by: Ronald Warsow Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: qconf: fix signal connection to invalid slots

2020-08-26T09:49:15Z

[ Upstream commit d85de3399f97467baa2026fbbbe587850d01ba8a ] If you right-click in the ConfigList window, you will see the following messages in the console: QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:888 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:897 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:906 QObject::connect: (sender name: 'config') Right, there is no such slot in QAction. I think this is a typo of setChecked. Due to this bug, when you toggled the menu "Option->Show Name/Range/Data" the state of the context menu was not previously updated. Fix this. Fixes: d5d973c3f8a9 ("Port xconfig to Qt5 - Put back some of the old implementation(part 2)") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: qconf: do not limit the pop-up menu to the first row

2020-08-26T09:49:15Z

[ Upstream commit fa8de0a3bf3c02e6f00b7746e7e934db522cdda9 ] If you right-click the first row in the option tree, the pop-up menu shows up, but if you right-click the second row or below, the event is ignored due to the following check: if (e->y() <= header()->geometry().bottom()) { Perhaps, the intention was to show the pop-menu only when the tree header was right-clicked, but this handler is not called in that case. Since the origin of e->y() starts from the bottom of the header, this check is odd. Going forward, you can right-click anywhere in the tree to get the pop-up menu. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

recordmcount: Fix build failure on non arm64

2020-08-21T11:15:16Z

[ Upstream commit 3df14264ad9930733a8166e5bd0eccc1727564bb ] Commit ea0eada45632 leads to the following build failure on powerpc: HOSTCC scripts/recordmcount scripts/recordmcount.c: In function 'arm64_is_fake_mcount': scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function) scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once scripts/recordmcount.c:440: error: for each function it appears in.) make[2]: *** [scripts/recordmcount] Error 1 Make sure R_AARCH64_CALL26 is always defined. Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.") Signed-off-by: Christophe Leroy Acked-by: Steven Rostedt (VMware) Acked-by: Gregory Herrero Cc: Gregory Herrero Link: https://lore.kernel.org/r/5ca1be21fa6ebf73203b45fd9aadd2bafb5e6b15.1597049145.git.christophe.leroy@csgroup.eu Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

scripts/selinux/mdp: fix initial SID handling

2020-08-19T06:26:12Z

[ Upstream commit 382c2b5d23b4245f1818f69286db334355488dc4 ] commit e3e0b582c321 ("selinux: remove unused initial SIDs and improve handling") broke scripts/selinux/mdp since the unused initial SID names were removed and the corresponding generation of policy initial SID definitions by mdp was not updated accordingly. Fix it. With latest upstream checkpolicy it is no longer necessary to include the SID context definitions for the unused initial SIDs but retain them for compatibility with older checkpolicy. Fixes: e3e0b582c321 ("selinux: remove unused initial SIDs and improve handling") Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin

recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.

2020-08-19T06:26:10Z

[ Upstream commit ea0eada45632f4807b2f49de951072283e2d781c ] Currently, if a section has a relocation to '_mcount' symbol, a new __mcount_loc entry will be added whatever the relocation type is. This is problematic when a relocation to '_mcount' is in the middle of a section and is not a call for ftrace use. Such relocation could be generated with below code for example: bool is_mcount(unsigned long addr) { return (target == (unsigned long) &_mcount); } With this snippet of code, ftrace will try to patch the mcount location generated by this code on module load and fail with: Call trace: ftrace_bug+0xa0/0x28c ftrace_process_locs+0x2f4/0x430 ftrace_module_init+0x30/0x38 load_module+0x14f0/0x1e78 __do_sys_finit_module+0x100/0x11c __arm64_sys_finit_module+0x28/0x34 el0_svc_common+0x88/0x194 el0_svc_handler+0x38/0x8c el0_svc+0x8/0xc ---[ end trace d828d06b36ad9d59 ]--- ftrace failed to modify [] 0xffffa2dbf3a3a41c actual: 66:a9:3c:90 Initializing ftrace call sites ftrace record flags: 2000000 (0) expected tramp: ffffa2dc6cf66724 So Limit the relocation type to R_AARCH64_CALL26 as in perl version of recordmcount. Fixes: af64d2aa872a ("ftrace: Add arm64 support to recordmcount") Signed-off-by: Gregory Herrero Acked-by: Steven Rostedt (VMware) Link: https://lore.kernel.org/r/20200717143338.19302-1-gregory.herrero@oracle.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

scripts: add dummy report mode to add_namespace.cocci

2020-08-11T13:48:09Z

commit 55c7549819e438f40a3ef1d8ac5c38b73390bcb7 upstream. When running `make coccicheck` in report mode using the add_namespace.cocci file, it will fail for files that contain MODULE_LICENSE. Those match the replacement precondition, but spatch errors out as virtual.ns is not set. In order to fix that, add the virtual rule nsdeps and only do search and replace if that rule has been explicitly requested. In order to make spatch happy in report mode, we also need a dummy rule, as otherwise it errors out with "No rules apply". Using a script:python rule appears unrelated and odd, but this is the shortest I could come up with. Adjust scripts/nsdeps accordingly to set the nsdeps rule when run trough `make nsdeps`. Suggested-by: Julia Lawall Fixes: c7c4e29fb5a4 ("scripts: add_namespace: Fix coccicheck failed") Cc: YueHaibing Cc: jeyu@kernel.org Cc: cocci@systeme.lip6.fr Cc: stable@vger.kernel.org Signed-off-by: Matthias Maennich Reported-by: Shuah Khan Acked-by: Julia Lawall Link: https://lore.kernel.org/r/20200604164145.173925-1-maennich@google.com Signed-off-by: Greg Kroah-Hartman