November 2019 - kernelnewbies@kernelnewbies.org

[PATCH 0/1] syscalls: Fix references to filenames
by Mohammad Nasirifar Nov. 4, 2019

Nov. 4, 2019

Hi Everyone, I wanted to submit this for review but 'get_maintainers.pl' is not very helpful (I don't want to spam people/lists) and I couldn't find a similar "cleaning" commit against these files. Was wondering if you could help me with what I need to do/where I should send this. Thanks, Mohammad Mohammad Nasirifar (1): syscalls: Fix references to filenames containing syscall defs include/linux/syscalls.h | 8 ++++---- include/uapi/asm-generic/unistd.h | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) -- 2.23.0

1 0

gso packet is failing with af_packet socket with packet_vnet_hdr
by Ramana Reddy Nov. 3, 2019

Nov. 3, 2019

Hi, I am wondering if anyone can help me with this. I am having trouble to send tso/gso packet with af_packet socket with packet_vnet_hdr (through virtio_net_hdr) over vxlan tunnel in OVS. What I observed that, the following function eventually hitting and is returning false (net/core/skbuff.c), hence the packet is dropping. static inline bool skb_gso_size_check(const struct sk_buff *skb, unsigned int seg_len, unsigned int max_len) { const struct skb_shared_info *shinfo = skb_shinfo(skb); const struct sk_buff *iter; if (shinfo->gso_size != GSO_BY_FRAGS) return seg_len <= max_len; .......... } [ 678.756673] ip_finish_output_gso:235 packet_length:2762 (here packet_length = skb->len - skb_inner_network_offset(skb)) [ 678.756678] ip_fragment:510 packet length:1500 [ 678.756715] ip_fragment:510 packet length:1314 [ 678.956889] skb_gso_size_check:4474 and seg_len:1550 and max_len:1500 and shinfo->gso_size:1448 and GSO_BY_FRAGS:65535 Observation: When we send the large packet ( example here is packet_length:2762), its showing the seg_len(1550) > max_len(1500). Hence return seg_len <= max_len statement returning false. Because of this, ip_fragment calling icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); rather the code reaching to ip_finish_output2(sk, skb) function in net/ipv4/ip_output.c and is given below: static int ip_finish_output_gso(struct sock *sk, struct sk_buff *skb, unsigned int mtu) { netdev_features_t features; struct sk_buff *segs; int ret = 0; /* common case: seglen is <= mtu */ if (skb_gso_validate_mtu(skb, mtu)) return ip_finish_output2(sk, skb); ........... err = ip_fragment(sk, segs, mtu, ip_finish_output2); ........... } But when we send normal iperf traffic ( gso/tso traffic) over vxlan, the skb_gso_size_check returning a true value, and ip_finish_output2 getting executed. Here is the values of normal iperf traffic over vxlan. [ 1041.400537] skb_gso_size_check:4477 and seg_len:1500 and max_len:1500 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535 [ 1041.400587] skb_gso_size_check:4477 and seg_len:1450 and max_len:1450 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535 [ 1041.400594] skb_gso_size_check:4477 and seg_len:1500 and max_len:1500 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535 [ 1041.400732] skb_gso_size_check:4477 and seg_len:1450 and max_len:1450 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535 [ 1041.400741] skb_gso_size_check:4477 and seg_len:1450 and max_len:1450 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535 Can someone help me to solve what is missing, and where should I modify the code in OVS/ or outside of ovs, so that it works as expected. Thanks in advance. Some more info: [root@xx ~]# uname -r 3.10.0-1062.4.1.el7.x86_64 [root@xx ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.7 (Maipo) [root@xx]# ovs-vsctl --version ovs-vsctl (Open vSwitch) 2.9.0 DB Schema 7.15.1 And dump_stack output with af_packet: [ 4833.637460] <IRQ> [<ffffffff81979612>] dump_stack+0x19/0x1b [ 4833.637474] [<ffffffff8197c3ca>] ip_fragment.constprop.55+0xc3/0x141 [ 4833.637481] [<ffffffff8189dd84>] ip_finish_output+0x314/0x350 [ 4833.637484] [<ffffffff8189eb83>] ip_output+0xb3/0x130 [ 4833.637490] [<ffffffff8189da70>] ? ip_do_fragment+0x910/0x910 [ 4833.637493] [<ffffffff8189cac9>] ip_local_out_sk+0xf9/0x180 [ 4833.637497] [<ffffffff818e6f6c>] iptunnel_xmit+0x18c/0x220 [ 4833.637505] [<ffffffffc073b2e7>] udp_tunnel_xmit_skb+0x117/0x130 [udp_tunnel] [ 4833.637538] [<ffffffffc074585a>] vxlan_xmit_one+0xb6a/0xb70 [vxlan] [ 4833.637545] [<ffffffff8129dad9>] ? vprintk_default+0x29/0x40 [ 4833.637551] [<ffffffffc074765e>] vxlan_xmit+0xc9e/0xef0 [vxlan] [ 4833.637555] [<ffffffff818356e7>] ? kfree_skbmem+0x37/0x90 [ 4833.637559] [<ffffffff81836c24>] ? consume_skb+0x34/0x90 [ 4833.637564] [<ffffffff819547bc>] ? packet_rcv+0x4c/0x3e0 [ 4833.637570] [<ffffffff8184d346>] dev_hard_start_xmit+0x246/0x3b0 [ 4833.637574] [<ffffffff81850339>] __dev_queue_xmit+0x519/0x650 [ 4833.637580] [<ffffffff812d9df0>] ? try_to_wake_up+0x190/0x390 [ 4833.637585] [<ffffffff81850480>] dev_queue_xmit+0x10/0x20 [ 4833.637592] [<ffffffffc0724316>] ovs_vport_send+0xa6/0x180 [openvswitch] [ 4833.637599] [<ffffffffc07150fe>] do_output+0x4e/0xd0 [openvswitch] [ 4833.637604] [<ffffffffc0716699>] do_execute_actions+0xa29/0xa40 [openvswitch] [ 4833.637610] [<ffffffff812d24d2>] ? __wake_up_common+0x82/0x120 [ 4833.637615] [<ffffffffc0716aac>] ovs_execute_actions+0x4c/0x140 [openvswitch] [ 4833.637621] [<ffffffffc071a824>] ovs_dp_process_packet+0x84/0x120 [openvswitch] [ 4833.637627] [<ffffffffc0725404>] ? ovs_ct_update_key+0xc4/0x150 [openvswitch] [ 4833.637633] [<ffffffffc0724213>] ovs_vport_receive+0x73/0xd0 [openvswitch] [ 4833.637638] [<ffffffff812d666f>] ? ttwu_do_activate+0x6f/0x80 [ 4833.637642] [<ffffffff812d9df0>] ? try_to_wake_up+0x190/0x390 [ 4833.637646] [<ffffffff812da0c2>] ? default_wake_function+0x12/0x20 [ 4833.637651] [<ffffffff812c61eb>] ? autoremove_wake_function+0x2b/0x40 [ 4833.637657] [<ffffffff812d24d2>] ? __wake_up_common+0x82/0x120 [ 4833.637661] [<ffffffff812e3ae9>] ? update_cfs_shares+0xa9/0xf0 [ 4833.637665] [<ffffffff812e3696>] ? update_curr+0x86/0x1e0 [ 4833.637669] [<ffffffff812dee88>] ? __enqueue_entity+0x78/0x80 [ 4833.637677] [<ffffffffc0724cbe>] netdev_frame_hook+0xde/0x180 [openvswitch] [ 4833.637682] [<ffffffff8184d6aa>] __netif_receive_skb_core+0x1fa/0xa10 [ 4833.637688] [<ffffffffc0724be0>] ? vport_netdev_free+0x30/0x30 [openvswitch] [ 4833.637692] [<ffffffff812d6539>] ? ttwu_do_wakeup+0x19/0xe0 [ 4833.637697] [<ffffffff8184ded8>] __netif_receive_skb+0x18/0x60 [ 4833.637703] [<ffffffff8184ee9e>] process_backlog+0xae/0x180 [ 4833.637707] [<ffffffff8184e57f>] net_rx_action+0x26f/0x390 [ 4833.637713] [<ffffffff812a41e5>] __do_softirq+0xf5/0x280 [ 4833.637719] [<ffffffff8199042c>] call_softirq+0x1c/0x30 [ 4833.637723] <EOI> [<ffffffff8122f675>] do_softirq+0x65/0xa0 [ 4833.637730] [<ffffffff812a363b>] __local_bh_enable_ip+0x9b/0xb0 [ 4833.637735] [<ffffffff812a3667>] local_bh_enable+0x17/0x20 [ 4833.637741] [<ffffffff81850065>] __dev_queue_xmit+0x245/0x650 [ 4833.637746] [<ffffffff81972e28>] ? printk+0x60/0x77 [ 4833.637752] [<ffffffff81850480>] dev_queue_xmit+0x10/0x20 [ 4833.637757] [<ffffffff81957a75>] packet_sendmsg+0xf65/0x1210 [ 4833.637761] [<ffffffff813d7524>] ? shmem_fault+0x84/0x1f0 [ 4833.637768] [<ffffffff8182d3a6>] sock_sendmsg+0xb6/0xf0 [ 4833.637772] [<ffffffff812e3696>] ? update_curr+0x86/0x1e0 [ 4833.637777] [<ffffffff812e3ae9>] ? update_cfs_shares+0xa9/0xf0 [ 4833.637781] [<ffffffff8122b621>] ? __switch_to+0x151/0x580 [ 4833.637786] [<ffffffff8182dad1>] SYSC_sendto+0x121/0x1c0 [ 4833.637793] [<ffffffff812c8d10>] ? hrtimer_get_res+0x50/0x50 [ 4833.637797] [<ffffffff8197e54b>] ? do_nanosleep+0x5b/0x100 [ 4833.637802] [<ffffffff8182f5ee>] SyS_sendto+0xe/0x10 [ 4833.637806] [<ffffffff8198cede>] system_call_fastpath+0x25/0x2a Looking forward to your reply. Regards, Ramana

1 0

Linked list of VM areas
by Pedro Ortega Nov. 2, 2019

Nov. 2, 2019

Hi everybody. The linux kernel has its own implementation of linked lists using list_head struct. So, why the vm_area_struct struct (defined in /include/linux/mm_types.h) use specific pointers for the same purpose (members vm_next and vm_prev)? Best regards. Thanks in advance.

1 0

Simple system stats.
by Andre Schmidt Nov. 2, 2019

Nov. 2, 2019

Hello kernel space, user space webmonkey here, tinkering on my home desktop setup and spelunking way too many rabbit holes... damn you source code! ;P The other day i got frustrated with re-implementing parsing and calculation of /proc/stat and /proc/meminfo for my visual user interface experiments (in various languages), so i "created"* a kernel module that helps me with that (https://github.com/oskude/proc_topstat) But i could not get swap info in the kernel module, cause - i guess - it's not exported? So i wonder, would/could upstream EXPORT_SYMBOL(si_swapinfo)? If yes/maybe, where/how should i propose such change? Cheers Andre Schmidt * "created" as in i copy and pasted from upstream code...

2 4

soft lockup in fb_flashcursor
by Subhashini Rao Beerisetty Nov. 1, 2019

Nov. 1, 2019

Hi All, I noticed soft lockup in fb_flashcursor(). What could be the problem? and how to resolve this? [ 1061.790322] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/u8:1:2690] [ 1061.790380] Modules linked in: debug(OE) opabs(OE) gpio(OE) ramoops reed_solomon ppdev intel_rapl intel_soc_dts_iosf intel_powerclamp coretemp kvm irqbypass punit_atom_debug nd_pmem nd_btt lpc_ich pci(OE) cdc_acm mei_txe shpchp mei parport_pc parport 8250_fintek tpm_infineon mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915 aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd igb drm_kms_helper syscopyarea dca sysfillrect ptp sysimgblt [ 1061.790387] pps_core fb_sys_fops i2c_algo_bit drm ahci libahci fjes video [last unloaded: opabs] [ 1061.790391] CPU: 1 PID: 2690 Comm: kworker/u8:1 Tainted: G OE 4.4.0-66-generic #87-Ubuntu [ 1061.790392] Hardware name: Quanmax Inc. COMM-E380/COMM-E380, BIOS 1.02 08/01/2017 [ 1061.790401] Workqueue: events_power_efficient fb_flashcursor [ 1061.790403] task: ffff8800b249f2c0 ti: ffff8800b3aa8000 task.ti: ffff8800b3aa8000 [ 1061.790410] RIP: 0010:[<ffffffff810d8543>] [<ffffffff810d8543>] console_unlock+0x313/0x550 [ 1061.790412] RSP: 0000:ffff8800b3aabda0 EFLAGS: 00000246 [ 1061.790413] RAX: 0000000000000000 RBX: 0000000000000246 RCX: 00000000ffffffff [ 1061.790414] RDX: ffff8800b3aabd18 RSI: 0000000000000004 RDI: 0000000000000246 [ 1061.790416] RBP: ffff8800b3aabdd8 R08: 0000000000000000 R09: 0000000000000000 [ 1061.790417] R10: ffff880034956f00 R11: ffffffffffffffff R12: 0000000000000067 [ 1061.790418] R13: 0000000000000007 R14: ffffffff82115cbc R15: 0000000000000000 [ 1061.790420] FS: 0000000000000000(0000) GS:ffff88013fc80000(0000) knlGS:0000000000000000 [ 1061.790422] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1061.790423] CR2: 00007f3f3e5b5000 CR3: 00000000b3420000 CR4: 00000000001006e0 [ 1061.790424] Stack: [ 1061.790428] 01ff880000000000 ffffffff821503d0 0000000000000720 ffff880035657800 [ 1061.790431] ffff88013b08c400 0000000000000002 ffffffff81477190 ffff8800b3aabe18 [ 1061.790434] ffffffff8147103c 000000003fc96dc0 ffff88013a778900 ffff88013b08e800 [ 1061.790435] Call Trace: [ 1061.790441] [<ffffffff81477190>] ? update_attr.isra.2+0x90/0x90 [ 1061.790445] [<ffffffff8147103c>] fb_flashcursor+0x5c/0x110 [ 1061.790449] [<ffffffff8109a515>] process_one_work+0x165/0x480 [ 1061.790452] [<ffffffff8109a87b>] worker_thread+0x4b/0x4c0 [ 1061.790455] [<ffffffff8109a830>] ? process_one_work+0x480/0x480 [ 1061.790458] [<ffffffff8109a830>] ? process_one_work+0x480/0x480 [ 1061.790460] [<ffffffff810a0ba8>] kthread+0xd8/0xf0 [ 1061.790463] [<ffffffff810a0ad0>] ? kthread_create_on_node+0x1e0/0x1e0 [ 1061.790468] [<ffffffff8183c98f>] ret_from_fork+0x3f/0x70 [ 1061.790470] [<ffffffff810a0ad0>] ? kthread_create_on_node+0x1e0/0x1e0 [ 1061.790502] Code: 48 8b 7d d0 83 e0 1f 89 05 63 7e 07 01 c6 07 00 0f 1f 40 00 48 c7 c6 a0 d6 10 82 44 89 ef 4c 89 e1 e8 f2 f5 ff ff 48 89 df 57 9d <0f> 1f 44 00 00 8b 45 c8 85 c0 0f 84 6e fd ff ff e8 98 01 76 00 Thanks

1 0