Messages in this thread | | | Subject | Re: Problem in pfmemalloc skb handling in net/core/dev.c | From | Eric Dumazet <> | Date | Fri, 9 Apr 2021 12:04:11 +0200 |
| |
On 4/9/21 11:14 AM, Xie He wrote: > On Fri, Apr 9, 2021 at 1:44 AM Mel Gorman <mgorman@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? >
Note that pfmemalloc skbs are normally dropped in sk_filter_trim_cap()
Simply make sure your protocol use it.
| |