Reapplied clang patches onto your latest mko-v2 work #5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Backport to msm-3.18 kerneltoast/android_kernel_google_wahoo@fc4b4ea Rather than going way back and removing the original commit, just patch in the latest version of this.
HEAD: "Backend: speed up and simplify is_mounted use" + AK3: add file/directory attributes functions + Example: update to use set_perm_recursive + AK3: reset_ak: don't remove $ramdisk unless has already been unpacked
In case the target node requests a security context, the extra_buffers_size is increased with the size of the security context. But, that size is not available for use by regular scatter-gather buffers; make sure the ending of that buffer is marked correctly. Bug: 136210786 Acked-by: Todd Kjos <[email protected]> Fixes: ec74136ded79 ("binder: create node flag to request sender's security context") Signed-off-by: Martijn Coenen <[email protected]> Cc: [email protected] # 5.1+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit a56587065094fd96eb4c2b5ad65571daad32156d)
…napshot
"kernel.h: handle pointers to arrays better in container_of()" triggers:
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/syscalls.h:71,
from fs/dcache.c:17:
fs/dcache.c: In function 'release_dentry_name_snapshot':
include/linux/compiler.h:542:38: error: call to '__compiletime_assert_305' declared with attribute error: pointer type mismatch in container_of()
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:525:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^
include/linux/compiler.h:542:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/build_bug.h:46:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
include/linux/kernel.h:860:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^
fs/dcache.c:305:7: note: in expansion of macro 'container_of'
p = container_of(name->name, struct external_name, name[0]);
Switch name_snapshot to use unsigned chars, matching struct qstr and
struct external_name.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit 0a2c13d9cd76c84f2520f573ff83f777eb7464aa)
Signed-off-by: Nathan Chancellor <[email protected]>
When the host's C compiler is clang, and when attempting to cross-compile Linux e.g. to MIPS with mipsel-linux-gcc, the Makefile would incorrectly detect the use of clang, which resulted in clang-specific flags being passed to mipsel-linux-gcc. This can be verified under Debian by installing the "clang" package, and then using it as the default compiler with: sudo update-alternatives --config cc This patch moves the detection of clang after the $(CC) variable is initialized to the name of the cross-compiler, so that the check applies to the cross-compiler and not the host's C compiler. v2: Move the detection of clang after the inclusion of the arch/*/Makefile (as they might set $(CROSS_COMPILE)) Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Michal Marek <[email protected]> (cherry picked from commit ee4eb20) Signed-off-by: Nathan Chancellor <[email protected]>
We cannot detect clang before including the arch Makefile, because that can set the default cross compiler. We also cannot detect clang after including the arch Makefile, because powerpc wants to know about clang. Solve this by using an deferred variable. This costs us a few shell invocations, but this is only a constant number. Reported-by: Behan Webster <[email protected]> Reported-by: Anton Blanchard <[email protected]> Signed-off-by: Michal Marek <[email protected]> (cherry picked from commit 5631d9c) Signed-off-by: Nathan Chancellor <[email protected]>
Add cross target to CC if using clang. Also add custom gcc toolchain path for fallback gcc tools. Clang will fallback to using things like ld, as, and libgcc if (respectively) one of the llvm linkers isn't available, the integrated assembler is turned off, or an appropriately cross-compiled version of compiler-rt isn't available. To this end, you can specify the path to this fallback gcc toolchain with GCC_TOOLCHAIN. Signed-off-by: Behan Webster <[email protected]> Reviewed-by: Jan-Simon Möller <[email protected]> Reviewed-by: Mark Charlebois <[email protected]> Signed-off-by: Greg Hackmann <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> (cherry picked from commit 785f11aa595bc3d4e74096cbd598ada54ecc0d81) Signed-off-by: Nathan Chancellor <[email protected]>
The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque object which will not have any validation performed on the content. The current behaviour in LLVM is to perform validation of the contents by means of parsing the input if the MC layer can handle it. Disable clangs integrated assembler and use the GNU assembler instead. Wording-mostly-from: Saleem Abdulrasool <[email protected]> Signed-off-by: Michael Davidson <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> (cherry picked from commit a37c45cd82e62a361706b9688a984a3a63957321) Signed-off-by: Nathan Chancellor <[email protected]>
The rules "cmd_bounds" and "cmd_offsets" are almost the same. (The difference is only the include guards.) They can be merged. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Michal Marek <[email protected]> (cherry picked from commit 39664e2) Signed-off-by: Nathan Chancellor <[email protected]>
This line produces an extra comment line for bounds.h and asm-offsets.h. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Michal Marek <[email protected]> (cherry picked from commit 343d3e6) Signed-off-by: Nathan Chancellor <[email protected]>
…needed Use filechk to generate asm-offsets.h and bounds.h. Based on a patch by Valdis Kletnieks. Reported-by: Valdis Kletnieks <[email protected]> Acked-By: Valdis Kletnieks <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Michal Marek <[email protected]> (cherry picked from commit 70a4fd6) Signed-off-by: Nathan Chancellor <[email protected]>
…rgets $(always) is added to targets by scripts/Makefile.build. Moreover, filechk does not need .*.cmd files. Adding these two files to targets is redundant. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Michal Marek <[email protected]> (cherry picked from commit 8a58e16) Signed-off-by: Nathan Chancellor <[email protected]>
…mation Largely redundant code is used in different places to generate C headers from offset information extracted from assembly language output. Consolidate the code in Makefile.lib and use this instead. Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> (cherry picked from commit ebf003f0cfb3705e60d40dedc3ec949176c741af) Signed-off-by: Nathan Chancellor <[email protected]>
This part ended up in redundant code after touched by multiple people. [1] Commit 3234282 ("x86, asm: Fix CFI macro invocations to deal with shortcomings in gas") added parentheses for defined expressions to support old gas for x86. [2] Commit a22dcdb ("x86, asm: Fix ancient-GAS workaround") split the pattern into two to avoid parentheses for non-numeric expressions. [3] Commit 95a2f6f ("Partially revert patch that encloses asm-offset.h numbers in brackets") removed parentheses from numeric expressions as well because parentheses in MN10300 assembly have a special meaning (pointer access). Apparently, there is a conflict between [1] and [3]. After all, [3] took precedence, and a long time has passed since then. Now, merge the two patterns again because the first one is covered by the other. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> (cherry picked from commit 7dd47b95b0f54f2057d40af6e66d477e3fe95d13) Signed-off-by: Nathan Chancellor <[email protected]>
KBuild abuses the asm statement to write to a file and clang chokes about these invalid asm statements. Hack it even more by fooling this is actual valid asm code. [masahiro: Import Jeroen's work for U-Boot: http://patchwork.ozlabs.org/patch/375026/ Tweak sed script a little to avoid garbage '#' for GCC case, like #define NR_PAGEFLAGS 23 /* __NR_PAGEFLAGS # */ ] Signed-off-by: Jeroen Hofstee <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Tested-by: Matthias Kaehlcke <[email protected]> (cherry picked from commit cf0c3e68aa81f992b0301f62e341b710d385bf68) Signed-off-by: Nathan Chancellor <[email protected]>
Clang will warn about unknown warnings but will not return false
unless -Werror is set. GCC will return false if an unknown
warning is passed.
Adding -Werror make both compiler behave the same.
[arnd: it turns out we need the same patch for testing whether -ffunction-sections
works right with gcc. I've build tested extensively with this patch
applied, so let's just merge this one now.]
Upstream commit: c3f0d0bc5b01
Signed-off-by: Mark Charlebois <[email protected]>
Signed-off-by: Behan Webster <[email protected]>
Reviewed-by: Jan-Simon Mller <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Kees Cook <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to
cc-option to support clang"), cc-option and friends work nicely
for clang.
However, -Wno-unknown-warning-option makes clang happy with any
unknown warning options even if -Werror is specified.
Once -Wno-unknown-warning-option is added, any succeeding call of
cc-disable-warning is evaluated positive, then unknown warning
options are accepted. This should be dropped.
Signed-off-by: Masahiro Yamada <[email protected]>
(cherry picked from commit a0ae981eba8f07dbc74bce38fd3a462b69a5bc8e)
Signed-off-by: Nathan Chancellor <[email protected]>
This generates smaller resulting object code when compiled with clang. Signed-off-by: Behan Webster <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> (cherry picked from commit 6748cb3c299de1ffbe56733647b01dbcc398c419) Signed-off-by: Nathan Chancellor <[email protected]>
Add rules to kbuild in order to generate LLVM assembly files with the .ll extension when using clang. # from c code make CC=clang kernel/pid.ll Signed-off-by: Vinícius Tinti <[email protected]> Signed-off-by: Behan Webster <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> (cherry picked from commit 433db3e260bc8134d4a46ddf20b3668937e12556) Signed-off-by: Nathan Chancellor <[email protected]>
clang warns about unused inline functions by default: arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' [-Wunused-function] arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' [-Wunused-function] As these appear in every single module, let's just disable the warnings by marking the two functions as __maybe_unused. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Miroslav Benes <[email protected]> Acked-by: Rusty Russell <[email protected]> Signed-off-by: Jessica Yu <[email protected]> (cherry picked from commit 1f318a8bafcfba9f0d623f4870c4e890fd22e659) Signed-off-by: Nathan Chancellor <[email protected]>
The default __UNIQUE_ID macro in compiler.h fails to work for some drivers:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:615:1: error: redefinition of
'__UNIQUE_ID_firmware615'
BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
This adds a copy of the version we use for gcc-4.3 and higher, as the same
one works with all versions of clang that I could find in svn (2.6 and higher).
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
(cherry picked from commit b41c29b0527c7fd6a95d0f71274abb79933bf960)
Signed-off-by: Nathan Chancellor <[email protected]>
…functions GCC explicitly does not warn for unused static inline functions for -Wunused-function. The manual states: Warn whenever a static function is declared but not defined or a non-inline static function is unused. Clang does warn for static inline functions that are unused. It turns out that suppressing the warnings avoids potentially complex Suppress the warning for clang. Signed-off-by: David Rientjes <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit abb2ea7dfd82451d85ce669b811310c05ab5ca46) Signed-off-by: Nathan Chancellor <[email protected]>
Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused
static inline functions") just caused more warnings due to re-defining
the 'inline' macro.
So undef it before re-defining it, and also add the 'notrace' attribute
like the gcc version that this is overriding does.
Maybe this makes clang happier.
Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit 6d53cefb18e4646fb4bf62ccb6098fb3808486df)
Signed-off-by: Nathan Chancellor <[email protected]>
…G is disabled
The motivation for commit abb2ea7dfd82 ("compiler, clang: suppress
warning for unused static inline functions") was to suppress clang's
warnings about unused static inline functions.
For configs without CONFIG_OPTIMIZE_INLINING enabled, such as any non-x86
architecture, `inline' in the kernel implies that
__attribute__((always_inline)) is used.
Some code depends on that behavior, see
https://lkml.org/lkml/2017/6/13/918:
net/built-in.o: In function `__xchg_mb':
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to `__compiletime_assert_99'
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to `__compiletime_assert_99
The full fix would be to identify these breakages and annotate the
functions with __always_inline instead of `inline'. But since we are
late in the 4.12-rc cycle, simply carry forward the forced inlining
behavior and work toward moving arm64, and other architectures, toward
CONFIG_OPTIMIZE_INLINING behavior.
(cherry picked from commit 9a04dbcfb33b4012d0ce8c0282f1e3ca694675b1)
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: David Rientjes <[email protected]>
Reported-by: Sodagudi Prasad <[email protected]>
Tested-by: Sodagudi Prasad <[email protected]>
Tested-by: Matthias Kaehlcke <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
clang generates plenty of these warnings in different parts of the code, to an extent that the warnings are little more than noise. Disable the 'address-of-packed-member' warning. Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> (cherry picked from commit bfb38988c51e440fd7062ddf3157f7d8b1dd5d70) Signed-off-by: Nathan Chancellor <[email protected]>
To reduce the number of copies of boilerplate code throughout the tree, this patch implements generic glue for the SHA-256 algorithm. This allows a specific arch or hardware implementation to only implement the special handling that it needs. The users need to supply an implementation of void (sha256_block_fn)(struct sha256_state *sst, u8 const *src, int blocks) and pass it to the SHA-256 base functions. For easy casting between the prototype above and existing block functions that take a 'u32 state[]' as their first argument, the 'state' member of struct sha256_state is moved to the base of the struct. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit 11b8d5e) Signed-off-by: Nathan Chancellor <[email protected]>
To reduce the number of copies of boilerplate code throughout the tree, this patch implements generic glue for the SHA-512 algorithm. This allows a specific arch or hardware implementation to only implement the special handling that it needs. The users need to supply an implementation of void (sha512_block_fn)(struct sha512_state *sst, u8 const *src, int blocks) and pass it to the SHA-512 base functions. For easy casting between the prototype above and existing block functions that take a 'u64 state[]' as their first argument, the 'state' member of struct sha512_state is moved to the base of the struct. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit b84a2a0) Signed-off-by: Nathan Chancellor <[email protected]>
This updated the generic SHA-1 implementation to use the generic shared SHA-1 glue code. It also implements a .finup hook crypto_sha1_finup() and exports it to other modules. The import and export() functions and the .statesize member are dropped, since the default implementation is perfectly suitable for this module. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit 7c71f0f) Signed-off-by: Nathan Chancellor <[email protected]>
This updates the generic SHA-256 implementation to use the new shared SHA-256 glue code. It also implements a .finup hook crypto_sha256_finup() and exports it to other modules. The import and export() functions and the .statesize member are dropped, since the default implementation is perfectly suitable for this module. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit a2e5ba4) Signed-off-by: Nathan Chancellor <[email protected]>
This updated the generic SHA-512 implementation to use the generic shared SHA-512 glue code. It also implements a .finup hook crypto_sha512_finup() and exports it to other modules. The import and export() functions and the .statesize member are dropped, since the default implementation is perfectly suitable for this module. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit ca14258) Signed-off-by: Nathan Chancellor <[email protected]>
../drivers/clk/msm/clock-gcc-8996.c:201:33: error: implicit conversion from 'double' to '_Bool' changes value from 2.5 to true [-Werror,-Wliteral-conversion]
F( 240000000, gpll0_out_main, 2.5, 0, 0),
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
../drivers/clk/msm/clock-gcc-8996.c:53:41: note: expanded from macro 'F'
.div_src_val = BVAL(4, 0, (int)FIXDIV(div)) \
~~~~~~~^~~~
../drivers/clk/msm/clock-gcc-8996.c:44:22: note: expanded from macro 'FIXDIV'
#define FIXDIV(div) (div ? (2 * (div) - 1) : (0))
^~~ ~
../include/linux/clk/msm-clk-provider.h:36:32: note: expanded from macro 'BVAL'
#define BVAL(msb, lsb, val) (((val) << lsb) & BM(msb, lsb))
Signed-off-by: Albert I <[email protected]>
[@nathanchance: Make title more descriptive and fix warning text]
Signed-off-by: Nathan Chancellor <[email protected]>
../sound/soc/msm/qdsp6v2/q6lsm.c:255:33: error: expression which evaluates to zero treated as a null pointer constant of type 'struct lsm_client *' [-Werror,-Wnon-literal-null-conversion]
lsm_session[client->session] = LSM_INVALID_SESSION_ID;
^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: yarost12 <[email protected]>
Signed-off-by: Albert I <[email protected]>
[@nathanchance: Improve changelog text]
Signed-off-by: Nathan Chancellor <[email protected]>
lsm_session is a pointer, setting it to zero is technically allowed but NULL is a little clearer and every point of the code just checks that lsm_session with a logical not so NULL doesn't change the meaning anywhere. Signed-off-by: Nathan Chancellor <[email protected]>
Clang complains about converting between ion_heap_type and msm_ion_heap_type. They ultimately don't conflict with each other as msm_ion_heap_type supplements ion_heap_type but Clang can't see that. Just change type into a int. Signed-off-by: Nathan Chancellor <[email protected]>
These are now fixed. Signed-off-by: Nathan Chancellor <[email protected]>
We should avoid using the space character when passing arguments to clang, because static code analysis check tool such as sparse may misinterpret the arguments followed by spaces as build targets hence cause the build to fail. Signed-off-by: David Lin <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> (cherry picked from commit bb3f38c3c5b759163e09b9152629cc789731de47) Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Kyle Elbert <[email protected]>
…nel_maker_id() to touch_device_type Fixes -Wenum-conversion for clang
…attribute by properly placing it after struct
same as last, ignored attribute packed fixed
…l-not-parentheses] no idea if should do if (rawdata_ret == 0 && (!((tc_status_val >> 28) & 0x1))) or add parentheses (!((tc_status_val >> 28)) & 0x1)) so trying first for now
:1675:16: error: stack frame size of 2640 bytes in function 'show_sd' Knocked the stack frame usage size down a bit, but not enough to silence -Wframe-larger-than altogether not sure how to decrease usage further, so silenced the warning by adjusting the warning size for this file in the Makefile
…is.c:612
:9: error: stack frame size of 3488 bytes in function
'lgit_imx298_init_set_rohm_ois' [-Werror,-Wframe-larger-than=]
Again, no clear idea how to solve the warning in this case, so suppressing
mostly when hitting default cases that will never ever happen in real use
…t a string literal
…quality comparison with extraneous parentheses
Signed-off-by: Kyle Elbert <[email protected]>
|
Hey I'd like to merge this, but was thinking I'd try to merge myself latest changes into existing clang branch, as the problem is probably that you need to back and reapply from a certain point (did a lot of force pushes to mko-2 since last clang update). |
stendro
force-pushed
the
mko-v2-clang
branch
2 times, most recently
from
11c8ccf to
a1ed14d
Compare
|
if you can just force the branch to my HEAD ( 0cd6eef ) we'd be set.
Yeah, those force commits caused issues trying to merge in the changes automatically, so I reapplied the clang patches from scratch onto your latest mko-v2.
It looks like there are many differences, even from your merge a few hours ago.
|
stendro
pushed a commit
that referenced
this pull request
Sep 26, 2021
{min,max}_capacity are static variables that are only updated from
__update_min_max_capacity(), but not used anywhere else.
Remove them together with the function updating them. This has also
the nice side effect of fixing a LOCKDEP warning related to locking
all CPUs in update_min_max_capacity(), as reported by Ke Wang:
[ 2.853595] c0 =============================================
[ 2.859219] c0 [ INFO: possible recursive locking detected ]
[ 2.864852] c0 4.4.6+ #5 Tainted: G W
[ 2.869604] c0 ---------------------------------------------
[ 2.875230] c0 swapper/0/1 is trying to acquire lock:
[ 2.880248] (&rq->lock){-.-.-.}, at: [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 2.888815] c0
[ 2.888815] c0 but task is already holding lock:
[ 2.895132] (&rq->lock){-.-.-.}, at: [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 2.903700] c0
[ 2.903700] c0 other info that might help us debug this:
[ 2.910710] c0 Possible unsafe locking scenario:
[ 2.910710] c0
[ 2.917112] c0 CPU0
[ 2.919795] c0 ----
[ 2.922478] lock(&rq->lock);
[ 2.925507] lock(&rq->lock);
[ 2.928536] c0
[ 2.928536] c0 *** DEADLOCK ***
[ 2.928536] c0
[ 2.935200] c0 May be due to missing lock nesting notation
[ 2.935200] c0
[ 2.942471] c0 7 locks held by swapper/0/1:
[ 2.946623] #0: (&dev->mutex){......}, at: [<ffffff800850e118>] __driver_attach+0x64/0xb8
[ 2.954931] #1: (&dev->mutex){......}, at: [<ffffff800850e128>] __driver_attach+0x74/0xb8
[ 2.963239] #2: (cpu_hotplug.lock){++++++}, at: [<ffffff80080cb218>] get_online_cpus+0x48/0xa8
[ 2.971979] #3: (subsys mutex#6){+.+.+.}, at: [<ffffff800850bed4>] subsys_interface_register+0x44/0xc0
[ 2.981411] #4: (&policy->rwsem){+.+.+.}, at: [<ffffff8008720338>] cpufreq_online+0x330/0x76c
[ 2.990065] #5: ((cpufreq_policy_notifier_list).rwsem){.+.+..}, at: [<ffffff80080f3418>] blocking_notifier_call_chain+0x38/0xc4
[ 3.001661] #6: (&rq->lock){-.-.-.}, at: [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 3.010661] c0
[ 3.010661] c0 stack backtrace:
[ 3.015514] c0 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.4.6+ #5
[ 3.022864] c0 Hardware name: Spreadtrum SP9860g Board (DT)
[ 3.028402] c0 Call trace:
[ 3.031092] c0 [<ffffff800808b50c>] dump_backtrace+0x0/0x210
[ 3.036716] c0 [<ffffff800808b73c>] show_stack+0x20/0x28
[ 3.041994] c0 [<ffffff8008433310>] dump_stack+0xa8/0xe0
[ 3.047273] c0 [<ffffff80081349e0>] __lock_acquire+0x1e0c/0x2218
[ 3.053243] c0 [<ffffff80081353c0>] lock_acquire+0xe0/0x280
[ 3.058784] c0 [<ffffff8008abfdfc>] _raw_spin_lock+0x44/0x58
[ 3.064407] c0 [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 3.070983] c0 [<ffffff80080f3458>] blocking_notifier_call_chain+0x78/0xc4
[ 3.077820] c0 [<ffffff8008720294>] cpufreq_online+0x28c/0x76c
[ 3.083618] c0 [<ffffff80087208a4>] cpufreq_add_dev+0x98/0xdc
[ 3.089331] c0 [<ffffff800850bf14>] subsys_interface_register+0x84/0xc0
[ 3.095907] c0 [<ffffff800871fa0c>] cpufreq_register_driver+0x168/0x28c
[ 3.102486] c0 [<ffffff80087272f8>] sprd_cpufreq_probe+0x134/0x19c
[ 3.108629] c0 [<ffffff8008510768>] platform_drv_probe+0x58/0xd0
[ 3.114599] c0 [<ffffff800850de2c>] driver_probe_device+0x1e8/0x470
[ 3.120830] c0 [<ffffff800850e168>] __driver_attach+0xb4/0xb8
[ 3.126541] c0 [<ffffff800850b750>] bus_for_each_dev+0x6c/0xac
[ 3.132339] c0 [<ffffff800850d6c0>] driver_attach+0x2c/0x34
[ 3.137877] c0 [<ffffff800850d234>] bus_add_driver+0x210/0x298
[ 3.143676] c0 [<ffffff800850f1f4>] driver_register+0x7c/0x114
[ 3.149476] c0 [<ffffff8008510654>] __platform_driver_register+0x60/0x6c
[ 3.156139] c0 [<ffffff8008f49f40>] sprd_cpufreq_platdrv_init+0x18/0x20
[ 3.162714] c0 [<ffffff8008082a64>] do_one_initcall+0xd0/0x1d8
[ 3.168514] c0 [<ffffff8008f0bc58>] kernel_init_freeable+0x1fc/0x29c
[ 3.174834] c0 [<ffffff8008ab554c>] kernel_init+0x20/0x12c
[ 3.180281] c0 [<ffffff8008086290>] ret_from_fork+0x10/0x40
Reported-by: Ke Wang <[email protected]>
Signed-off-by: Juri Lelli <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Noticed an issue building after merging in your latest changes on top of the existing mko-v2-clang branch, so starting from your current mko-v2 head I reapplied the clang patches. Still seems to build (with clang)..
On the side, I see you closed your V20 thread, are you done with the V20 then? If so I'm about done myself... but I'm holding off until I get my hands on a Pixel 4, though the occasional minor maintenance might still get done