On Fri 12-06-20 15:13:22, Naresh Kamboju wrote:
On Thu, 11 Jun 2020 at 15:25, Michal Hocko mhocko@kernel.org wrote:
On Fri 29-05-20 11:49:20, Michal Hocko wrote:
On Fri 29-05-20 02:56:44, Chris Down wrote:
Yafang Shao writes:
Agreed. Even if e{low,min} might still have some rough edges I am completely puzzled how we could end up oom if none of the protection path triggers which the additional debugging should confirm. Maybe my debugging patch is incomplete or used incorrectly (maybe it would be esier to use printk rather than trace_printk?).
It would be really great if we could move forward. While the fix (which has been dropped from mmotm) is not super urgent I would really like to understand how it could hit the observed behavior. Can we double check that the debugging patch really doesn't trigger (e.g. s@trace_printk@printk in the first step)?
Please suggest to me the way to get more debug information by providing kernel debug patches and extra kernel configs.
I have applied your debug patch and tested on top on linux next 20200612 but did not find any printk output while running mkfs -t ext4 /drive test case.
Have you tried s@trace_printk@printk@ in the patch? AFAIK trace_printk doesn't dump anything into the printk ring buffer. You would have to look into trace ring buffer.