[Kernel-packages] [Bug 1802480] Re: Crash when using IPsec VTI interfaces on 4.15 and 4.18.
This happens with 4.20-rc2. This is fixed by the patch referenced in this thread: https://marc.info/?l=linux-netdev=154239557300724=2 ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Tags added: kernel-bug-exists-upstream -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1802480 Title: Crash when using IPsec VTI interfaces on 4.15 and 4.18. Status in linux package in Ubuntu: Confirmed Bug description: Hey! After upgrading a few VPN to 4.15.0-38.41 (either Xenial or Bionic), we get random crashes. This also happens with the 4.18 in bionic- proposed. These crashes didn't happen with 4.4 from Xenial. Here is a stack trace: [ 31.154360] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 31.162233] PGD 0 P4D 0 [ 31.164786] Oops: [#1] SMP PTI [ 31.168291] CPU: 5 PID: 42 Comm: ksoftirqd/5 Not tainted 4.18.0-11-generic #12~18.04.1-Ubuntu [ 31.176854] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016 [ 31.184980] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti] [ 31.189962] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20 [ 31.208916] RSP: 0018:bc61832e3920 EFLAGS: 00010246 [ 31.214160] RAX: RBX: 9a3504964a00 RCX: 0002 [ 31.221328] RDX: 9a351add4080 RSI: 9a351aa08000 RDI: 9a3504964a00 [ 31.228485] RBP: bc61832e3940 R08: 0004 R09: c0aa612b [ 31.235643] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: 9a3507b31900 [ 31.242803] R13: 9a3507b31000 R14: R15: 9a3504964a00 [ 31.249964] FS: () GS:9a35bfd4() knlGS: [ 31.258077] CS: 0010 DS: ES: CR0: 80050033 [ 31.263848] CR2: 0038 CR3: 00041a40a003 CR4: 003606e0 [ 31.271004] DR0: DR1: DR2: [ 31.278163] DR3: DR6: fffe0ff0 DR7: 0400 [ 31.285320] Call Trace: [ 31.287789] xfrm4_rcv_cb+0x4a/0x70 [ 31.291297] xfrm_input+0x58f/0x8f0 [ 31.294807] vti_input+0xaa/0x110 [ip_vti] [ 31.298926] vti_rcv+0x33/0x3c [ip_vti] [ 31.302783] xfrm4_esp_rcv+0x39/0x50 [ 31.306375] ip_local_deliver_finish+0x62/0x200 [ 31.310923] ip_local_deliver+0xdf/0xf0 [ 31.314775] ? ip_rcv_finish+0x420/0x420 [ 31.318718] ip_rcv_finish+0x126/0x420 [ 31.322486] ip_rcv+0x28f/0x360 [ 31.325655] ? inet_del_offload+0x40/0x40 [ 31.329686] __netif_receive_skb_core+0x48c/0xb70 [ 31.334413] ? kmem_cache_alloc+0xb4/0x1d0 [ 31.338532] ? __build_skb+0x2b/0xf0 [ 31.342128] __netif_receive_skb+0x18/0x60 [ 31.346244] ? __netif_receive_skb+0x18/0x60 [ 31.350536] netif_receive_skb_internal+0x45/0xe0 [ 31.355263] napi_gro_receive+0xc5/0xf0 [ 31.359141] mlx5e_handle_rx_cqe+0x1b2/0x5d0 [mlx5_core] [ 31.364476] ? skb_release_all+0x24/0x30 [ 31.368430] mlx5e_poll_rx_cq+0xd3/0x990 [mlx5_core] [ 31.373432] mlx5e_napi_poll+0x9b/0xc60 [mlx5_core] [ 31.378333] ? __switch_to_asm+0x34/0x70 [ 31.382270] ? __switch_to_asm+0x40/0x70 [ 31.386214] ? __switch_to_asm+0x34/0x70 [ 31.391056] ? __switch_to_asm+0x40/0x70 [ 31.395905] ? __switch_to_asm+0x34/0x70 [ 31.400743] net_rx_action+0x140/0x3a0 [ 31.405379] ? __switch_to+0xad/0x500 [ 31.409887] __do_softirq+0xe4/0x2bb [ 31.414448] run_ksoftirqd+0x2b/0x40 [ 31.418862] smpboot_thread_fn+0xfc/0x170 [ 31.423700] kthread+0x121/0x140 [ 31.427701] ? sort_range+0x30/0x30 [ 31.432040] ? kthread_create_worker_on_cpu+0x70/0x70 [ 31.437816] ret_from_fork+0x35/0x40 [ 31.442219] Modules linked in: esp6 authenc echainiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo ip_vti ip_tunnel ip6_vti ip6_tunnel tunnel6 8021q garp mrp stp llc bonding ipt_REJECT nf_reject_ipv4 nfnetlink_log n fnetlink xt_NFLOG xt_hl xt_limit xt_nat xt_TCPMSS xt_HL xt_comment xt_tcpudp xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark xt_mark iptable_mangle xt_CT nf_conntrack xt_addrtype iptable_raw bpfilter ipmi_ssif gpio_ ich intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds joydev mei_me intel_pch_thermal ioatdma mei lpc_ich ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mac_hid sch_fq_codel [ 31.519488] ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs
[Kernel-packages] [Bug 1802480] Re: Crash when using IPsec VTI interfaces on 4.15 and 4.18.
Nevermind, 4.18.17 is not enough to fix the crash. Currently testing with 4.19.1. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1802480 Title: Crash when using IPsec VTI interfaces on 4.15 and 4.18. Status in linux package in Ubuntu: Confirmed Bug description: Hey! After upgrading a few VPN to 4.15.0-38.41 (either Xenial or Bionic), we get random crashes. This also happens with the 4.18 in bionic- proposed. These crashes didn't happen with 4.4 from Xenial. Here is a stack trace: [ 31.154360] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 31.162233] PGD 0 P4D 0 [ 31.164786] Oops: [#1] SMP PTI [ 31.168291] CPU: 5 PID: 42 Comm: ksoftirqd/5 Not tainted 4.18.0-11-generic #12~18.04.1-Ubuntu [ 31.176854] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016 [ 31.184980] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti] [ 31.189962] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20 [ 31.208916] RSP: 0018:bc61832e3920 EFLAGS: 00010246 [ 31.214160] RAX: RBX: 9a3504964a00 RCX: 0002 [ 31.221328] RDX: 9a351add4080 RSI: 9a351aa08000 RDI: 9a3504964a00 [ 31.228485] RBP: bc61832e3940 R08: 0004 R09: c0aa612b [ 31.235643] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: 9a3507b31900 [ 31.242803] R13: 9a3507b31000 R14: R15: 9a3504964a00 [ 31.249964] FS: () GS:9a35bfd4() knlGS: [ 31.258077] CS: 0010 DS: ES: CR0: 80050033 [ 31.263848] CR2: 0038 CR3: 00041a40a003 CR4: 003606e0 [ 31.271004] DR0: DR1: DR2: [ 31.278163] DR3: DR6: fffe0ff0 DR7: 0400 [ 31.285320] Call Trace: [ 31.287789] xfrm4_rcv_cb+0x4a/0x70 [ 31.291297] xfrm_input+0x58f/0x8f0 [ 31.294807] vti_input+0xaa/0x110 [ip_vti] [ 31.298926] vti_rcv+0x33/0x3c [ip_vti] [ 31.302783] xfrm4_esp_rcv+0x39/0x50 [ 31.306375] ip_local_deliver_finish+0x62/0x200 [ 31.310923] ip_local_deliver+0xdf/0xf0 [ 31.314775] ? ip_rcv_finish+0x420/0x420 [ 31.318718] ip_rcv_finish+0x126/0x420 [ 31.322486] ip_rcv+0x28f/0x360 [ 31.325655] ? inet_del_offload+0x40/0x40 [ 31.329686] __netif_receive_skb_core+0x48c/0xb70 [ 31.334413] ? kmem_cache_alloc+0xb4/0x1d0 [ 31.338532] ? __build_skb+0x2b/0xf0 [ 31.342128] __netif_receive_skb+0x18/0x60 [ 31.346244] ? __netif_receive_skb+0x18/0x60 [ 31.350536] netif_receive_skb_internal+0x45/0xe0 [ 31.355263] napi_gro_receive+0xc5/0xf0 [ 31.359141] mlx5e_handle_rx_cqe+0x1b2/0x5d0 [mlx5_core] [ 31.364476] ? skb_release_all+0x24/0x30 [ 31.368430] mlx5e_poll_rx_cq+0xd3/0x990 [mlx5_core] [ 31.373432] mlx5e_napi_poll+0x9b/0xc60 [mlx5_core] [ 31.378333] ? __switch_to_asm+0x34/0x70 [ 31.382270] ? __switch_to_asm+0x40/0x70 [ 31.386214] ? __switch_to_asm+0x34/0x70 [ 31.391056] ? __switch_to_asm+0x40/0x70 [ 31.395905] ? __switch_to_asm+0x34/0x70 [ 31.400743] net_rx_action+0x140/0x3a0 [ 31.405379] ? __switch_to+0xad/0x500 [ 31.409887] __do_softirq+0xe4/0x2bb [ 31.414448] run_ksoftirqd+0x2b/0x40 [ 31.418862] smpboot_thread_fn+0xfc/0x170 [ 31.423700] kthread+0x121/0x140 [ 31.427701] ? sort_range+0x30/0x30 [ 31.432040] ? kthread_create_worker_on_cpu+0x70/0x70 [ 31.437816] ret_from_fork+0x35/0x40 [ 31.442219] Modules linked in: esp6 authenc echainiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo ip_vti ip_tunnel ip6_vti ip6_tunnel tunnel6 8021q garp mrp stp llc bonding ipt_REJECT nf_reject_ipv4 nfnetlink_log n fnetlink xt_NFLOG xt_hl xt_limit xt_nat xt_TCPMSS xt_HL xt_comment xt_tcpudp xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark xt_mark iptable_mangle xt_CT nf_conntrack xt_addrtype iptable_raw bpfilter ipmi_ssif gpio_ ich intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds joydev mei_me intel_pch_thermal ioatdma mei lpc_ich ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mac_hid sch_fq_codel [ 31.519488] ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear mlx5_ib ib_uverbs ib _core raid1
[Kernel-packages] [Bug 1802480] Re: Crash when using IPsec VTI interfaces on 4.15 and 4.18.
Sorry, currently, all hosts are running a mainline kernel (4.18.17). ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1802480 Title: Crash when using IPsec VTI interfaces on 4.15 and 4.18. Status in linux package in Ubuntu: Confirmed Bug description: Hey! After upgrading a few VPN to 4.15.0-38.41 (either Xenial or Bionic), we get random crashes. This also happens with the 4.18 in bionic- proposed. These crashes didn't happen with 4.4 from Xenial. Here is a stack trace: [ 31.154360] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 31.162233] PGD 0 P4D 0 [ 31.164786] Oops: [#1] SMP PTI [ 31.168291] CPU: 5 PID: 42 Comm: ksoftirqd/5 Not tainted 4.18.0-11-generic #12~18.04.1-Ubuntu [ 31.176854] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016 [ 31.184980] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti] [ 31.189962] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20 [ 31.208916] RSP: 0018:bc61832e3920 EFLAGS: 00010246 [ 31.214160] RAX: RBX: 9a3504964a00 RCX: 0002 [ 31.221328] RDX: 9a351add4080 RSI: 9a351aa08000 RDI: 9a3504964a00 [ 31.228485] RBP: bc61832e3940 R08: 0004 R09: c0aa612b [ 31.235643] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: 9a3507b31900 [ 31.242803] R13: 9a3507b31000 R14: R15: 9a3504964a00 [ 31.249964] FS: () GS:9a35bfd4() knlGS: [ 31.258077] CS: 0010 DS: ES: CR0: 80050033 [ 31.263848] CR2: 0038 CR3: 00041a40a003 CR4: 003606e0 [ 31.271004] DR0: DR1: DR2: [ 31.278163] DR3: DR6: fffe0ff0 DR7: 0400 [ 31.285320] Call Trace: [ 31.287789] xfrm4_rcv_cb+0x4a/0x70 [ 31.291297] xfrm_input+0x58f/0x8f0 [ 31.294807] vti_input+0xaa/0x110 [ip_vti] [ 31.298926] vti_rcv+0x33/0x3c [ip_vti] [ 31.302783] xfrm4_esp_rcv+0x39/0x50 [ 31.306375] ip_local_deliver_finish+0x62/0x200 [ 31.310923] ip_local_deliver+0xdf/0xf0 [ 31.314775] ? ip_rcv_finish+0x420/0x420 [ 31.318718] ip_rcv_finish+0x126/0x420 [ 31.322486] ip_rcv+0x28f/0x360 [ 31.325655] ? inet_del_offload+0x40/0x40 [ 31.329686] __netif_receive_skb_core+0x48c/0xb70 [ 31.334413] ? kmem_cache_alloc+0xb4/0x1d0 [ 31.338532] ? __build_skb+0x2b/0xf0 [ 31.342128] __netif_receive_skb+0x18/0x60 [ 31.346244] ? __netif_receive_skb+0x18/0x60 [ 31.350536] netif_receive_skb_internal+0x45/0xe0 [ 31.355263] napi_gro_receive+0xc5/0xf0 [ 31.359141] mlx5e_handle_rx_cqe+0x1b2/0x5d0 [mlx5_core] [ 31.364476] ? skb_release_all+0x24/0x30 [ 31.368430] mlx5e_poll_rx_cq+0xd3/0x990 [mlx5_core] [ 31.373432] mlx5e_napi_poll+0x9b/0xc60 [mlx5_core] [ 31.378333] ? __switch_to_asm+0x34/0x70 [ 31.382270] ? __switch_to_asm+0x40/0x70 [ 31.386214] ? __switch_to_asm+0x34/0x70 [ 31.391056] ? __switch_to_asm+0x40/0x70 [ 31.395905] ? __switch_to_asm+0x34/0x70 [ 31.400743] net_rx_action+0x140/0x3a0 [ 31.405379] ? __switch_to+0xad/0x500 [ 31.409887] __do_softirq+0xe4/0x2bb [ 31.414448] run_ksoftirqd+0x2b/0x40 [ 31.418862] smpboot_thread_fn+0xfc/0x170 [ 31.423700] kthread+0x121/0x140 [ 31.427701] ? sort_range+0x30/0x30 [ 31.432040] ? kthread_create_worker_on_cpu+0x70/0x70 [ 31.437816] ret_from_fork+0x35/0x40 [ 31.442219] Modules linked in: esp6 authenc echainiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo ip_vti ip_tunnel ip6_vti ip6_tunnel tunnel6 8021q garp mrp stp llc bonding ipt_REJECT nf_reject_ipv4 nfnetlink_log n fnetlink xt_NFLOG xt_hl xt_limit xt_nat xt_TCPMSS xt_HL xt_comment xt_tcpudp xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark xt_mark iptable_mangle xt_CT nf_conntrack xt_addrtype iptable_raw bpfilter ipmi_ssif gpio_ ich intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds joydev mei_me intel_pch_thermal ioatdma mei lpc_ich ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mac_hid sch_fq_codel [ 31.519488] ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0
[Kernel-packages] [Bug 1802480] Re: Crash when using IPsec VTI interfaces on 4.15 and 4.18.
Commit fdb06c787b34fd397f28f515105627307d615025 title is "xfrm: reset transport header back to network header after all input transforms ahave been applied" -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1802480 Title: Crash when using IPsec VTI interfaces on 4.15 and 4.18. Status in linux package in Ubuntu: Incomplete Bug description: Hey! After upgrading a few VPN to 4.15.0-38.41 (either Xenial or Bionic), we get random crashes. This also happens with the 4.18 in bionic- proposed. These crashes didn't happen with 4.4 from Xenial. Here is a stack trace: [ 31.154360] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 31.162233] PGD 0 P4D 0 [ 31.164786] Oops: [#1] SMP PTI [ 31.168291] CPU: 5 PID: 42 Comm: ksoftirqd/5 Not tainted 4.18.0-11-generic #12~18.04.1-Ubuntu [ 31.176854] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016 [ 31.184980] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti] [ 31.189962] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20 [ 31.208916] RSP: 0018:bc61832e3920 EFLAGS: 00010246 [ 31.214160] RAX: RBX: 9a3504964a00 RCX: 0002 [ 31.221328] RDX: 9a351add4080 RSI: 9a351aa08000 RDI: 9a3504964a00 [ 31.228485] RBP: bc61832e3940 R08: 0004 R09: c0aa612b [ 31.235643] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: 9a3507b31900 [ 31.242803] R13: 9a3507b31000 R14: R15: 9a3504964a00 [ 31.249964] FS: () GS:9a35bfd4() knlGS: [ 31.258077] CS: 0010 DS: ES: CR0: 80050033 [ 31.263848] CR2: 0038 CR3: 00041a40a003 CR4: 003606e0 [ 31.271004] DR0: DR1: DR2: [ 31.278163] DR3: DR6: fffe0ff0 DR7: 0400 [ 31.285320] Call Trace: [ 31.287789] xfrm4_rcv_cb+0x4a/0x70 [ 31.291297] xfrm_input+0x58f/0x8f0 [ 31.294807] vti_input+0xaa/0x110 [ip_vti] [ 31.298926] vti_rcv+0x33/0x3c [ip_vti] [ 31.302783] xfrm4_esp_rcv+0x39/0x50 [ 31.306375] ip_local_deliver_finish+0x62/0x200 [ 31.310923] ip_local_deliver+0xdf/0xf0 [ 31.314775] ? ip_rcv_finish+0x420/0x420 [ 31.318718] ip_rcv_finish+0x126/0x420 [ 31.322486] ip_rcv+0x28f/0x360 [ 31.325655] ? inet_del_offload+0x40/0x40 [ 31.329686] __netif_receive_skb_core+0x48c/0xb70 [ 31.334413] ? kmem_cache_alloc+0xb4/0x1d0 [ 31.338532] ? __build_skb+0x2b/0xf0 [ 31.342128] __netif_receive_skb+0x18/0x60 [ 31.346244] ? __netif_receive_skb+0x18/0x60 [ 31.350536] netif_receive_skb_internal+0x45/0xe0 [ 31.355263] napi_gro_receive+0xc5/0xf0 [ 31.359141] mlx5e_handle_rx_cqe+0x1b2/0x5d0 [mlx5_core] [ 31.364476] ? skb_release_all+0x24/0x30 [ 31.368430] mlx5e_poll_rx_cq+0xd3/0x990 [mlx5_core] [ 31.373432] mlx5e_napi_poll+0x9b/0xc60 [mlx5_core] [ 31.378333] ? __switch_to_asm+0x34/0x70 [ 31.382270] ? __switch_to_asm+0x40/0x70 [ 31.386214] ? __switch_to_asm+0x34/0x70 [ 31.391056] ? __switch_to_asm+0x40/0x70 [ 31.395905] ? __switch_to_asm+0x34/0x70 [ 31.400743] net_rx_action+0x140/0x3a0 [ 31.405379] ? __switch_to+0xad/0x500 [ 31.409887] __do_softirq+0xe4/0x2bb [ 31.414448] run_ksoftirqd+0x2b/0x40 [ 31.418862] smpboot_thread_fn+0xfc/0x170 [ 31.423700] kthread+0x121/0x140 [ 31.427701] ? sort_range+0x30/0x30 [ 31.432040] ? kthread_create_worker_on_cpu+0x70/0x70 [ 31.437816] ret_from_fork+0x35/0x40 [ 31.442219] Modules linked in: esp6 authenc echainiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo ip_vti ip_tunnel ip6_vti ip6_tunnel tunnel6 8021q garp mrp stp llc bonding ipt_REJECT nf_reject_ipv4 nfnetlink_log n fnetlink xt_NFLOG xt_hl xt_limit xt_nat xt_TCPMSS xt_HL xt_comment xt_tcpudp xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark xt_mark iptable_mangle xt_CT nf_conntrack xt_addrtype iptable_raw bpfilter ipmi_ssif gpio_ ich intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds joydev mei_me intel_pch_thermal ioatdma mei lpc_ich ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mac_hid sch_fq_codel [ 31.519488] ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
[Kernel-packages] [Bug 1802480] [NEW] Crash when using IPsec VTI interfaces on 4.15 and 4.18.
Public bug reported: Hey! After upgrading a few VPN to 4.15.0-38.41 (either Xenial or Bionic), we get random crashes. This also happens with the 4.18 in bionic-proposed. These crashes didn't happen with 4.4 from Xenial. Here is a stack trace: [ 31.154360] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 31.162233] PGD 0 P4D 0 [ 31.164786] Oops: [#1] SMP PTI [ 31.168291] CPU: 5 PID: 42 Comm: ksoftirqd/5 Not tainted 4.18.0-11-generic #12~18.04.1-Ubuntu [ 31.176854] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016 [ 31.184980] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti] [ 31.189962] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20 [ 31.208916] RSP: 0018:bc61832e3920 EFLAGS: 00010246 [ 31.214160] RAX: RBX: 9a3504964a00 RCX: 0002 [ 31.221328] RDX: 9a351add4080 RSI: 9a351aa08000 RDI: 9a3504964a00 [ 31.228485] RBP: bc61832e3940 R08: 0004 R09: c0aa612b [ 31.235643] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: 9a3507b31900 [ 31.242803] R13: 9a3507b31000 R14: R15: 9a3504964a00 [ 31.249964] FS: () GS:9a35bfd4() knlGS: [ 31.258077] CS: 0010 DS: ES: CR0: 80050033 [ 31.263848] CR2: 0038 CR3: 00041a40a003 CR4: 003606e0 [ 31.271004] DR0: DR1: DR2: [ 31.278163] DR3: DR6: fffe0ff0 DR7: 0400 [ 31.285320] Call Trace: [ 31.287789] xfrm4_rcv_cb+0x4a/0x70 [ 31.291297] xfrm_input+0x58f/0x8f0 [ 31.294807] vti_input+0xaa/0x110 [ip_vti] [ 31.298926] vti_rcv+0x33/0x3c [ip_vti] [ 31.302783] xfrm4_esp_rcv+0x39/0x50 [ 31.306375] ip_local_deliver_finish+0x62/0x200 [ 31.310923] ip_local_deliver+0xdf/0xf0 [ 31.314775] ? ip_rcv_finish+0x420/0x420 [ 31.318718] ip_rcv_finish+0x126/0x420 [ 31.322486] ip_rcv+0x28f/0x360 [ 31.325655] ? inet_del_offload+0x40/0x40 [ 31.329686] __netif_receive_skb_core+0x48c/0xb70 [ 31.334413] ? kmem_cache_alloc+0xb4/0x1d0 [ 31.338532] ? __build_skb+0x2b/0xf0 [ 31.342128] __netif_receive_skb+0x18/0x60 [ 31.346244] ? __netif_receive_skb+0x18/0x60 [ 31.350536] netif_receive_skb_internal+0x45/0xe0 [ 31.355263] napi_gro_receive+0xc5/0xf0 [ 31.359141] mlx5e_handle_rx_cqe+0x1b2/0x5d0 [mlx5_core] [ 31.364476] ? skb_release_all+0x24/0x30 [ 31.368430] mlx5e_poll_rx_cq+0xd3/0x990 [mlx5_core] [ 31.373432] mlx5e_napi_poll+0x9b/0xc60 [mlx5_core] [ 31.378333] ? __switch_to_asm+0x34/0x70 [ 31.382270] ? __switch_to_asm+0x40/0x70 [ 31.386214] ? __switch_to_asm+0x34/0x70 [ 31.391056] ? __switch_to_asm+0x40/0x70 [ 31.395905] ? __switch_to_asm+0x34/0x70 [ 31.400743] net_rx_action+0x140/0x3a0 [ 31.405379] ? __switch_to+0xad/0x500 [ 31.409887] __do_softirq+0xe4/0x2bb [ 31.414448] run_ksoftirqd+0x2b/0x40 [ 31.418862] smpboot_thread_fn+0xfc/0x170 [ 31.423700] kthread+0x121/0x140 [ 31.427701] ? sort_range+0x30/0x30 [ 31.432040] ? kthread_create_worker_on_cpu+0x70/0x70 [ 31.437816] ret_from_fork+0x35/0x40 [ 31.442219] Modules linked in: esp6 authenc echainiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo ip_vti ip_tunnel ip6_vti ip6_tunnel tunnel6 8021q garp mrp stp llc bonding ipt_REJECT nf_reject_ipv4 nfnetlink_log n fnetlink xt_NFLOG xt_hl xt_limit xt_nat xt_TCPMSS xt_HL xt_comment xt_tcpudp xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark xt_mark iptable_mangle xt_CT nf_conntrack xt_addrtype iptable_raw bpfilter ipmi_ssif gpio_ ich intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds joydev mei_me intel_pch_thermal ioatdma mei lpc_ich ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mac_hid sch_fq_codel [ 31.519488] ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear mlx5_ib ib_uverbs ib _core raid1 hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ast pcbc ttm drm_kms_helper aesni_intel syscopyarea aes_x86_64 sysfillrect mxm_wmi crypto_simd sysimgblt cryptd glue_helper fb_sys_fops mlx5_core ixgbe igb mpt3sas drm ahci tls libahci i2c_algo_bit m lxfw raid_class dca devlink mdio scsi_transport_sas wmi [ 31.578877] CR2: 0038 [ 31.583249] ---[ end trace c4bada38847a0075 ]--- Upgrading to mainline 4.18.17 seems to solve the issue. It's difficult to bissect
[Kernel-packages] [Bug 1778486] Re: x86/kvm: fix LAPIC timer drift when guest uses periodic mode
The fix is not present in -32. It seems to be scheduled for -33.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1778486
Title:
x86/kvm: fix LAPIC timer drift when guest uses periodic mode
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
In Progress
Bug description:
== SRU Justification ==
This patch fixes a regression introduced by mainline commit
8003c9ae204e in v4.10. Without this new patch, OpenBSD guests encounter
timing issues when running under bionic kernel.
See also:
https://www.spinics.net/lists/kvm/msg161311.html
== Fix ==
d8f2f498d9ed ("x86/kvm: fix LAPIC timer drift when guest uses periodic mode")
== Regression Potential ==
Low. This fixes a current regression.
== Test Case ==
A test kernel was built with this patch and tested by the original bug
reporter.
The bug reporter states the test kernel resolved the bug.
OpenBSD guests encounter timing issues when running under bionic kernel.
This issue is actually present since 4.10 and is fixed by:
https://patchwork.kernel.org/patch/10411125/
See also
https://www.spinics.net/lists/kvm/msg161311.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1778486/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1764956] Re: Guests using IBRS incur a large performance penalty
No log files to provide. ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1764956 Title: Guests using IBRS incur a large performance penalty Status in linux package in Ubuntu: Confirmed Bug description: Hello! As of Linux 4.4.0-119, when a KVM guest is using IBRS, this incurs a very large performance penalty on the hosts and other guests. From my understanding, the patch f676aa34b4027d1a7a4bbcc58b81b20c68c7ce0c is incomplete. If host doesn't handle IBRS itself (which is now the case by default since 4.4.0-116: it relies on retpoline instead) but the guest does (eg running an earlier kernel), the guest will set IBRS for the CPU it is running on from time to time but if it gets preempted at some point, the IBRS bit will stay, incurring a major performance penalty for all other users of the CPU (host userland, host kernel and other guests not caring about IBRS). The equivalent patch in mainline (d28b387fb74da95d69d2615732f50cceb38e9a4d) ensure the appropriate MSR is correctly restored when switching from one guest to another or from one guest to host. The issue is easy to reproduce: host running 4.4.0-119, exposing "spec_ctrl" to a guest running CentOS 7.4 with its January kernel. Wait a few minutes and the host will become pretty slow. A simple shell loop will take 10 more times to execute. Executing "sysctl -w kernel.ibrs_dump=1" will show that most real cores have now their IBRS bit set to 1. A workaround is to reeanble IBRS on the host (sysctl -w kernel.ibrs_enabled=1). This way, IBRS will be correctly disabled when changing context. A long term solution would be to properly backport the patch from mainline. It is not part of the 4.4 stable branch and it seems not trivial to port. A mid term solution could be to remove the faulty patch (not exposing IBRS), since most VM don't need it anymore. This also salvage the ability to use IBPB (which doesn't seem to alter performance that much) but it isn't believed to be essential. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1764956/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1764956] [NEW] Guests using IBRS incur a large performance penalty
Public bug reported: Hello! As of Linux 4.4.0-119, when a KVM guest is using IBRS, this incurs a very large performance penalty on the hosts and other guests. >From my understanding, the patch f676aa34b4027d1a7a4bbcc58b81b20c68c7ce0c is incomplete. If host doesn't handle IBRS itself (which is now the case by default since 4.4.0-116: it relies on retpoline instead) but the guest does (eg running an earlier kernel), the guest will set IBRS for the CPU it is running on from time to time but if it gets preempted at some point, the IBRS bit will stay, incurring a major performance penalty for all other users of the CPU (host userland, host kernel and other guests not caring about IBRS). The equivalent patch in mainline (d28b387fb74da95d69d2615732f50cceb38e9a4d) ensure the appropriate MSR is correctly restored when switching from one guest to another or from one guest to host. The issue is easy to reproduce: host running 4.4.0-119, exposing "spec_ctrl" to a guest running CentOS 7.4 with its January kernel. Wait a few minutes and the host will become pretty slow. A simple shell loop will take 10 more times to execute. Executing "sysctl -w kernel.ibrs_dump=1" will show that most real cores have now their IBRS bit set to 1. A workaround is to reeanble IBRS on the host (sysctl -w kernel.ibrs_enabled=1). This way, IBRS will be correctly disabled when changing context. A long term solution would be to properly backport the patch from mainline. It is not part of the 4.4 stable branch and it seems not trivial to port. A mid term solution could be to remove the faulty patch (not exposing IBRS), since most VM don't need it anymore. This also salvage the ability to use IBPB (which doesn't seem to alter performance that much) but it isn't believed to be essential. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1764956 Title: Guests using IBRS incur a large performance penalty Status in linux package in Ubuntu: New Bug description: Hello! As of Linux 4.4.0-119, when a KVM guest is using IBRS, this incurs a very large performance penalty on the hosts and other guests. From my understanding, the patch f676aa34b4027d1a7a4bbcc58b81b20c68c7ce0c is incomplete. If host doesn't handle IBRS itself (which is now the case by default since 4.4.0-116: it relies on retpoline instead) but the guest does (eg running an earlier kernel), the guest will set IBRS for the CPU it is running on from time to time but if it gets preempted at some point, the IBRS bit will stay, incurring a major performance penalty for all other users of the CPU (host userland, host kernel and other guests not caring about IBRS). The equivalent patch in mainline (d28b387fb74da95d69d2615732f50cceb38e9a4d) ensure the appropriate MSR is correctly restored when switching from one guest to another or from one guest to host. The issue is easy to reproduce: host running 4.4.0-119, exposing "spec_ctrl" to a guest running CentOS 7.4 with its January kernel. Wait a few minutes and the host will become pretty slow. A simple shell loop will take 10 more times to execute. Executing "sysctl -w kernel.ibrs_dump=1" will show that most real cores have now their IBRS bit set to 1. A workaround is to reeanble IBRS on the host (sysctl -w kernel.ibrs_enabled=1). This way, IBRS will be correctly disabled when changing context. A long term solution would be to properly backport the patch from mainline. It is not part of the 4.4 stable branch and it seems not trivial to port. A mid term solution could be to remove the faulty patch (not exposing IBRS), since most VM don't need it anymore. This also salvage the ability to use IBPB (which doesn't seem to alter performance that much) but it isn't believed to be essential. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1764956/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1746936] Re: linux: 4.4.0-113.136 -proposed tracker
Compared to previous kernel, IBRS/IBPB are not exposed anymore for use by KVM (MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD). VM running on the previous kernel (with a profile mandating spec-ctrl) won't be able to start anymore. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1746936 Title: linux: 4.4.0-113.136 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Confirmed Status in Kernel SRU Workflow certification-testing series: Confirmed Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Confirmed Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-certification-testing series: New Status in Kernel SRU Workflow snap-release-to-beta series: Confirmed Status in Kernel SRU Workflow snap-release-to-candidate series: New Status in Kernel SRU Workflow snap-release-to-edge series: Confirmed Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow upload-to-ppa series: Invalid Status in Kernel SRU Workflow verification-testing series: Confirmed Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Confirmed Bug description: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow backports: 1746937,1746938 derivatives: 1746939,1746941,1746942,1746944,1746945,1746946 -- swm properties -- boot-testing-requested: true phase: Promoted to proposed proposed-announcement-sent: true proposed-testing-requested: true To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1746936/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1743362] Re: linux: 4.4.0-111.134 -proposed tracker
As mentioned in #1742995, one patch is incomplete and doesn't expose the appropriate CPUID for KVM hosts when running on Intel hardware. 8339cae23d79be97a38df3852ef5dab870806a58 should add speculative control CPUID support for guests. The patch looks truncated as it defines KVM_CPUID_BIT_SPEC_CTRL but doesn't use it. I am using this patch instead: https://github.com/exoscale/pkg- kernel-4.4/blob/xenial/debian/patches/ibrs%2Bkvm/0002-kvm-x86-add- speculative-control-cpuid-support-for-guests.patch. The additional bits compared to the patch from SuSE (https://github.com/openSUSE/kernel- source/blob/SLE12-SP3/patches.suse/27-kvm-x86-add-speculative-control- cpuid-support-for-guests.patch) are needed because this is the first time a CPUID 7.0 feature is exposed on EDX. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1743362 Title: linux: 4.4.0-111.134 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Confirmed Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Fix Released Status in Kernel SRU Workflow security-signoff series: Fix Released Status in Kernel SRU Workflow snap-certification-testing series: Fix Released Status in Kernel SRU Workflow snap-release-to-beta series: Fix Released Status in Kernel SRU Workflow snap-release-to-candidate series: Fix Released Status in Kernel SRU Workflow snap-release-to-edge series: Fix Released Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow upload-to-ppa series: Invalid Status in Kernel SRU Workflow verification-testing series: Invalid Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Confirmed Bug description: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow backports: 1743363,1743364 derivatives: 1743365,1743367,1743368,1743369,1743370,1743371 -- swm properties -- boot-testing-requested: true phase: Promoted to proposed proposed-announcement-sent: true proposed-testing-requested: true To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1743362/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1742995] Re: linux: 4.4.0-110.133 -proposed tracker
The last patch doesn't apply cleanly. This one does: https://github.com/exoscale/pkg- kernel-4.4/blob/7586bedddca6a5a7d3e2f4fc2fbe944043fa9780/debian/patches/ibrs%2Bkvm/0003-x86 -provide-get-scattered-cpuid-leaf.patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1742995 Title: linux: 4.4.0-110.133 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Incomplete Status in Kernel SRU Workflow certification-testing series: Confirmed Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Confirmed Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-certification-testing series: New Status in Kernel SRU Workflow snap-release-to-beta series: Confirmed Status in Kernel SRU Workflow snap-release-to-candidate series: New Status in Kernel SRU Workflow snap-release-to-edge series: Confirmed Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow upload-to-ppa series: Invalid Status in Kernel SRU Workflow verification-testing series: Confirmed Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Confirmed Bug description: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow backports: 1742996,1742998 derivatives: 1742999,1743000,1743001,1743002,1743004,1743006 -- swm properties -- boot-testing-requested: true phase: Promoted to proposed proposed-announcement-sent: true proposed-testing-requested: true To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1742995/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1742995] Re: linux: 4.4.0-110.133 -proposed tracker
Hey! The patchset seems incomplete: 8339cae23d79be97a38df3852ef5dab870806a58 should add speculative control CPUID support for guests but only the AMD part is here. When running a guest on top of KVM, CPUID doesn't contain the spec-ctrl bit. I am using this patch instead: https://github.com/exoscale/pkg-kernel-4.4/blob/4d0b19ad0379ba20846634e21ec0192a9326/debian/patches/ibrs%2Bkvm/27-kvm-x86-add-speculative-control-cpuid-support-for-guests.patch It also needs the following patch: https://github.com/exoscale/pkg-kernel-4.4/blob/4d0b19ad0379ba20846634e21ec0192a9326/debian/patches/ibrs%2Bkvm/32-x86-provide-get-scattered-cpuid-leaf.patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1742995 Title: linux: 4.4.0-110.133 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Incomplete Status in Kernel SRU Workflow certification-testing series: Confirmed Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Confirmed Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-certification-testing series: New Status in Kernel SRU Workflow snap-release-to-beta series: Confirmed Status in Kernel SRU Workflow snap-release-to-candidate series: New Status in Kernel SRU Workflow snap-release-to-edge series: Confirmed Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow upload-to-ppa series: Invalid Status in Kernel SRU Workflow verification-testing series: Confirmed Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Confirmed Bug description: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow backports: 1742996,1742998 derivatives: 1742999,1743000,1743001,1743002,1743004,1743006 -- swm properties -- boot-testing-requested: true phase: Promoted to proposed proposed-announcement-sent: true proposed-testing-requested: true To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1742995/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1708870] [NEW] Support for X553 Intel NIC in Xenial
Public bug reported: Hey! The Intel Atom C3000 platform comes with an integrated X553 Intel NIC. Support was added in Linux 4.11: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net- next.git/commit/?id=b3eb4e1860f35. PCI IDs are 8086:15E4 and 8086:15E5. Would it be possible to backport such support into 4.4? Redhat provided support for such chips a few months back (through DKMS): https://access.redhat.com/errata/RHEA-2017:1194. Thanks. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1708870 Title: Support for X553 Intel NIC in Xenial Status in linux package in Ubuntu: New Bug description: Hey! The Intel Atom C3000 platform comes with an integrated X553 Intel NIC. Support was added in Linux 4.11: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net- next.git/commit/?id=b3eb4e1860f35. PCI IDs are 8086:15E4 and 8086:15E5. Would it be possible to backport such support into 4.4? Redhat provided support for such chips a few months back (through DKMS): https://access.redhat.com/errata/RHEA-2017:1194. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1708870/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1460768] Re: Unable to build kernel 3.19.0-18
The symlinks are generated by debian/clean: https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/xenial/tree/debian/source/options -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1460768 Title: Unable to build kernel 3.19.0-18 Status in One Hundred Papercuts: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: There is a bug during compiling kernel version 3.19.0-18. First I executed patch file from archive linux_3.19.0-18.18.diff.gz and source https://launchpad.net/ubuntu/+source/linux/3.19.0-18.18 Then I executed make-kpkg --initrd buildpackage with attached config file. But I got a compiling error: CC [M] ubuntu/vbox/vboxguest/VBoxGuest-linux.o In file included from :0:0: ././include/linux/kconfig.h:46:1: fatal error: ./ubuntu/vbox/vboxguest/include/VBox/VBoxGuestMangling.h: No such file or directory #endif /* __LINUX_KCONFIG_H */ ^ compilation terminated. make[6]: *** [ubuntu/vbox/vboxguest/VBoxGuest-linux.o] Error 1 make[5]: *** [ubuntu/vbox/vboxguest] Error 2 make[4]: *** [ubuntu/vbox] Error 2 make[3]: *** [ubuntu] Error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1460768/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1233014] [NEW] Use CFLAGS=-grecord-gcc-switches
Public bug reported: Hi! Tools, like systemtap, need to circumvent some bugs in GCC, notably in the way it reports debugging data for highly-optimized programs. Systemtap includes workarounds but they are only reliable when the kernel is using some options. Therefore, systemtap needs to know with which option GCC was invoked. For example, LTS kernels for Precise are using GCC 4.6.3 Precise which has a bug related to -mfentry and produce incorrect offsets for debugging symbols (off by 5). Systemtap includes a workaround for this but it can only be reliably detected if it knows that -mfentry flag was requested. This can be done by using CFLAGS=-grecord-gcc-switches. Please, use it for all future release, even when the version of GCC used has no known bug. Thanks. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1233014 Title: Use CFLAGS=-grecord-gcc-switches Status in “linux” package in Ubuntu: New Bug description: Hi! Tools, like systemtap, need to circumvent some bugs in GCC, notably in the way it reports debugging data for highly-optimized programs. Systemtap includes workarounds but they are only reliable when the kernel is using some options. Therefore, systemtap needs to know with which option GCC was invoked. For example, LTS kernels for Precise are using GCC 4.6.3 Precise which has a bug related to -mfentry and produce incorrect offsets for debugging symbols (off by 5). Systemtap includes a workaround for this but it can only be reliably detected if it knows that -mfentry flag was requested. This can be done by using CFLAGS=-grecord-gcc-switches. Please, use it for all future release, even when the version of GCC used has no known bug. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233014/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1233014] Re: Use CFLAGS=-grecord-gcc-switches
No need for a log file, this is a wishlist. ** Changed in: linux (Ubuntu) Status: Incomplete = Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1233014 Title: Use CFLAGS=-grecord-gcc-switches Status in “linux” package in Ubuntu: Confirmed Bug description: Hi! Tools, like systemtap, need to circumvent some bugs in GCC, notably in the way it reports debugging data for highly-optimized programs. Systemtap includes workarounds but they are only reliable when the kernel is using some options. Therefore, systemtap needs to know with which option GCC was invoked. For example, LTS kernels for Precise are using GCC 4.6.3 Precise which has a bug related to -mfentry and produce incorrect offsets for debugging symbols (off by 5). Systemtap includes a workaround for this but it can only be reliably detected if it knows that -mfentry flag was requested. This can be done by using CFLAGS=-grecord-gcc-switches. Please, use it for all future release, even when the version of GCC used has no known bug. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233014/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
