dmesg カーネル警告メッセージの理解

dmesg カーネル警告メッセージの理解

カーネルモジュールをデバッグしようとしています。実行すると、次のカーネル警告が表示されますが、私が見た他の警告のような情報メッセージはないようです。これから役に立つ情報を入手できますか?


追加情報:

このモジュールはfirewalltcpパケットをユーザー空間のプロキシサーバーに送信し、プロキシは受信したtcpデータを意図した宛先に送信します。

これは、単に1つのソケットからすべてのデータを受け取り、別のソケットでsendallを呼び出してhttp応答が処理されるときに発生します。すべての応答が 1 つのパケットにある場合は警告は発生しませんが、http ペイロード データが複数の tcp パケットにフラグメント化されると警告が発生します。

エージェントはPythonで書かれています。私が奇妙だと思うのは、警告に「python tainted」と書かれていることです。ユーザー空間アプリケーションによってカーネル警告が発生する可能性がありますか?


プロキシから大容量ファイルを受信しようとしましたが、送信していないがエラーが発生せず、システムがいつでも停止しませんでした。問題は、ソケット.sendall/socket.sendを呼び出すときにのみ発生します。

読み込みバッファのサイズを減らしてから、より小さなチャンクを送信すると、システムがより速くロックされます。

gso、をすべてオフにするとエラーメッセージは表示されませんが、tso同じethtool時間が経過してもシステムがまだロックされるため、警告がロックに関連しているかどうか疑問に思います。

[16795.153478] ------------[ cut here ]------------
[16795.153489] WARNING: at /build/buildd/linux-3.2.0/net/core/dev.c:1970 skb_gso_segment+0x2e9/0x360()
[16795.153492] Hardware name: VirtualBox
[16795.153495] e1000: caps=(0x40014b89, 0x401b4b89) len=2948 data_len=0 ip_summed=0
[16795.153497] Modules linked in: firewall(O) vesafb vboxsf(O) snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device joydev psmouse snd soundcore serio_raw i2c_piix4 snd_page_alloc vboxguest(O) video bnep mac_hid rfcomm bluetooth parport_pc ppdev lp parport usbhid hid e1000 [last unloaded: firewall]
[16795.153529] Pid: 7644, comm: python Tainted: G        W  O 3.2.0-37-generic-pae #58-Ubuntu
[16795.153532] Call Trace:
[16795.153540]  [<c105a822>] warn_slowpath_common+0x72/0xa0
[16795.153544]  [<c14ad2b9>] ? skb_gso_segment+0x2e9/0x360
[16795.153548]  [<c14ad2b9>] ? skb_gso_segment+0x2e9/0x360
[16795.153551]  [<c105a8f3>] warn_slowpath_fmt+0x33/0x40
[16795.153555]  [<c14ad2b9>] skb_gso_segment+0x2e9/0x360
[16795.153561]  [<c14b01ce>] dev_hard_start_xmit+0xae/0x4c0
[16795.153568]  [<f9a6f2fd>] ? divertPacket+0x7d/0xe0 [firewall]
[16795.153574]  [<c14c8151>] sch_direct_xmit+0xb1/0x180
[16795.153578]  [<f9a6f941>] ? hook_localout+0x71/0xe0 [firewall]
[16795.153582]  [<c14b06d6>] dev_queue_xmit+0xf6/0x370
[16795.153586]  [<c14c6459>] ? eth_header+0x29/0xc0
[16795.153590]  [<c14b73f0>] neigh_resolve_output+0x100/0x1c0
[16795.153594]  [<c14c6430>] ? eth_rebuild_header+0x80/0x80
[16795.153598]  [<c14dec62>] ip_finish_output+0x152/0x2e0
[16795.153602]  [<c14df75f>] ip_output+0xaf/0xc0
[16795.153605]  [<c14dd340>] ? ip_forward_options+0x1d0/0x1d0
[16795.153609]  [<c14deec0>] ip_local_out+0x20/0x30
[16795.153612]  [<c14defee>] ip_queue_xmit+0x11e/0x3c0
[16795.153617]  [<c10841c5>] ? getnstimeofday+0x55/0x120
[16795.153622]  [<c14f4de7>] tcp_transmit_skb+0x2d7/0x4a0
[16795.153626]  [<c14f5786>] tcp_write_xmit+0x146/0x3a0
[16795.153630]  [<c14f5a4c>] __tcp_push_pending_frames+0x2c/0x90
[16795.153634]  [<c14e7d2b>] tcp_sendmsg+0x71b/0xae0
[16795.153638]  [<c104a33d>] ? update_curr+0x1ed/0x360
[16795.153642]  [<c1509c23>] ? inet_recvmsg+0x73/0x90
[16795.153646]  [<c1509ca0>] inet_sendmsg+0x60/0xa0
[16795.153650]  [<c149ae27>] sock_sendmsg+0xf7/0x120
[16795.153655]  [<c1044648>] ? ttwu_do_wakeup+0x28/0x130
[16795.153660]  [<c1036a98>] ? default_spin_lock_flags+0x8/0x10
[16795.153667]  [<c149ce7e>] sys_sendto+0x10e/0x150
[16795.153672]  [<c1117e7f>] ? handle_pte_fault+0x28f/0x2c0
[16795.153675]  [<c111809e>] ? handle_mm_fault+0x15e/0x2c0
[16795.153679]  [<c15ab9c7>] ? do_page_fault+0x227/0x490
[16795.153681]  [<c149cefb>] sys_send+0x3b/0x40
[16795.153684]  [<c149d842>] sys_socketcall+0x162/0x2c0
[16795.153687]  [<c15af55f>] sysenter_do_call+0x12/0x28
[16795.153689] ---[ end trace 3170256120cbbc8f ]---

答え1

スタックトレースの終わりから逆追跡してみましたかaddr2line

たとえば、最後の行を表示します。sysenter_do_call+0x12/0x28

0x12オフセットは、長さは次のとおりです。0x28

$ addr2line -e [path-to-kernel-module-with-issue] 0xc15af55f

ちょっと...gdbはスタックトレースを複数行に分割するもう1つのオプションです。

しかし、あなたが提供したログの抜粋で私が見たのは警告だけなので、カーネルパニックがどのように発生したのか完全にはわかりません。スタックトレースを公開した後にクラッシュ/カーネルパニックメッセージが発生しますか?

--------スタックトレースが公開されている限り:これは通常の分割オフロードに関連しており、skbufferはip_summedチェックサムを満たしていないため、ラージ\一般受信機のオフロードは無効になります。

$ethtool -k [NIC] lro off $ethtool -k [NIC] gro off

考えられる解決策になることができます。また、skb->ip_summed = CHECKSUM_UNNECESSARY設定の目的に応じてチェックサムの確認をスキップしても、この問題は解決される可能性があります。

関連情報