On Sat, Aug 27, 2016 at 07:45:57AM -0700, Roy Yang wrote: > Hi Ted, > Thank you very much for reply. > The stack trace of the process is killed is: Hmm, are you sure this is the only process that got oom-killed? What I was expecting was a process with a stack trace that showed it was in the middle of ext4 or jbd2 code at the time when it tried to do a memory allocation and this either caused an OOM kill, or an EXT4-fs error report when a memory allocation failed. > We adjust the memory limit and avoid this process is killed. Now the > problem goes away. If possible, we still want to understand why Ext4 > is stuck in this case. What is probably happening is that a memory allocation failed in the middle of an ext4 operation, and it was holding jbd2 handle at the time of the failure. The error handling path didn't release the handle, and so the next time the jbd2 subsystem tried to do a transaction commit, it waited for all of the handles to complete, and since there was a handle leak due to the allocation failure / OOM kill, it caused the jbd2 commit code to wait forever. If that was the only process that got OOM killed, were there any ext4 error or warning messages before the OOM kill, or maybe slightly after it? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
