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?
