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

lib: rename arch/sim to arch/lib #25

Merged
merged 1 commit into from
Dec 4, 2014
Merged

lib: rename arch/sim to arch/lib #25

merged 1 commit into from
Dec 4, 2014

Conversation

thehajime
Copy link
Member

nuse: clean up userspace build and kernelspace build
lib: change the name CONFIG_SIM to CONFIG_LIB

files sim_.[c] indicate to relate to simulator via Direct Code Execution (DCE),
files nuse_.[ch] indicate to relate to Network Stack in Userspace (NUSE).

libsim-linux_.so and libnuse-linux_.so will be generated for both purpose.
code are internally shared.

functions, variables are replaced from 'sim_' to 'lib_'
struct name weren't replaced because ns-3 (DCE) uses this name.

lib: add documentation

This commit addresses the issue #22 and #21.

nuse: clean up userspace build and kernelspace build
lib: change the name CONFIG_SIM to CONFIG_LIB

files sim*.[c] indicate to relate to simulator via Direct Code Execution (DCE),
files nuse*.[ch] indicate to relate to Network Stack in Userspace (NUSE).

libsim-linux*.so and libnuse-linux*.so will be generated for both purpose.
code are internally shared.

functions, variables are replaced from 'sim_' to 'lib_'
struct name weren't replaced because ns-3 (DCE) uses this name.

lib: add documentation
@thehajime
Copy link
Member Author

there are some suspicious messages, but test passed so it should be fine ;)
https://travis-ci.org/libos-nuse/net-next-nuse/builds/42940128

./include/linux/rcupdate.h:373:2: error: #error "Unknown RCU implementation specified to kernel configuration"
./include/linux/jiffies.h:39:3: error: #error Invalid value of HZ.
./include/linux/jiffies.h:60:39: error: division by zero in #if
./include/linux/rcupdate.h:373:2: error: #error "Unknown RCU implementation specified to kernel configuration"
./include/linux/jiffies.h:39:3: error: #error Invalid value of HZ.
./include/linux/jiffies.h:60:39: error: division by zero in #if
./include/linux/jiffies.h:60:39: error: division by zero in #if

thehajime added a commit that referenced this pull request Dec 4, 2014
lib: rename arch/sim to arch/lib
@thehajime thehajime merged commit 0c5b428 into nuse Dec 4, 2014
@thehajime thehajime deleted the arch-lib branch December 4, 2014 03:01
thehajime pushed a commit that referenced this pull request May 10, 2015
The slock spinlock in the cx23885_dev struct is only initialised if analogue
video is being used, but is used in other places too, leading to the attached
lockdep complaint.

Move the lock initialisation so that it is done unconditionally.

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 4413 Comm: scandvb Tainted: G        W       4.0.0-rc1-fsdevel+ #25
Hardware name: System manufacturer System Product Name/P5Q PRO TURBO, BIOS 0701    10/08/2012
 0000000000000000 ffff880129d779d8 ffffffff8162bbdf 0000000000000006
 0000000000000000 ffff880129d77aa8 ffffffff810780e3 0000000000000001
 0000000000000046 0000000000000004 ffffffff81c3f180 0000000000000000
Call Trace:
 [<ffffffff8162bbdf>] dump_stack+0x4c/0x65
 [<ffffffff810780e3>] __lock_acquire+0x7b5/0x1a0e
 [<ffffffff810799ee>] lock_acquire+0x97/0x10c
 [<ffffffffa006494e>] ? cx23885_buf_queue+0x69/0x142 [cx23885]
 [<ffffffff8102e9bc>] ? amd_set_subcaches+0x19b/0x19b
 [<ffffffff816313b4>] _raw_spin_lock_irqsave+0x36/0x4a
 [<ffffffffa006494e>] ? cx23885_buf_queue+0x69/0x142 [cx23885]
 [<ffffffffa006494e>] cx23885_buf_queue+0x69/0x142 [cx23885]
 [<ffffffffa00662cb>] buffer_queue+0x17/0x19 [cx23885]
 [<ffffffffa00382d5>] __enqueue_in_driver+0x6a/0x6f [videobuf2_core]
 [<ffffffffa0038ead>] vb2_start_streaming+0x37/0x129 [videobuf2_core]
 [<ffffffffa003a6c0>] vb2_internal_streamon+0xc5/0x105 [videobuf2_core]
 [<ffffffffa003b889>] __vb2_init_fileio+0x224/0x286 [videobuf2_core]
 [<ffffffffa003bcc0>] ? vb2_thread_start+0x7b/0x15f [videobuf2_core]
 [<ffffffffa0050182>] ? vb2_dvb_start_feed+0x86/0x86 [videobuf2_dvb]
 [<ffffffffa003bd06>] vb2_thread_start+0xc1/0x15f [videobuf2_core]
 [<ffffffff8150d393>] ? dmx_section_feed_start_filtering+0x2f/0x14f
 [<ffffffffa0050157>] vb2_dvb_start_feed+0x5b/0x86 [videobuf2_dvb]
 [<ffffffff8150d461>] dmx_section_feed_start_filtering+0xfd/0x14f
 [<ffffffff8150afc7>] dvb_dmxdev_filter_start+0x23f/0x315
 [<ffffffff8150b6ad>] dvb_demux_do_ioctl+0x1fb/0x556
 [<ffffffff81509e94>] dvb_usercopy+0xb4/0x11c
 [<ffffffff8150b4b2>] ? dvb_dmxdev_ts_callback+0xd0/0xd0
 [<ffffffff8150a11a>] dvb_demux_ioctl+0x10/0x14
 [<ffffffff81144ac4>] do_vfs_ioctl+0x3c1/0x474
 [<ffffffff8126f181>] ? file_has_perm+0x5b/0x7f
 [<ffffffff810bf6ca>] ? __audit_syscall_entry+0xbc/0xde
 [<ffffffff81144bcc>] SyS_ioctl+0x55/0x7a
 [<ffffffff81631d52>] system_call_fastpath+0x12/0x17

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
thehajime pushed a commit that referenced this pull request Aug 14, 2015
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
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #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.

Cc: stable@vger.kernel.org # 3.9+
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
thehajime pushed a commit that referenced this pull request Feb 2, 2016
Intel Tangier SoC is known to have 64-bit dual core CPU. Enable
64-bit build for it.

The kernel has been tested on Intel Edison board:

	Linux buildroot 4.4.0-next-20160115+ #25 SMP Fri Jan 15 22:03:19 EET 2016 x86_64 GNU/Linux

	processor       : 0
	vendor_id       : GenuineIntel
	cpu family      : 6
	model           : 74
	model name      : Genuine Intel(R) CPU   4000  @  500MHz
	stepping        : 8

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1452888668-147116-1-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
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.

None yet

1 participant