rsweerarathna
commented
7 years ago Hi, I'm also getting this error continuously on console, and occasional kernel panics as well. I'm running several rules with 10-20Mbps traffic. I think the error printed for every packet which matches the iptables rule.
Can anyone tell me the reason for this and how this can be fixed, as i hope to handle several Gbps traffic with ndpi-netfilter ?
[17776.424497] BUG: scheduling while atomic: swapper/0/0/0x10000500
[17776.424662] Modules linked in: cls_u32 sch_sfq sch_htb xt_mac xt_ndpi(OE) iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter nfnetlink_queue nfnetlink_log nfnetlink bluetooth rfkill snd_seq_midi snd_seq_midi_event intel_powerclamp coretemp iosf_mbi crc32_pclmul snd_ens1371 ghash_clmulni_intel aesni_intel lrw gf128mul snd_rawmidi glue_helper snd_ac97_codec ablk_helper ac97_bus cryptd snd_seq ppdev snd_seq_device snd_pcm snd_timer snd soundcore sg vmw_balloon pcspkr vmxnet3 parport_pc parport shpchp vmw_vmci i2c_piix4 ip_tables xfs libcrc32c sr_mod cdrom ata_generic pata_acpi sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel vmwgfx serio_raw drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_piix
[17776.424689] ahci libahci drm vmw_pvscsi e1000 i2c_core libata floppy fjes
[17776.424695] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W OE ------------ 3.10.0-514.16.1.el7.x86_64 #1
[17776.424699] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/14/2014
[17776.424702] 0000000000000000 b8b5cd03e0bc9318 ffff88007c6033e8 ffffffff81686ac3
[17776.424706] ffff88007c6033f8 ffffffff81680761 ffff88007c603458 ffffffff8168c04e
[17776.424709] ffffffff819c1460 ffffffff819affd8 ffffffff819affd8 ffffffff819affd8
[17776.424713] Call Trace:
[17776.424716]
Under Scientific Linux 6.8 I'm getting "scheduling while atomic" errors and occasional kernel panics. At the moment, ndpi_malloc() calls kmalloc(size, GFP_KERNEL) - presumably changing GFP_KERNEL to GFP_ATOMIC would fix this problem, but I'm not sure if that's a good idea since ndpi_malloc() is probably called from non-atomic parts of code too?
:Pid: 0, comm: swapper Not tainted 2.6.32-642.3.1.el6.x86_64 #1 :Call Trace: : [] ? schedule_bug+0x44/0x50
:[] ? schedule+0xa4c/0xb70
:[] ? pvclock_clocksource_read+0x58/0xd0
:[] ? sched_clock_local+0x25/0x90
:[] ? ndpi_malloc+0x2a/0x30 [xt_ndpi]
:[] ? __cond_resched+0x2a/0x40
:[] ? _cond_resched+0x30/0x40
:[] ? kmalloc+0x138/0x230
:[] ? ndpi_malloc+0x2a/0x30 [xt_ndpi]
:[] ? check_content_type_and_change_protocol+0x5ea/0x920 [xt_ndpi]
:[] ? _read_unlock_bh+0x15/0x20
:[] ? xfrm_policy_lookup_bytype+0x131/0x240
:[] ? mod_timer_pending+0x126/0x200
:[] ? mod_timer+0x144/0x220
:[] ? ndpi_parse_packet_line_info+0x5fe/0x7e0 [xt_ndpi]
:[] ? ndpi_search_http_tcp+0xbf/0x3f0 [xt_ndpi]
:[] ? check_ndpi_tcp_flow_func+0x22d/0x740 [xt_ndpi]
:[] ? dev_hard_start_xmit+0x21c/0x490
:[] ? sch_direct_xmit+0x78/0x1c0
:[] ? pvclock_clocksource_read+0x58/0xd0
:[] ? check_ndpi_flow_func+0x18/0x40 [xt_ndpi]
:[] ? ndpi_detection_process_packet+0x2fa/0x4c0 [xt_ndpi]
:[] ? kmem_cache_alloc+0x18a/0x190
:[] ? ndpi_mt+0x263/0x880 [xt_ndpi]
:[] ? ipt_do_table+0x34a/0x678 [ip_tables]
:[] ? ipt_hook+0x23/0x30 [iptable_filter]
:[] ? nf_iterate+0x69/0xb0
:[] ? ip_forward_finish+0x0/0x60
:[] ? nf_hook_slow+0x76/0x120
:[] ? ip_forward_finish+0x0/0x60
:[] ? sch_direct_xmit+0x78/0x1c0
:[] ? ip_forward+0x2b3/0x460
:[] ? ip_rcv_finish+0x12d/0x440
:[] ? ip_rcv+0x275/0x350
:[] ? netif_receive_skb+0x201/0x590
:[] ? netif_receive_skb+0x58/0x60
:[] ? cp_rx_poll+0x3b8/0x4f0 [8139cp]
:[] ? swiotlb_map_page+0x0/0x100
:[] ? net_rx_action+0x103/0x300
:[] ? do_softirq+0xe5/0x230
:[] ? call_softirq+0x1c/0x30
:[] ? do_softirq+0x65/0xa0
:[] ? irq_exit+0x85/0x90
:[] ? do_IRQ+0x75/0xf0
:[] ? ret_from_intr+0x0/0x11
: [] ? native_safe_halt+0xb/0x10
:[] ? default_idle+0x4d/0xb0
:[] ? cpu_idle+0xb6/0x110
:[] ? start_secondary+0x2c0/0x316