diff options
author | Jakub Kicinski <kuba@kernel.org> | 2024-03-26 21:02:12 -0700 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2024-03-28 18:30:40 -0700 |
commit | 6e9b01909a811555ff3326cf80a5847169c57806 (patch) | |
tree | 56d515b6f50fae8cee8b8f394ad9482dff3f2745 /scripts | |
parent | 49d665b8535e5ea5927b896086dcb2eb65514341 (diff) | |
download | linux-stable-6e9b01909a811555ff3326cf80a5847169c57806.tar.gz linux-stable-6e9b01909a811555ff3326cf80a5847169c57806.tar.bz2 linux-stable-6e9b01909a811555ff3326cf80a5847169c57806.zip |
net: remove gfp_mask from napi_alloc_skb()
__napi_alloc_skb() is napi_alloc_skb() with the added flexibility
of choosing gfp_mask. This is a NAPI function, so GFP_ATOMIC is
implied. The only practical choice the caller has is whether to
set __GFP_NOWARN. But that's a false choice, too, allocation failures
in atomic context will happen, and printing warnings in logs,
effectively for a packet drop, is both too much and very likely
non-actionable.
This leads me to a conclusion that most uses of napi_alloc_skb()
are simply misguided, and should use __GFP_NOWARN in the first
place. We also have a "standard" way of reporting allocation
failures via the queue stat API (qstats::rx-alloc-fail).
The direct motivation for this patch is that one of the drivers
used at Meta calls napi_alloc_skb() (so prior to this patch without
__GFP_NOWARN), and the resulting OOM warning is the top networking
warning in our fleet.
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240327040213.3153864-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions