On Fri, Apr 09, 2021 at 02:14:12AM -0700, Xie He wrote: > On Fri, Apr 9, 2021 at 1:44 AM Mel Gorman <mgor...@techsingularity.net> wrote: > > > > That would imply that the tap was communicating with a swap device to > > allocate a pfmemalloc skb which shouldn't happen. Furthermore, it would > > require the swap device to be deactivated while pfmemalloc skbs still > > existed. Have you encountered this problem? > > I'm not a user of swap devices or pfmemalloc skbs. I just want to make > sure the protocols that I'm developing (not IP or IPv6) won't get > pfmemalloc skbs when receiving, because those protocols cannot handle > them. > > According to the code, it seems always possible to get a pfmemalloc > skb when a network driver calls "__netdev_alloc_skb". The skb will > then be queued in per-CPU backlog queues when the driver calls > "netif_rx". There seems to be nothing preventing "sk_memalloc_socks()" > from becoming "false" after the skb is allocated and before it is > handled by "__netif_receive_skb". > > Do you mean that at the time "sk_memalloc_socks()" changes from "true" > to "false", there would be no in-flight skbs currently being received, > and all network communications have been paused?
Not all network communication, but communication with swap devices should have stopped once sk_memalloc_socks is false. -- Mel Gorman SUSE Labs
