On 2022/07/14 23:18, Jan Kara wrote: > Hello, > > so this lockdep report looks real but is more related to OOM handling than > to ext4 as such. The immediate problem I can see is that > mem_cgroup_print_oom_meminfo() which is called under oom_lock calls > memory_stat_format() which does GFP_KERNEL allocations to allocate buffers > for dumping of MM statistics. This creates oom_lock -> fs reclaim > dependency and because OOM can be hit (and thus oom_lock acquired) in > practically any allocation (regardless of GFP_NOFS) this has a potential of > creating real deadlock cycles. > > So should mem_cgroup_print_oom_meminfo() be using > memalloc_nofs_save/restore() to avoid such deadlocks? Or perhaps someone > sees another solution? Generally allocating memory to report OOM looks a > bit dangerous to me ;). > > Honza I think mem_cgroup_print_oom_meminfo() should use GFP_ATOMIC, for it will fall into infinite loop if kmalloc(GFP_NOFS) under oom_lock reached __alloc_pages_may_oom() path.
