Bug#966477: WARNING: at net/ipv4/tcp_input.c:2799 tcp_fastretrans_alert
Package: src:linux Version: 4.19.118-2+deb10u1 Severity: normal Dear Maintainer, During my semi-regular auditing of the system log, I noticed the below warning and stack trace. I have no idea what may have caused it, and the system has been operating normally for weeks (continuous uptime) and appears to still be operating normally. Regards, Aidan Gauland Note: Some sensitive apparmor audit lines have been removed from the kernel log here. -- Package-specific info: ** Version: Linux version 4.19.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) ** Command line: BOOT_IMAGE=/BOOT/debian@/vmlinuz-4.19.0-9-amd64 root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian quiet ** Tainted: PWOE (12801) * Proprietary module has been loaded. * Taint on warning. * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: [2513851.122581] kauditd_printk_skb: 10 callbacks suppressed [2693086.705995] [ cut here ] [2693086.706047] WARNING: CPU: 3 PID: 0 at net/ipv4/tcp_input.c:2799 tcp_fastretrans_alert.cold.86+0x19/0x74 [2693086.706049] Modules linked in: nft_reject_inet nft_reject nft_log nft_ct rpcsec_gss_krb5 nf_tables_set nf_log_ipv6 ip6_tables ip6t_REJECT nf_reject_ipv6 nf_log_ipv4 nf_log_common nft_limit nft_counter xt_LOG xt_limit xt_comment xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c crc32c_generic nft_compat nf_tables nfnetlink nls_ascii nls_cp437 vfat fat intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm ast ttm irqbypass drm_kms_helper crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate mxm_wmi drm sg evdev joydev intel_uncore mei_me efi_pstore ipmi_si mei intel_rapl_perf pcspkr efivars pcc_cpufreq iTCO_wdt ipmi_devintf iTCO_vendor_support intel_pch_thermal ioatdma ipmi_msghandler wmi button acpi_pad [2693086.706102] nfsd auth_rpcgss nfs_acl lockd grace sunrpc efivarfs ip_tables x_tables autofs4 zfs(POE) zunicode(POE) zlua(POE) zavl(POE) icp(POE) zcommon(POE) znvpair(POE) spl(OE) hid_generic usbhid hid sd_mod crc32c_intel ahci xhci_pci libahci ehci_pci xhci_hcd ehci_hcd libata ixgbe aesni_intel scsi_mod igb usbcore aes_x86_64 crypto_simd cryptd glue_helper lpc_ich i2c_i801 i2c_algo_bit mfd_core dca usb_common mdio [2693086.706142] CPU: 3 PID: 0 Comm: swapper/3 Tainted: P W OE 4.19.0-9-amd64 #1 Debian 4.19.118-2+deb10u1 [2693086.706144] Hardware name: Supermicro Super Server/X10SDV-4C+-TLN4F, BIOS 2.1 11/22/2019 [2693086.706150] RIP: 0010:tcp_fastretrans_alert.cold.86+0x19/0x74 [2693086.706154] Code: c7 48 f0 c3 96 e8 5a a8 a8 ff 0f 0b e9 ea ad ff ff 48 c7 c7 48 f0 c3 96 48 89 4c 24 10 44 89 4c 24 08 89 14 24 e8 3a a8 a8 ff <0f> 0b 8b 14 24 44 8b 4c 24 08 48 8b 4c 24 10 e9 a9 b2 ff ff 48 c7 [2693086.706157] RSP: 0018:93d39fac3b10 EFLAGS: 00010246 [2693086.706160] RAX: 0024 RBX: 93d374724400 RCX: [2693086.706163] RDX: RSI: 00f6 RDI: 0300 [2693086.706165] RBP: R08: 0011c6ad R09: 0004 [2693086.706166] R10: R11: 0001 R12: 0001 [2693086.706168] R13: 93d39fac3ba8 R14: R15: 0001 [2693086.706172] FS: () GS:93d39fac() knlGS: [2693086.706174] CS: 0010 DS: ES: CR0: 80050033 [2693086.706176] CR2: 7f014aa2b000 CR3: 0007e840a001 CR4: 003606e0 [2693086.706179] DR0: DR1: DR2: [2693086.706181] DR3: DR6: fffe0ff0 DR7: 0400 [2693086.706182] Call Trace: [2693086.706186] [2693086.706194] tcp_ack+0x95d/0x1120 [2693086.706202] ? sched_clock+0x5/0x10 [2693086.706208] ? tcp_write_xmit+0x3cf/0x1000 [2693086.706214] tcp_rcv_established+0x327/0x650 [2693086.706219] tcp_v4_do_rcv+0x12a/0x1e0 [2693086.706223] tcp_v4_rcv+0xb1a/0xc20 [2693086.706240] ? nft_do_chain_inet+0x8a/0x100 [nf_tables] [2693086.706248] ip_local_deliver_finish+0x63/0x1e0 [2693086.706253] ip_local_deliver+0xe0/0xf0 [2693086.706258] ? ip_sublist_rcv_finish+0x80/0x80 [2693086.706263] ip_rcv+0xbc/0xd0 [2693086.706268] ? ip_rcv_finish_core.isra.18+0x360/0x360 [2693086.706275] __netif_receive_skb_one_core+0x52/0x70 [2693086.706280] netif_receive_skb_internal+0x2f/0xa0 [2693086.706285] napi_gro_receive+0xba/0xe0 [2693086.706303] igb_poll+0x481/0xeb0 [igb] [2693086.706310] net_rx_action+0x149/0x3b0 [2693086.706318] __do_softirq+0xde/0x2d8 [2693086.706325] irq_exit+0xba/0xc0 [2693086.706330] do_IRQ+0x7f/0xe0 [2693086.706335] common_interrupt+0xf/0xf [2693086.706337] [2693086.706342] RIP: 0010:cpuidle_enter_state+0xb9/0x320 [2693086.706345] Code: e8 dc c0 b0 ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 ae b0 b6
Re: Next Kernel update for Buster
vincent.deb...@free.fr writes: > On 2020-07-28T17:47+0200, gianluca wrote: >>On 7/28/20 3:35 PM, Salvatore Bonaccorso wrote: Have a look at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35 >>>The next point release for buster (10.5) will contain an update of >>>src:linux to 4.19.132, see >>>https://lists.debian.org/debian-stable-announce/2020/07/msg1.html >> >>that's a very good news to know. What about timeline for 10.5?? >>;-) > > It should be available on Saturday August 1st. Gianluca, P.S. if you're interested in participating in testing packages queued for the next point release, see https://www.debian.org/releases/proposed-updates If you're exclusively interested in testing kernel proposed-updates, then you can use APT pinning to configure this: https://wiki.debian.org/AptConfiguration To get this effect I'd add a rule to pin proposed-updates to a lower priority than stable, stable-updates, and debian-security, and then add a rule to make kernel-related packages from proposed-updates evaluate to a higher priority. There might be better ways, and this is just the method I'd use ;-) Cheers, Nicholas signature.asc Description: PGP signature
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards
Package: src:linux Version: 5.7.6-1 Severity: normal Tags: upstream X-Debbugs-Cc: t...@mirbsd.de I’m using setsockopt to set the traffic class on sending and receive it in control messages on receiving, for both IPv4 and IPv6. The relevant documentation is the ip(7) manpage and, because the ipv6(7) manpage doesn’t contain it, RFC3542. For the receiving side, the corresponding socket options are: • IPPROTO_IP ⇒ IP_RECVTOS, with an int argument 1 (as in the manpage) • IPPROTO_IPV6 ⇒ IPV6_TCLASS, with an int argument 1 (as in the RFC) The receiving CMSG is then supposed to contain the traffic class octet as first byte in the corresponding CMSG_DATA: IP_RECVTOS (since Linux 2.2) If enabled, the IP_TOS ancillary message is passed with incoming packets. It contains a byte which specifies the Type of Ser‐ vice/Precedence field of the packet header. … and… In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_TCLASS, and the first byte of cmsg_data[] will be the first byte of the integer traffic class. However, Linux has net/ipv6/datagram.c… int tclass = ipv6_get_dsfield(ipv6_hdr(skb)); put_cmsg(msg, SOL_IPV6, IPV6_TCLASS, sizeof(tclass), ); … and net/ipv6/ipv6_sockglue.c… int tclass = (int)ip6_tclass(np->rcv_flowinfo); put_cmsg(, SOL_IPV6, IPV6_TCLASS, sizeof(tclass), ); … both setting them as int, breaking standards/documentation-compliant code on all big endian platforms. Same in net/ipv4/ip_sockglue.c… int tos = inet->rcv_tos; put_cmsg(, SOL_IP, IP_TOS, sizeof(tos), ); … in one place, but… put_cmsg(msg, SOL_IP, IP_TOS, 1, _hdr(skb)->tos); … in ip_cmsg_recv_tos(), yielding inconsistent results for IPv4(!). For the sending side, we use: • IPPROTO_IP, IP_TOS, with an argument… • IPPROTO_IPV6, IPV6_TCLASS, with an argument… This is funny. The documentation says to use a byte for IPv4… IP_TOS (since Linux 1.0) Set or receive the Type-Of-Service (TOS) field that is sent with every IP packet originating from this socket. It is used to prioritize packets on the network. TOS is a byte. There are … and setsockopt works with a byte argument, but for IPv6, using a byte causes EINVAL (but this is because RFC3542 says int, overriding the itojun draft which said byte). Looking at the kernel code, IP_TOS indeed reads a byte if the size given is less than 4, an int otherwise… except bpf_setsockopt, which expects an int. OK, should be no problem for my userspace code. IPV6_TCLASS always expects an int. Unexpected but apparently okay wrt. the documentation. tl;dr: Receiving traffic class values from IP traffic is broken on big endian platforms. I place the following suggestion for discussion, to achieve maximum portability: put 4 bytes into the CMSG for both IPv4 and IPv6, where the first and fourth byte are, identically, traffic class, second and third 0. Please forward this upstream. Thanks! -- Package-specific info: ** Version: Linux version 5.7.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 (2020-06-24) ** Command line: BOOT_IMAGE=/vmlinuz-5.7.0-1-amd64 root=/dev/sda4 ro rootdelay=5 syscall.x32=y vsyscall=emulate net.ifnames=0 kaslr pcie_aspm=force consoleblank=0 ** Tainted: W (512) * kernel issued warning ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: LENOVO product_name: 7673AG4 product_version: ThinkPad X61 chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 7NET30WW (1.11 ) board_vendor: LENOVO board_name: 7673AG4 board_version: Not Available ** Loaded modules: ufs hfs dm_mod loop netlink_diag snd_seq_dummy cdc_acm ctr aes_generic libaes crypto_simd cryptd glue_helper ccm cpufreq_conservative cpufreq_userspace cpufreq_powersave binfmt_misc nft_counter nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nft_compat nf_tables x_tables nfnetlink tun snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_hda_codec_analog snd_hda_codec_generic ppdev iwl4965 coretemp snd_hda_intel iwlegacy kvm_intel snd_intel_dspcfg pcmcia kvm snd_hda_codec mac80211 snd_hda_core snd_hwdep snd_pcm_oss irqbypass snd_mixer_oss cfg80211 serio_raw pcspkr snd_pcm sg iTCO_wdt yenta_socket iTCO_vendor_support thinkpad_acpi pcmcia_rsrc watchdog pcmcia_core snd_timer libarc4 nvram ledtrig_audio snd soundcore ac rfkill parport_pc evdev parport button acpi_cpufreq ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common ata_generic i915 ata_piix sdhci_pci i2c_algo_bit ahci
Re: Next Kernel update for Buster
On 2020-07-28T17:47+0200, gianluca wrote: On 7/28/20 3:35 PM, Salvatore Bonaccorso wrote: Have a look at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35 The next point release for buster (10.5) will contain an update of src:linux to 4.19.132, see https://lists.debian.org/debian-stable-announce/2020/07/msg1.html that's a very good news to know. What about timeline for 10.5?? ;-) It should be available on Saturday August 1st. signature.asc Description: PGP signature
Re: Next Kernel update for Buster
On 7/28/20 3:35 PM, Salvatore Bonaccorso wrote: Have a look at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35 The next point release for buster (10.5) will contain an update of src:linux to 4.19.132, see https://lists.debian.org/debian-stable-announce/2020/07/msg1.html that's a very good news to know. What about timeline for 10.5?? ;-) Regards, -- Eurek s.r.l. | Electronic Engineering| http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212
Re: Next Kernel update for Buster
Ciao Gianluca, On Tue, Jul 28, 2020 at 02:58:53PM +0200, gianluca wrote: > Hello, > I was wondering if there is any chance to have a better kernel from the > 4.19.129 or greater. > > I am asking this, mainly because of the BUG correction on NILFS2 Garbage > Collector as my systems are using NILFS2 as rootfs and at the moment they > are unable to boot off a nilfs2-formatted disk. > > Have a look at: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35 > > > At the moment the only workaround I have found is using an ext4-formatted > disk, but it is merely temporary. The next point release for buster (10.5) will contain an update of src:linux to 4.19.132, see https://lists.debian.org/debian-stable-announce/2020/07/msg1.html . Regards, Salvatore
Next Kernel update for Buster
Hello, I was wondering if there is any chance to have a better kernel from the 4.19.129 or greater. I am asking this, mainly because of the BUG correction on NILFS2 Garbage Collector as my systems are using NILFS2 as rootfs and at the moment they are unable to boot off a nilfs2-formatted disk. Have a look at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35 At the moment the only workaround I have found is using an ext4-formatted disk, but it is merely temporary. Best regards, Gianluca Renzi -- Eurek s.r.l. | Electronic Engineering| http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212
Bug#966420: linux-image-4.19.0-9-amd64: Freezing when NMI watchdog detect hard LOCKUP
Package: src:linux Version: 4.19.118-2+deb10u1 Severity: important Dear Maintainer, -- Package-specific info: ** Version: Linux version 4.19.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64 root=UUID=72305f04-c6f2-4c34-9ed6-5b5a5080832c ro quiet ** Tainted: OE (12288) * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: [ 2877.834099] RAX: RBX: 029a8b67a18b RCX: 941fa7a9cd40 [ 2877.834101] RDX: RSI: 029a8b67a18b RDI: 941fa7a95f40 [ 2877.834102] RBP: R08: 029a8b67a18b R09: 029a8b2a988b [ 2877.834104] R10: 003d0900 R11: 029a8b2a988b R12: 0015be81 [ 2877.834105] R13: 9e421080 R14: 029a8b67a18b R15: 941fa7a9cdf8 [ 2877.834107] FS: 7f22241d2b10() GS:941fa7a8() knlGS: [ 2877.834108] CS: 0010 DS: ES: CR0: 80050033 [ 2877.834110] CR2: 7fa69cf0cff0 CR3: 0001f96f4000 CR4: 06e0 [ 2877.834110] Call Trace: [ 2877.834111] [ 2877.834112] clockevents_program_event+0x54/0xf0 [ 2877.834114] hrtimer_interrupt+0x12e/0x220 [ 2877.834115] smp_apic_timer_interrupt+0x6a/0x140 [ 2877.834116] apic_timer_interrupt+0xf/0x20 [ 2877.834117] [ 2877.834118] RIP: 0033:0x7f22b8786843 [ 2877.834121] Code: 00 44 0f b6 84 24 a6 02 00 00 44 0f b6 9c 24 a7 02 00 00 44 0f b6 94 24 ab 02 00 00 44 0f b6 8c 24 af 02 00 00 42 33 74 85 00 <42> 8b 0c 93 42 33 14 9b 44 0f b6 84 24 a3 02 00 00 89 54 24 40 31 [ 2877.834122] RSP: 002b:7f22241d25d0 EFLAGS: 0282 ORIG_RAX: ff13 [ 2877.834125] RAX: 6f7fc827 RBX: 7f22b88d87c0 RCX: [ 2877.834126] RDX: 84b8794e RSI: ef9782b9 RDI: 78e074d5 [ 2877.834128] RBP: 7f22b88d8bc0 R08: 0036 R09: 005b [ 2877.834129] R10: 000d R11: 0032 R12: 7f22b88d8fc0 [ 2877.834130] R13: 7f22b88d93c0 R14: 7f22b88da3c0 R15: 7f22b88d9fc0 [ 2877.834186] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 [ 2877.834189] Modules linked in: tun rfkill vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc snd_usb_audio uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev snd_usbmidi_lib media snd_rawmidi snd_seq_device snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core edac_mce_amd kvm_amd ccp snd_hwdep serio_raw snd_pcm rng_core snd_timer kvm snd sg sp5100_tco pcspkr irqbypass soundcore wmi_bmof evdev k10temp pcc_cpufreq acpi_cpufreq squashfs zstd_decompress xxhash loop cuse fuse ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp sunrpc libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 hid_generic usbhid [ 2877.834233] hid amdgpu chash gpu_sched mfd_core sr_mod cdrom sd_mod radeon ohci_pci i2c_algo_bit ata_generic ttm pata_atiixp ohci_hcd ahci ehci_pci drm_kms_helper libahci libata r8169 ehci_hcd firewire_ohci drm realtek libphy usbcore scsi_mod i2c_piix4 firewire_core crc_itu_t usb_common wmi button [ 2877.834254] CPU: 1 PID: 1726 Comm: kswapd0 Tainted: G OE 4.19.0-9-amd64 #1 Debian 4.19.118-2+deb10u1 [ 2877.834257] Hardware name: Gigabyte Technology Co., Ltd. GA-880GM-UD2H/GA-880GM-UD2H, BIOS F8 10/11/2010 [ 2877.834258] RIP: 0010:ktime_get+0x7d/0xa0 [ 2877.834261] Code: 51 01 48 21 d0 48 d1 ea 48 f7 d2 48 85 c2 8b 15 f9 bd 51 01 48 0f 45 c5 45 3b 65 00 74 0e 45 8b 65 00 41 f6 c4 01 74 a9 f3 90 f2 48 0f af c2 48 01 f0 48 d3 e8 48 01 d8 5b 5d 41 5c 41 5d c3 [ 2877.834263] RSP: :941fa7a43f38 EFLAGS: 0002 [ 2877.834265] RAX: RBX: 029a8b67a18b RCX: 941fa7a5cd00 [ 2877.834267] RDX: RSI: 029a8b67a18b RDI: 941fa7a55f40 [ 2877.834268] RBP: R08: 029a8b67a18b R09: 029a8b2a988b [ 2877.834270] R10: 003d0900 R11: 029a8b2a988b R12: 0015be81 [ 2877.834271] R13: 9e421080 R14: 029a8b67a18b R15: 941fa7a5cdf8 [ 2877.834273] FS: 7f222440ab10() GS:941fa7a4() knlGS: [ 2877.834274] CS: 0010 DS: ES: CR0: 80050033 [ 2877.834275] CR2: 7fff50347fd8 CR3: 0001f96f4000 CR4: 06e0 [ 2877.834276] Call Trace: [ 2877.834277] [ 2877.834278] clockevents_program_event+0x54/0xf0 [ 2877.834280] hrtimer_interrupt+0x12e/0x220 [ 2877.834281] smp_apic_timer_interrupt+0x6a/0x140 [ 2877.834282] apic_timer_interrupt+0xf/0x20 [ 2877.834282] [ 2877.834283] RIP: 0033:0x7f22241d4ee4 [ 2877.834287] Code: f3 0f e6 51 10 f3 0f e6 59 18 f3 0f e6 61 20 f3 0f e6 69 28 f3 0f e6 71 30 f3 0f e6 79 38 41 0f 54 e5 41 0f 54 ed 41 0f 54 f5 <41> 0f 54 fd 41
