Comment 2 for bug 1389787

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote : Re: 3.11 memory consumption leads to HANG (not sure if 3.13 suffers from this).

For the other back trace (the one I have the core and can use crash tool):
* I'm still analysing this...

PID: 4453 TASK: ffff8800362dddc0 CPU: 16 COMMAND: "git"
#0 [ffff880092791a60] machine_kexec at ffffffff8104b141
#1 [ffff880092791ad0] crash_kexec at ffffffff810d5a58
#2 [ffff880092791ba0] oops_end at ffffffff81748b38
#3 [ffff880092791bd0] no_context at ffffffff8172dd02
#4 [ffff880092791c20] __bad_area_nosemaphore at ffffffff8172dee4
#5 [ffff880092791c80] bad_area_nosemaphore at ffffffff8172df16
#6 [ffff880092791c90] __do_page_fault at ffffffff8174bc12
#7 [ffff880092791da0] do_page_fault at ffffffff8174bde7
#8 [ffff880092791dd0] page_fault at ffffffff81747e98
[exception RIP: kmem_cache_alloc+102]
RIP: ffffffff8119c316 RSP: ffff880092791e88 RFLAGS: 00010286
RAX: 0000000000000000 RBX: ffffffffffffffea RCX: 00000000260000be
RDX: 00000000260000bd RSI: 00000000000000d0 RDI: 00000000000173c0
RBP: ffff880092791ed8 R8: ffff880c0bb173c0 R9: 0000000000001165
R10: 00007f2e4ac88dcc R11: 0000000000000246 R12: ffff880c0b403800
R13: ffff880ce78ccc00 R14: ffffffff8108f636 R15: 00000000000000d0
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#9 [ffff880092791ee0] prepare_creds at ffffffff8108f636
#10 [ffff880092791f00] sys_faccessat at ffffffff811b22b4
#11 [ffff880092791f70] sys_access at ffffffff811b24b8
#12 [ffff880092791f80] system_call_fastpath at ffffffff8175099d
RIP: 00007f2e4d883097 RSP: 00007f2e4ac87c88 RFLAGS: 00000206
RAX: 0000000000000015 RBX: ffffffff8175099d RCX: ffffffffffffffff
RDX: 00000000007bde07 RSI: 0000000000000000 RDI: 00000000007bdd80
RBP: 0000000000000001 R8: 0000000000000066 R9: 0000000000001165
R10: 00007f2e4ac88dcc R11: 0000000000000246 R12: ffffffff811b24b8
R13: ffff880092791f78 R14: 0000000000000002 R15: 0000000000000000
ORIG_RAX: 0000000000000015 CS: 0033 SS: 002b

We can see that ... system call access (which calls sys_faccessat) was called by user mode (CS: 0033) to check wether this process has permission to handle the given file:

FD FILE DENTRY INODE TYPE PATH
3 ffff880be925be00 ffff88076dd34b40 ffff88082a8434b0 REG /home001/jeongku.choi/8994_recent/.repo/project-objects/LG_apps/android/vendor/lge/apps/LGSettings.git/objects/pack/tmp_p

You can check that the file descriptor ffff880be925be00 is present into frame #10 (because it is an argument to the system call and was pushed into stack):

#10 [ffff880092791f00] sys_faccessat at ffffffff811b22b4
ffff880092791f08: 0000000000000001 00007f2e30001050
ffff880092791f18: ffff880be925be00 0000000000000000
ffff880092791f28: ffff880092791f78 ffffffff811b46b6
ffff880092791f38: 00007f2e4ac87d00 00007f2e4cce9590
ffff880092791f48: 00007f2e4cce9590 0000000000000457
ffff880092791f58: 0000000000000000 0000000000000002
ffff880092791f68: ffff880092791f78 ffffffff811b24b8

To check this file's permission... continuing on the backtrace... (next comment)