On 2023/04/04 20:05, Michal Hocko wrote: > But you are right that GFP_ATOMIC allocations from IRQ context are quite > common so this is a more general situation that doesn't really need to > involve TTY and some locking oddities there. Yes, that's why "[PATCH] mm/page_alloc: don't check zonelist_update_seq from atomic allocations" was proposed; I consider that zonelist_update_seq should not be checked from atomic context. From lockdep perspective, keeping locking dependency simpler is the better, even if we go with printk_deferred_enter()/printk_deferred_exit() approach.