Thanks Ted, I will work with our team to reproduce this with upstream kernel. Will update you after we get this after next week. Best Regards Roy On Sat, Aug 27, 2016 at 12:02 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Sat, Aug 27, 2016 at 09:29:51AM -0700, Roy Yang wrote: >> Yes, that is the process which was killed by oom killer since it is >> exceeding 1.4GB memory. >> The full dmesg and also processes stuck at ext4 >> start_this_handle/wait_transaction_locked >> are attached. > > Yeah, unfortunately it's not helpful. My guess is that it's somewhere > in the call chain of page fault code calling ext4_page_mkwrite() where > we have a bad error handling path, but finding it will be a pain. > > Since you have a reliable repro, would you be willing to try and > reproduce the problem with the latest upstream kernel? If you can > reproduce it there, I'll promise to help you instrument the kernel so > we can track down the problem. > >> I also searched Redhat support portal, online resource. Similar issue >> was found but not sure whether >> upstream patch 2c869b262a10ca99cb866d04087d75311587a30c mentioned at >> https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-checkins/y6n90Mqop7A >> has addressed the problem. > > No, this patch fixes a problem with online resize, which has nothing > to do with what you are seeing. > > - 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
