正確には何が問題なのかはわかりませんが、それを解決するための正しい方向性を見つけようとします.
ENOBUFS コードは sk_alloc() のいずれかの場合に返されます または dst_alloc() 失敗しました。 ENOBUFS の他の出現を見つけることができません ソケットに関連するソース コード内。
また、 SYSCALL_DEFINE3(connect) からのパスが見つかりません sk_alloc()まで 、そして connect() の間はソケットを割り当てるべきではないと思います エラーが発生した場所を呼び出すので、 sk_alloc() である可能性は低いと思います 問題を引き起こしました。
dst_alloc() connect() でルートを確認するために使用される可能性があります。 、それへの正確なパスが見つかりません。 SYSCALL_DEFINE3(connect) 内のどこかにあるはずです -> .connect() -> ip4_datagram_connect() -> ip_route_connect()
dst_alloc() 対応する SLAB キャッシュにエントリを割り当てます。キャッシュがいっぱいの場合、実際には失敗する可能性があります。その場合、実際には古いエントリを削除する必要がありますが、それでもエラーが返される場合があります。
この方向に進むことができると思います。dst キャッシュ サイズは /proc/sys/net/ipv4/route/max_size まで変更される可能性があります。 .まず、設定 (または sys.net.ipv4.route の他の設定) を確認します。 ) は、「Google で表示されるランダムな TCP 微調整」によって変更されます。
3.6 より前のカーネルでは、net.ipv4.route.max_size または net.ipv6.route.max_size の制限が不足すると、通常の IPv4/v6 トラフィックの ENOBUFS にヒットする可能性がありました。
カーネル 3.6 以降では、ルーティング キャッシュが削除され、net.ipv4.route.max_size は dst エントリの量への影響を失いました。したがって、一般的に、それはもはや不可能です。
ただし、IPSec を使用している場合でも、私のようにこのエラーが発生する可能性があります。一定量の IPSec トンネルを作成した後、リモート ホストに ping を実行できませんでした:
# ping 10.100.0.1
connect: No buffer space available
iputils からの ping は、テスト ファイル記述子を作成し、それに対して connect() を使用して、dst ip をバインドします。これが発生すると、指定された AF の dst キャッシュ エントリがカーネルによって作成され、私の場合、xfrm4 dst キャッシュ エントリの制限は既に使い果たされています。この制限は、sysctl 設定によって制御されます:
xfrm4_gc_thresh - INTEGER
The threshold at which we will start garbage collecting for IPv4
destination cache entries. At twice this value the system will
refuse new allocations.
私はカーネル 3.10.59 を使用してこれに遭遇しました。デフォルトの制限は非常に低く、1024 です。カーネル 3.10.83 から、この制限は 32768 に増加し、ヒットするのがはるかに難しくなります。
だから、私は発行しました：
# sysctl net.ipv4.xfrm4_gc_thresh=32768
IPSec を使用する場合のカーネル内のおおよそのパス:
ip4_datagram_connect() -> ip_route_connect() -> ip_route_output_flow() ->
xfrm_lookup() -> xfrm_resolve_and_create_bundle() ->
... -> xfrm_alloc_dst() -> dst_alloc() with xfrm4_dst_ops, where gc is set.