On Thu 10-10-19 17:16:29, Sergey Senozhatsky wrote: > On (10/10/19 09:40), Michal Hocko wrote: > [..] > > > > Considering that console.write is called from essentially arbitrary code > > > > path IIUC then all the locks used in this path should be pretty much > > > > tail locks or console internal ones without external dependencies. > > > > > > That's a good expectation, but I guess it's not always the case. > > > > > > One example might be NET console - net subsystem locks, net device > > > drivers locks, maybe even some MM locks (skb allocations?). > > > > I am not familiar with the netconsole code TBH. If there is absolutely > > no way around that then we might have to bite a bullet and consider some > > of MM locks a land of no printk. > > So this is what netconsole does (before we pass on udp to net device > driver code, which *may be* can do more allocations, I don't know): > > write_msg() > netpoll_send_udp() > find_skb() > alloc_skb(len, GFP_ATOMIC) > kmem_cache_alloc_node() > > You are the right person to ask this question to - how many MM > locks are involved when we do GFP_ATOMIC kmem_cache allocation? > Is there anything to be concerned about? At least zone->lock might involved. Maybe even more. -- Michal Hocko SUSE Labs
