Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Out of tree build fixes #121

Open
wants to merge 2 commits into
base: release-4.4
Choose a base branch
from
Open

Out of tree build fixes #121

wants to merge 2 commits into from

Conversation

kraj
Copy link
Contributor

@kraj kraj commented Sep 1, 2018

No description provided.

When builing with make O=<dir> option this fails
with errors since it can't find the header in the
relative tree, prepending srctree is the right
thing to do here.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
When builing with make O=<dir> option this fails
with errors since it can't find the header in the
relative tree, prepending srctree is the right
thing to do here.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
@rkchrome rkchrome force-pushed the release-4.4 branch 2 times, most recently from 3fb5973 to 4311650 Compare September 26, 2018 06:01
@keveryang
Copy link
Member

We are not able to merge the PR with so much patches, because we do have to pick the patches in internal Gerrit for review, and for the kernel maintain:

  1. we will merge stable update from upstream, so don't send patch from stable branck;
  2. please send the patches you really need and in upstream coding style, so that we can review it.

rkchrome pushed a commit that referenced this pull request Aug 23, 2019
[ Upstream commit 80bf6ce ]

When we get into activate_mm(), lockdep complains that we're doing
something strange:

    WARNING: possible circular locking dependency detected
    5.1.0-10252-gb00152307319-dirty #121 Not tainted
    ------------------------------------------------------
    inside.sh/366 is trying to acquire lock:
    (____ptrval____) (&(&p->alloc_lock)->rlock){+.+.}, at: flush_old_exec+0x703/0x8d7

    but task is already holding lock:
    (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&mm->mmap_sem){++++}:
           [...]
           __lock_acquire+0x12ab/0x139f
           lock_acquire+0x155/0x18e
           down_write+0x3f/0x98
           flush_old_exec+0x748/0x8d7
           load_elf_binary+0x2ca/0xddb
           [...]

    -> #0 (&(&p->alloc_lock)->rlock){+.+.}:
           [...]
           __lock_acquire+0x12ab/0x139f
           lock_acquire+0x155/0x18e
           _raw_spin_lock+0x30/0x83
           flush_old_exec+0x703/0x8d7
           load_elf_binary+0x2ca/0xddb
           [...]

    other info that might help us debug this:

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----
      lock(&mm->mmap_sem);
                                   lock(&(&p->alloc_lock)->rlock);
                                   lock(&mm->mmap_sem);
      lock(&(&p->alloc_lock)->rlock);

     *** DEADLOCK ***

    2 locks held by inside.sh/366:
     #0: (____ptrval____) (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file+0x12d/0x869
     #1: (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7

    stack backtrace:
    CPU: 0 PID: 366 Comm: inside.sh Not tainted 5.1.0-10252-gb00152307319-dirty #121
    Stack:
     [...]
    Call Trace:
     [<600420de>] show_stack+0x13b/0x155
     [<6048906b>] dump_stack+0x2a/0x2c
     [<6009ae64>] print_circular_bug+0x332/0x343
     [<6009c5c6>] check_prev_add+0x669/0xdad
     [<600a06b4>] __lock_acquire+0x12ab/0x139f
     [<6009f3d0>] lock_acquire+0x155/0x18e
     [<604a07e0>] _raw_spin_lock+0x30/0x83
     [<60151e6a>] flush_old_exec+0x703/0x8d7
     [<601a8eb8>] load_elf_binary+0x2ca/0xddb
     [...]

I think it's because in exec_mmap() we have

	down_read(&old_mm->mmap_sem);
...
        task_lock(tsk);
...
	activate_mm(active_mm, mm);
	(which does down_write(&mm->mmap_sem))

I'm not really sure why lockdep throws in the whole knowledge
about the task lock, but it seems that old_mm and mm shouldn't
ever be the same (and it doesn't deadlock) so tell lockdep that
they're different.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hejiawencc pushed a commit to LubanCat/kernel that referenced this pull request Jan 10, 2024
Ref: commit 20d9fde ("ASoC: soc-core: add snd_soc_find_dai_with_mutex()")

This patch fix WARNING when config enable CONFIG_LOCKDEP:

WARNING: CPU: 2 PID: 1 at sound/soc/soc-core.c:816 snd_soc_find_dai+0x120/0x128
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.66 rockchip-linux#121
pstate: 60c00009 (nZCv daif +PAN +UAO -TCO BTYPE=--)
pc : snd_soc_find_dai+0x120/0x128
lr : snd_soc_find_dai+0x40/0x128
sp : ffffffc0130eb910
x29: ffffffc0130eb910 x28: 0000000000000000
x27: ffffff80eefdeda0 x26: 0000000000000002
x25: 0000000000000002 x24: ffffff800c20a590
x23: ffffff80ef06a6e8 x22: ffffff800c20a480
x21: ffffff800c1ab680 x20: ffffff80048f8800
x19: ffffffc0130eb970 x18: ffffffc0130e5098
x17: 0000000000000001 x16: ffffff8003d18000
x15: ffffffc012f86000 x14: ffffffc0125e6ce8
x13: 00000000ffffffff x12: ffffffc0129b8d68
x11: 0000000100000003 x10: 00000000ffffffff
x9 : 0000000000000000 x8 : ffffffc0dcdb3000
x7 : ffffffc010640fc0 x6 : ffffff8003d18990
x5 : 0000000000000000 x4 : 0000000000000001
x3 : e358acf3a5519911 x2 : 0000000000000001
x1 : ffffffc01246bf58 x0 : 0000000000000000
Call trace:
 snd_soc_find_dai+0x120/0x128
 rockchip_mdais_probe+0x1cc/0x730
 platform_drv_probe+0x9c/0xc4
 really_probe+0x20c/0x51c
 driver_probe_device+0x80/0xc0
 device_driver_attach+0x7c/0xc0
 __driver_attach+0xcc/0x158
 bus_for_each_dev+0x80/0xd0
 driver_attach+0x28/0x38
 bus_add_driver+0x108/0x1e8
 driver_register+0x7c/0x118
 __platform_driver_register+0x48/0x58
 rockchip_mdais_driver_init+0x20/0x30
 do_one_initcall+0x9c/0x190
 do_initcall_level+0xa4/0xc8
 do_initcalls+0x58/0x9c
 do_basic_setup+0x28/0x38
 kernel_init_freeable+0x9c/0xf8
 kernel_init+0x18/0x190
 ret_from_fork+0x10/0x30

Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Change-Id: I16b9642fc1022389e099de0fb98b31201eafe0a1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants