This repository was archived by the owner on Aug 5, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 48
Fix for missing ./mfd_trace.h and ./trace.h #5
Open
celestialmachines
wants to merge
4
commits into
intel:wip-edison-3.19.5
Choose a base branch
from
celestialmachines:wip-edison-3.19.5
base: wip-edison-3.19.5
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Fix for missing ./mfd_trace.h and ./trace.h #5
celestialmachines
wants to merge
4
commits into
intel:wip-edison-3.19.5
from
celestialmachines:wip-edison-3.19.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
Fix include/trace/define_trace.h:83:43: fatal error: ./trace.h: No such file or directory
Revert Erroneous Patch include/trace/define_trace.h:83:43: fatal error: ./trace.h: No such file or directory
Fix the following error: In file included from drivers/tty/serial/mfd_trace.h:197:0, from drivers/tty/serial/mfd.h:251, from drivers/tty/serial/mfd_core.c:43: include/trace/define_trace.h:83:43: fatal error: ./mfd_trace.h: No such file or directory
Fixes the following error: In file included from drivers/usb/dwc3/trace.h:247:0, from drivers/usb/dwc3/trace.c:19, from drivers/usb/dwc3/dwc3-device-intel.c:36: include/trace/define_trace.h:83:43: fatal error: ./trace.h: No such file or directory
funman
pushed a commit
to SipRadius/edison-linux
that referenced
this pull request
Mar 10, 2016
commit ecf5fc6 upstream. Nikolay has reported a hang when a memcg reclaim got stuck with the following backtrace: PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync" #0 __schedule at ffffffff815ab152 #1 schedule at ffffffff815ab76e intel#2 schedule_timeout at ffffffff815ae5e5 intel#3 io_schedule_timeout at ffffffff815aad6a intel#4 bit_wait_io at ffffffff815abfc6 intel#5 __wait_on_bit at ffffffff815abda5 intel#6 wait_on_page_bit at ffffffff8111fd4f intel#7 shrink_page_list at ffffffff81135445 intel#8 shrink_inactive_list at ffffffff81135845 intel#9 shrink_lruvec at ffffffff81135ead intel#10 shrink_zone at ffffffff811360c3 intel#11 shrink_zones at ffffffff81136eff intel#12 do_try_to_free_pages at ffffffff8113712f intel#13 try_to_free_mem_cgroup_pages at ffffffff811372be intel#14 try_charge at ffffffff81189423 intel#15 mem_cgroup_try_charge at ffffffff8118c6f5 intel#16 __add_to_page_cache_locked at ffffffff8112137d intel#17 add_to_page_cache_lru at ffffffff81121618 intel#18 pagecache_get_page at ffffffff8112170b intel#19 grow_dev_page at ffffffff811c8297 intel#20 __getblk_slow at ffffffff811c91d6 intel#21 __getblk_gfp at ffffffff811c92c1 intel#22 ext4_ext_grow_indepth at ffffffff8124565c intel#23 ext4_ext_create_new_leaf at ffffffff81246ca8 intel#24 ext4_ext_insert_extent at ffffffff81246f09 intel#25 ext4_ext_map_blocks at ffffffff8124a848 intel#26 ext4_map_blocks at ffffffff8121a5b7 #27 mpage_map_one_extent at ffffffff8121b1fa #28 mpage_map_and_submit_extent at ffffffff8121f07b #29 ext4_writepages at ffffffff8121f6d5 #30 do_writepages at ffffffff8112c490 #31 __filemap_fdatawrite_range at ffffffff81120199 #32 filemap_flush at ffffffff8112041c #33 ext4_alloc_da_blocks at ffffffff81219da1 #34 ext4_rename at ffffffff81229b91 #35 ext4_rename2 at ffffffff81229e32 #36 vfs_rename at ffffffff811a08a5 #37 SYSC_renameat2 at ffffffff811a3ffc #38 sys_renameat2 at ffffffff811a408e #39 sys_rename at ffffffff8119e51e #40 system_call_fastpath at ffffffff815afa89 Dave Chinner has properly pointed out that this is a deadlock in the reclaim code because ext4 doesn't submit pages which are marked by PG_writeback right away. The heuristic was introduced by commit e62e384 ("memcg: prevent OOM with too many dirty pages") and it was applied only when may_enter_fs was specified. The code has been changed by c3b94f4 ("memcg: further prevent OOM with too many dirty pages") which has removed the __GFP_FS restriction with a reasoning that we do not get into the fs code. But this is not sufficient apparently because the fs doesn't necessarily submit pages marked PG_writeback for IO right away. ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily submit the bio. Instead it tries to map more pages into the bio and mpage_map_one_extent might trigger memcg charge which might end up waiting on a page which is marked PG_writeback but hasn't been submitted yet so we would end up waiting for something that never finishes. Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2) before we go to wait on the writeback. The page fault path, which is the only path that triggers memcg oom killer since 3.12, shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue which was originally addressed by the heuristic. As per David Chinner the xfs is doing similar thing since 2.6.15 already so ext4 is not the only affected filesystem. Moreover he notes: : For example: IO completion might require unwritten extent conversion : which executes filesystem transactions and GFP_NOFS allocations. The : writeback flag on the pages can not be cleared until unwritten : extent conversion completes. Hence memory reclaim cannot wait on : page writeback to complete in GFP_NOFS context because it is not : safe to do so, memcg reclaim or otherwise. [[email protected]: corrected the control flow] Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages") Reported-by: Nikolay Borisov <[email protected]> Signed-off-by: Michal Hocko <[email protected]> Signed-off-by: Hugh Dickins <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fix for missing ./mfd_trace.h ./trace.h that lead to compilation termination.