My test scenario is:
1.Set vmalloc to 400M
2. Load 5 game apps.(
com.imangi.templerun2-1.apk
com.imangi.templerun-1.apk
com.rovio.angrybirdsseasons-1.apk
com.rovio.angrybirdsrio-1.apk
com.ArtInGames.AirAttackHDLite-1.apk)
3. Start Youtube 3G Streaming
4. start 5 to 6 filedownloads from
http://www.thinkbroadband.com/download.html
Switch b/w steps 2 and 3 periodically.
Keep checking log file for lockdep warning. Also keep checking cat
/proc/meminfo. memfree should be b/w 7M to 15M. Issue is reproducible
within 30 minutes.
Regards
Shiva
On Thursday, 11 July 2013 18:34:17 UTC+5:30, 冯力 wrote:
>
> What's you test program? can you paste it out or send a copy to me?
> It's a deadlock which had been discused in linux-kernel mail list.
> I want to know the detail.But It's hard to reproduct.
>
> 在 2013年7月10日星期三UTC+8下午4时23分23秒，psh2001写道：
>>
>> Hi,
>>
>> I have been facing this possible deadlock lockdep warning under low
>> memory conditions.I am using kernel 3.4 version
>>
>>
>> <4>1[ 704.818328] 526 inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W}
>> usage.
>>
>> <4>1[ 704.825805] 526 kswapd0/526 [HC0[0]:SC0[0]:HE1:SE1] takes:
>>
>> <4>1[ 704.831909] 526 (&sb->s_type->i_mutex_key#4){+.+.?.}, at:
>> [<c00b6e58>] vmtruncate_range+0x7c/0xec
>>
>> <4>1[ 704.841491] 526 {RECLAIM_FS-ON-W} state was registered at:
>>
>> <4>1[ 704.847595] 526 [<c007ccb8>] mark_held_locks+0x60/0x120
>>
>> <4>1[ 704.853607] 526 [<c007d488>] lockdep_trace_alloc+0x88/0xf4
>>
>> <4>1[ 704.859863] 526 [<c00b1114>] __alloc_pages_nodemask+0x70/0x778
>>
>> <4>1[ 704.866485] 526 [<c00d61ec>] new_slab+0x68/0x220
>>
>> <4>1[ 704.871887] 526 [<c05a13a8>]
>> __slab_alloc.isra.51.constprop.55+0x4ac/0x56c
>>
>> <4>1[ 704.879547] 526 [<c00d71f4>] kmem_cache_alloc+0x10c/0x118
>>
>> <4>1[ 704.885711] 526 [<c00f2894>] __d_alloc+0x1c/0x154
>>
>> <4>1[ 704.891204] 526 [<c00f2c24>] d_alloc+0x10/0x60
>>
>> <4>1[ 704.896423] 526 [<c00e6714>] __lookup_hash+0xac/0xdc
>>
>> <1>0[ 704.901306] 3389 [1373374124.123] sndp : sndp_fsi_trigger():
>> PLAYBACK val[0x20] TRIGGER_STOP
>>
>> <4>1[ 704.911132] 526 [<c00e69a4>] do_lookup+0x260/0x2c4
>>
>> <4>1[ 704.916687] 526 [<c00e97ec>] do_last.isra.30+0x134/0x6bc
>>
>> <4>1[ 704.922790] 526 [<c00e9f74>] path_openat+0xb8/0x388
>>
>> <4>1[ 704.928436] 526 [<c00ea32c>] do_filp_open+0x2c/0x80
>>
>> <4>1[ 704.934112] 526 [<c00dac10>] do_sys_open+0xdc/0x174
>>
>> <4>1[ 704.939758] 526 [<c000ee80>] ret_fast_syscall+0x0/0x3c
>>
>> <4>1[ 704.945678] 526 irq event stamp: 1219094
>>
>> <4>1[ 704.950195] 526 hardirqs last enabled at (1219094): [<c05a4a08>]
>> mutex_trylock+0x184/0x1fc
>>
>> <4>1[ 704.959167] 526 hardirqs last disabled at (1219093): [<c05a48d0>]
>> mutex_trylock+0x4c/0x1fc
>>
>> <4>1[ 704.968017] 526 softirqs last enabled at (1215303): [<c00371c4>]
>> irq_exit+0xa0/0xa8
>>
>> <4>1[ 704.976379] 526 softirqs last disabled at (1215274): [<c00371c4>]
>> irq_exit+0xa0/0xa8
>>
>> <4>1[ 704.984741] 526
>>
>> <4>1[ 704.984741] 526 other info that might help us debug this:
>>
>> <4>1[ 704.993164] 526 Possible unsafe locking scenario:
>>
>> <4>1[ 704.993164] 526
>>
>> <4>1[ 705.000976] 526 CPU0
>>
>> <4>1[ 705.004364] 526 ----
>>
>> <4>1[ 705.007781] 526 lock(&sb->s_type->i_mutex_key#4);
>>
>> <4>1[ 705.013275] 526 <Interrupt>
>>
>> <4>1[ 705.016845] 526 lock(&sb->s_type->i_mutex_key#4);
>>
>> <4>1[ 705.022521] 526
>>
>> <4>1[ 705.022521] 526 *** DEADLOCK ***
>>
>> <4>1[ 705.022521] 526
>>
>> <4>1[ 705.031311] 526 2 locks held by kswapd0/526:
>>
>> <4>1[ 705.036163] 526 #0: (shrinker_rwsem){++++..}, at: [<c00b7450>]
>> shrink_slab+0x28/0x24c
>>
>> <4>1[ 705.044799] 526 #1: (ashmem_mutex){+.+.+.}, at: [<c03757ec>]
>> ashmem_shrink+0x30/0x12c
>>
>> <4>1[ 705.053466] 526 stack backtrace:
>>
>> <4>1[ 705.059722] 526 [<c001543c>] (unwind_backtrace+0x0/0xf8) from
>> [<c059feb0>] (print_usage_bug+0x250/0x2b8)
>>
>> <4>1[ 705.069824] 526 [<c059feb0>] (print_usage_bug+0x250/0x2b8) from
>> [<c007a584>] (mark_lock+0x530/0x66c)
>>
>> <4>1[ 705.079559] 526 [<c007a584>] (mark_lock+0x530/0x66c) from
>> [<c007abc4>] (__lock_acquire+0x504/0x1a28)
>>
>> <4>1[ 705.089263] 526 [<c007abc4>] (__lock_acquire+0x504/0x1a28) from
>> [<c007c58c>] (lock_acquire+0x60/0x74)
>>
>> <4>1[ 705.099090] 526 [<c007c58c>] (lock_acquire+0x60/0x74) from
>> [<c05a582c>] (mutex_lock_nested+0x6c/0x3f0)
>>
>> <4>1[ 705.109008] 526 [<c05a582c>] (mutex_lock_nested+0x6c/0x3f0) from
>> [<c00b6e58>] (vmtruncate_range+0x7c/0xec)
>>
>> <4>1[ 705.119262] 526 [<c00b6e58>] (vmtruncate_range+0x7c/0xec) from
>> [<c0375864>] (ashmem_shrink+0xa8/0x12c)
>>
>> <4>1[ 705.129150] 526 [<c0375864>] (ashmem_shrink+0xa8/0x12c) from
>> [<c00b75d8>] (shrink_slab+0x1b0/0x24c)
>>
>> <4>1[ 705.138793] 526 [<c00b75d8>] (shrink_slab+0x1b0/0x24c) from
>> [<c00b9800>] (kswapd+0x52c/0x9b4)
>>
>> <4>1[ 705.147918] 526 [<c00b9800>] (kswapd+0x52c/0x9b4) from [<c004df08>]
>> (kthread+0x84/0x90)
>>
>> <4>1[ 705.156524] 526 [<c004df08>] (kthread+0x84/0x90) from [<c000f9dc>]
>> (kernel_thread_exit+0x0/0x8)
>>
>>
>>
>> while removing vmtruncate_range usage in ashmem.c as part of this patch
>> (commit 3f31d07571eeea18a7d34db9af21d2285b807a17 ), author has suggested
>> using shmem_truncate_range directly but no patch is proposed or upstreamed
>> regarding this .
>>
>> Currently in my code, i still use vmtruncate_range() instead of
>> do_fallocate but still both these functions take mutex lock and hence issue
>> is still possible with using do_fallocate()
>>
>> I have tried using shmem_truncate_range() in ashmem_shrink, and i don't
>> see the lockdep warning anymore.
>>
>> but still i want the confirmation or any side effects of using
>> shmem_truncate_range directly if any.
>>
>>
>>
>> Thanks
>>
>> Shiva
>>
>>
>>
>>
>>
>
--
--
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel
---
You received this message because you are subscribed to the Google Groups
"Android Linux Kernel Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-kernel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
