FIX: Broken path of mdss_mdp_trace.h#14
Open
imShara wants to merge 1 commit intoTheScarastic:lineage-15.0from
Open
FIX: Broken path of mdss_mdp_trace.h#14imShara wants to merge 1 commit intoTheScarastic:lineage-15.0from
imShara wants to merge 1 commit intoTheScarastic:lineage-15.0from
Conversation
Compilation error: ``` include/trace/define_trace.h:79:43: fatal error: ./mdss_mdp_trace.h: No such file or directory #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) ```
Contributor
|
Use a separate out dir |
xtrymind
pushed a commit
to xtrymind/android_kernel_xiaomi_msm8953
that referenced
this pull request
May 30, 2018
[ Upstream commit 2bbea6e ] when mounting an ISO filesystem sometimes (very rarely) the system hangs because of a race condition between two tasks. PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount" #0 [ffff880078447ae0] __schedule at ffffffff8168d605 TheScarastic#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49 TheScarastic#2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995 TheScarastic#3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef TheScarastic#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod] TheScarastic#5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50 TheScarastic#6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3 TheScarastic#7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs] #8 [ffff880078447da8] mount_bdev at ffffffff81202570 TheScarastic#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs] TheScarastic#10 [ffff880078447e28] mount_fs at ffffffff81202d09 TheScarastic#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f TheScarastic#12 [ffff880078447ea8] do_mount at ffffffff81220fee TheScarastic#13 [ffff880078447f28] sys_mount at ffffffff812218d6 TheScarastic#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49 RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246 RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010 RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30 RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010 R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040 R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30 ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b This task was trying to mount the cdrom. It allocated and configured a super_block struct and owned the write-lock for the super_block->s_umount rwsem. While exclusively owning the s_umount lock, it called sr_block_ioctl and waited to acquire the global sr_mutex lock. PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd" #0 [ffff880078417898] __schedule at ffffffff8168d605 TheScarastic#1 [ffff880078417900] schedule at ffffffff8168dc59 TheScarastic#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605 TheScarastic#3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838 TheScarastic#4 [ffff8800784179d0] down_read at ffffffff8168cde0 TheScarastic#5 [ffff8800784179e8] get_super at ffffffff81201cc7 TheScarastic#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de TheScarastic#7 [ffff880078417a40] flush_disk at ffffffff8123a94b #8 [ffff880078417a88] check_disk_change at ffffffff8123ab50 TheScarastic#9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom] TheScarastic#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod] TheScarastic#11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86 TheScarastic#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65 TheScarastic#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b TheScarastic#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7 TheScarastic#15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf TheScarastic#16 [ffff880078417d00] do_last at ffffffff8120d53d TheScarastic#17 [ffff880078417db0] path_openat at ffffffff8120e6b2 TheScarastic#18 [ffff880078417e48] do_filp_open at ffffffff8121082b TheScarastic#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33 TheScarastic#20 [ffff880078417f70] sys_open at ffffffff811fde4e TheScarastic#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49 RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246 RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000 RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70 RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020 R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010 ORIG_RAX: 0000000000000002 CS: 0033 SS: 002b This task tried to open the cdrom device, the sr_block_open function acquired the global sr_mutex lock. The call to check_disk_change() then saw an event flag indicating a possible media change and tried to flush any cached data for the device. As part of the flush, it tried to acquire the super_block->s_umount lock associated with the cdrom device. This was the same super_block as created and locked by the previous task. The first task acquires the s_umount lock and then the sr_mutex_lock; the second task acquires the sr_mutex_lock and then the s_umount lock. This patch fixes the issue by moving check_disk_change() out of cdrom_open() and let the caller take care of it. Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RahifM
pushed a commit
to RahifM/android_kernel_xiaomi_msm8953
that referenced
this pull request
Jan 16, 2020
commit cf3591e upstream. Revert the commit bd293d0. The proper fix has been made available with commit d0a255e ("loop: set PF_MEMALLOC_NOIO for the worker thread"). Note that the fix offered by commit bd293d0 doesn't really prevent the deadlock from occuring - if we look at the stacktrace reported by Junxiao Bi, we see that it hangs in bit_wait_io and not on the mutex - i.e. it has already successfully taken the mutex. Changing the mutex from mutex_lock to mutex_trylock won't help with deadlocks that happen afterwards. PID: 474 TASK: ffff8813e11f4600 CPU: 10 COMMAND: "kswapd0" #0 [ffff8813dedfb938] __schedule at ffffffff8173f405 #1 [ffff8813dedfb990] schedule at ffffffff8173fa27 #2 [ffff8813dedfb9b0] schedule_timeout at ffffffff81742fec TheScarastic#3 [ffff8813dedfba60] io_schedule_timeout at ffffffff8173f186 TheScarastic#4 [ffff8813dedfbaa0] bit_wait_io at ffffffff8174034f TheScarastic#5 [ffff8813dedfbac0] __wait_on_bit at ffffffff8173fec8 TheScarastic#6 [ffff8813dedfbb10] out_of_line_wait_on_bit at ffffffff8173ff81 TheScarastic#7 [ffff8813dedfbb90] __make_buffer_clean at ffffffffa038736f [dm_bufio] #8 [ffff8813dedfbbb0] __try_evict_buffer at ffffffffa0387bb8 [dm_bufio] TheScarastic#9 [ffff8813dedfbbd0] dm_bufio_shrink_scan at ffffffffa0387cc3 [dm_bufio] TheScarastic#10 [ffff8813dedfbc40] shrink_slab at ffffffff811a87ce TheScarastic#11 [ffff8813dedfbd30] shrink_zone at ffffffff811ad778 TheScarastic#12 [ffff8813dedfbdc0] kswapd at ffffffff811ae92f TheScarastic#13 [ffff8813dedfbec0] kthread at ffffffff810a8428 TheScarastic#14 [ffff8813dedfbf50] ret_from_fork at ffffffff81745242 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Fixes: bd293d0 ("dm bufio: fix deadlock with loop device") Depends-on: d0a255e ("loop: set PF_MEMALLOC_NOIO for the worker thread") Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I6cd6b254cca8cb8e72c197d44b91790c1a799554
RahifM
pushed a commit
to RahifM/android_kernel_xiaomi_msm8953
that referenced
this pull request
Jun 24, 2020
…nded commit 331dcf4 upstream. If the i2c device is already runtime suspended, if qup_i2c_suspend is executed during suspend-to-idle or suspend-to-ram it will result in the following splat: WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90 Modules linked in: CPU: 3 PID: 1593 Comm: bash Tainted: G W 4.8.0-rc3 TheScarastic#14 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) PC is at clk_core_unprepare+0x80/0x90 LR is at clk_unprepare+0x28/0x40 pc : [<ffff0000086eecf0>] lr : [<ffff0000086f0c58>] pstate: 60000145 Call trace: clk_core_unprepare+0x80/0x90 qup_i2c_disable_clocks+0x2c/0x68 qup_i2c_suspend+0x10/0x20 platform_pm_suspend+0x24/0x68 ... This patch fixes the issue by executing qup_i2c_pm_suspend_runtime conditionally in qup_i2c_suspend. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Change-Id: Idf53f82075dedbb8a9da9d4004ee0cdd26a23377
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Compilation error: