[Kernel-packages] [Bug 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed- bionic'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-bionic -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug was erroneously marked for verification in bionic; verification is not required and verification-needed-bionic is being removed. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
** Tags removed: verification-needed-bionic ** Tags added: kernel-fixup-verification-needed-bionic -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed- bionic'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-bionic -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug was fixed in the package linux - 4.4.0-127.153 --- linux (4.4.0-127.153) xenial; urgency=medium * CVE-2018-3639 (powerpc) - powerpc/pseries: Support firmware disable of RFI flush - powerpc/powernv: Support firmware disable of RFI flush - powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code - powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again - powerpc/rfi-flush: Always enable fallback flush on pseries - powerpc/rfi-flush: Differentiate enabled and patched flush types - powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration - powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags - powerpc: Add security feature flags for Spectre/Meltdown - powerpc/pseries: Set or clear security feature flags - powerpc/powernv: Set or clear security feature flags - powerpc/64s: Move cpu_show_meltdown() - powerpc/64s: Enhance the information in cpu_show_meltdown() - powerpc/powernv: Use the security flags in pnv_setup_rfi_flush() - powerpc/pseries: Use the security flags in pseries_setup_rfi_flush() - powerpc/64s: Wire up cpu_show_spectre_v1() - powerpc/64s: Wire up cpu_show_spectre_v2() - powerpc/pseries: Fix clearing of security feature flags - powerpc: Move default security feature flags - powerpc/pseries: Restore default security feature flags on setup - SAUCE: powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit * CVE-2018-3639 (x86) - SAUCE: Clean up IBPB and IBRS control functions and macros - SAUCE: Fix up IBPB and IBRS kernel parameters documentation - SAUCE: Remove #define X86_FEATURE_PTI - x86/cpufeature: Move some of the scattered feature bits to x86_capability - x86/cpufeature: Cleanup get_cpu_cap() - x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6 - x86/cpufeatures: Add CPUID_7_EDX CPUID leaf - x86/cpufeatures: Add Intel feature bits for Speculation Control - SAUCE: x86/kvm: Expose SPEC_CTRL from the leaf - x86/cpufeatures: Add AMD feature bits for Speculation Control - x86/msr: Add definitions for new speculation control MSRs - SAUCE: x86/msr: Rename MSR spec control feature bits - x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown - x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes - x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support - x86/speculation: Add dependency - x86/cpufeatures: Clean up Spectre v2 related CPUID flags - x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel - SAUCE: x86/speculation: Move vendor specific IBRS/IBPB control code - SAUCE: x86: Add alternative_msr_write - SAUCE: x86/nospec: Simplify alternative_msr_write() - SAUCE: x86/bugs: Concentrate bug detection into a separate function - SAUCE: x86/bugs: Concentrate bug reporting into a separate function - arch: Introduce post-init read-only memory - SAUCE: x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits - SAUCE: x86/bugs, KVM: Support the combination of guest and host IBRS - SAUCE: x86/bugs: Expose /sys/../spec_store_bypass - SAUCE: x86/cpufeatures: Add X86_FEATURE_RDS - SAUCE: x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation - SAUCE: x86/bugs/intel: Set proper CPU features and setup RDS - SAUCE: x86/bugs: Whitelist allowed SPEC_CTRL MSR values - SAUCE: x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested - SAUCE: x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest - SAUCE: x86/speculation: Create spec-ctrl.h to avoid include hell - SAUCE: prctl: Add speculation control prctls - x86/process: Optimize TIF checks in __switch_to_xtra() - SAUCE: x86/process: Allow runtime control of Speculative Store Bypass - SAUCE: x86/speculation: Add prctl for Speculative Store Bypass mitigation - SAUCE: nospec: Allow getting/setting on non-current task - SAUCE: proc: Provide details on speculation flaw mitigations - SAUCE: seccomp: Enable speculation flaw mitigations - SAUCE: x86/bugs: Honour SPEC_CTRL default - SAUCE: x86/bugs: Make boot modes __ro_after_init - SAUCE: prctl: Add force disable speculation - SAUCE: seccomp: Use PR_SPEC_FORCE_DISABLE - selftest/seccomp: Fix the flag name SECCOMP_FILTER_FLAG_TSYNC - SAUCE: seccomp: Add filter flag to opt-out of SSB mitigation - SAUCE: seccomp: Move speculation migitation control to arch code - SAUCE: x86/speculation: Make "seccomp" the default mode for Speculative Store Bypass - SAUCE: x86/bugs: Rename _RDS to _SSBD - SAUCE: proc: Use underscores for SSBD in 'status' - SAUCE: Documentation/spec_ctrl: Do some minor cleanups - SAUCE: x86/bugs: Fix __ssb_select_mitigation() return type - SAUCE: x86/bugs: Make cpu_show_common() static
[Kernel-packages] [Bug 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug was fixed in the package linux - 3.13.0-149.199 --- linux (3.13.0-149.199) trusty; urgency=medium * CVE-2018-3639 (powerpc) - SAUCE: rfi-flush: update H_CPU_* macro names to upstream - SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to upstream - powerpc/pseries: Support firmware disable of RFI flush - powerpc/powernv: Support firmware disable of RFI flush - powerpc/64s: Allow control of RFI flush via debugfs - powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code - powerpc/rfi-flush: Always enable fallback flush on pseries - powerpc/rfi-flush: Differentiate enabled and patched flush types - powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags - powerpc: Add security feature flags for Spectre/Meltdown - powerpc/pseries: Set or clear security feature flags - powerpc/powernv: Set or clear security feature flags - powerpc/powernv: Use the security flags in pnv_setup_rfi_flush() - powerpc/pseries: Use the security flags in pseries_setup_rfi_flush() - powerpc/pseries: Fix clearing of security feature flags - powerpc: Move default security feature flags - powerpc/pseries: Restore default security feature flags on setup - powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit - SAUCE: powerpc/64s: Move the data access exception out-of-line * CVE-2018-3639 (x86) - arch: Introduce post-init read-only memory - SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES - SAUCE: x86: Add alternative_msr_write - x86/nospec: Simplify alternative_msr_write() - x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown - x86/bugs: Concentrate bug detection into a separate function - x86/bugs: Concentrate bug reporting into a separate function - x86/msr: Add definitions for new speculation control MSRs - x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits - x86/bugs, KVM: Support the combination of guest and host IBRS - x86/bugs: Expose /sys/../spec_store_bypass - x86/cpufeatures: Add X86_FEATURE_RDS - x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation - x86/bugs/intel: Set proper CPU features and setup RDS - x86/bugs: Whitelist allowed SPEC_CTRL MSR values - x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested - x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest - x86/speculation: Create spec-ctrl.h to avoid include hell - prctl: Add speculation control prctls - x86/process: Allow runtime control of Speculative Store Bypass - x86/speculation: Add prctl for Speculative Store Bypass mitigation - nospec: Allow getting/setting on non-current task - proc: Provide details on speculation flaw mitigations - seccomp: Enable speculation flaw mitigations - SAUCE: x86/bugs: Honour SPEC_CTRL default - x86/bugs: Make boot modes __ro_after_init - prctl: Add force disable speculation - seccomp: Use PR_SPEC_FORCE_DISABLE - seccomp: Add filter flag to opt-out of SSB mitigation - seccomp: Move speculation migitation control to arch code - x86/speculation: Make "seccomp" the default mode for Speculative Store Bypass - x86/bugs: Rename _RDS to _SSBD - proc: Use underscores for SSBD in 'status' - Documentation/spec_ctrl: Do some minor cleanups - x86/bugs: Fix __ssb_select_mitigation() return type - x86/bugs: Make cpu_show_common() static linux (3.13.0-148.197) trusty; urgency=medium * linux: 3.13.0-148.197 -proposed tracker (LP: #1769077) * CVE-2017-18208 - mm/madvise.c: fix madvise() infinite loop under special circumstances * CVE-2018-8822 - staging: ncpfs: memory corruption in ncp_read_kernel() * CVE-2017-18221 - mlock: fix mlock count can not decrease in race condition * CVE-2017-12134 - xen: fix bio vec merging * CVE-2017-18203 - dm: fix race between dm_get_from_kobject() and __dm_destroy() * CVE-2017-17449 - netlink: Add netns check on taps * CVE-2017-13220 - Bluetooth: hidp_connection_add() unsafe use of l2cap_pi() * CVE-2017-18204 - ocfs2: should wait dio before inode lock in ocfs2_setattr() * CVE-2017-13305 - KEYS: encrypted: fix buffer overread in valid_master_desc() * CVE-2017-18079 - Input: i8042 - fix crash at boot time * "ip a" command on a guest VM shows UNKNOWN status (LP: #1761534) - virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS * ibrs/ibpb fixes result in excessive kernel logging (LP: #1755627) - SAUCE: remove ibrs_dump sysctl interface -- Stefan BaderMon, 14 May 2018 16:58:50 +0200 ** Changed in: linux (Ubuntu Trusty) Status: Fix Committed => Fix Released ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-12134 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13220
[Kernel-packages] [Bug 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug was fixed in the package linux - 4.13.0-43.48 --- linux (4.13.0-43.48) artful; urgency=medium * CVE-2018-3639 (powerpc) - SAUCE: rfi-flush: update H_CPU_* macro names to upstream - SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to upstream - SAUCE: update pseries_setup_rfi_flush() capitalization to upstream - powerpc/pseries: Support firmware disable of RFI flush - powerpc/powernv: Support firmware disable of RFI flush - powerpc/64s: Allow control of RFI flush via debugfs - powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code - powerpc/rfi-flush: Always enable fallback flush on pseries - powerpc/rfi-flush: Differentiate enabled and patched flush types - powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags - powerpc: Add security feature flags for Spectre/Meltdown - powerpc/powernv: Set or clear security feature flags - powerpc/pseries: Set or clear security feature flags - powerpc/powernv: Use the security flags in pnv_setup_rfi_flush() - powerpc/pseries: Use the security flags in pseries_setup_rfi_flush() - powerpc/pseries: Fix clearing of security feature flags - powerpc: Move default security feature flags - powerpc/pseries: Restore default security feature flags on setup - powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit * CVE-2018-3639 (x86) - SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES - SAUCE: x86: Add alternative_msr_write - x86/nospec: Simplify alternative_msr_write() - x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown - x86/bugs: Concentrate bug detection into a separate function - x86/bugs: Concentrate bug reporting into a separate function - x86/msr: Add definitions for new speculation control MSRs - x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits - x86/bugs, KVM: Support the combination of guest and host IBRS - x86/bugs: Expose /sys/../spec_store_bypass - x86/cpufeatures: Add X86_FEATURE_RDS - x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation - x86/bugs/intel: Set proper CPU features and setup RDS - x86/bugs: Whitelist allowed SPEC_CTRL MSR values - x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested - x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest - x86/speculation: Create spec-ctrl.h to avoid include hell - prctl: Add speculation control prctls - x86/process: Allow runtime control of Speculative Store Bypass - x86/speculation: Add prctl for Speculative Store Bypass mitigation - nospec: Allow getting/setting on non-current task - proc: Provide details on speculation flaw mitigations - seccomp: Enable speculation flaw mitigations - SAUCE: x86/bugs: Honour SPEC_CTRL default - x86/bugs: Make boot modes __ro_after_init - prctl: Add force disable speculation - seccomp: Use PR_SPEC_FORCE_DISABLE - seccomp: Add filter flag to opt-out of SSB mitigation - seccomp: Move speculation migitation control to arch code - x86/speculation: Make "seccomp" the default mode for Speculative Store Bypass - x86/bugs: Rename _RDS to _SSBD - proc: Use underscores for SSBD in 'status' - Documentation/spec_ctrl: Do some minor cleanups - x86/bugs: Fix __ssb_select_mitigation() return type - x86/bugs: Make cpu_show_common() static * LSM Stacking prctl values should be redefined as to not collide with upstream prctls (LP: #1769263) // CVE-2018-3639 - SAUCE: LSM stacking: adjust prctl values linux (4.13.0-42.47) artful; urgency=medium * linux: 4.13.0-42.47 -proposed tracker (LP: #1769993) * arm64: fix CONFIG_DEBUG_WX address reporting (LP: #1765850) - arm64: fix CONFIG_DEBUG_WX address reporting * HiSilicon HNS NIC names are truncated in /proc/interrupts (LP: #1765977) - net: hns: Avoid action name truncation * CVE-2017-18208 - mm/madvise.c: fix madvise() infinite loop under special circumstances * CVE-2018-8822 - staging: ncpfs: memory corruption in ncp_read_kernel() * CVE-2017-18203 - dm: fix race between dm_get_from_kobject() and __dm_destroy() * CVE-2017-17449 - netlink: Add netns check on taps * CVE-2017-17975 - media: usbtv: prevent double free in error case * [8086:3e92] display becomes blank after S3 (LP: #1763271) - drm/i915/edp: Allow alternate fixed mode for eDP if available. - drm/i915/dp: rename intel_dp_is_edp to intel_dp_is_port_edp - drm/i915/dp: make is_edp non-static and rename to intel_dp_is_edp - drm/i915/edp: Do not do link training fallback or prune modes on EDP * sky2 gigabit ethernet driver sometimes stops working after lid-open resume from sleep (88E8055) (LP: #1758507) - sky2: Increase D3 delay to sky2 stops working after suspend * perf vendor events arm64: Enable JSON events for
[Kernel-packages] [Bug 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
** Tags removed: verification-needed-artful verification-needed-trusty verification-needed-xenial ** Tags added: verification-done-artful verification-done-trusty verification-done-xenial -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0:mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0:mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- artful' to 'verification-done-artful'. If the problem still exists, change the tag 'verification-needed-artful' to 'verification-failed- artful'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-artful -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0:mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- trusty' to 'verification-done-trusty'. If the problem still exists, change the tag 'verification-needed-trusty' to 'verification-failed- trusty'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-trusty -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Released Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0:mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
This bug was fixed in the package linux - 4.15.0-19.20 --- linux (4.15.0-19.20) bionic; urgency=medium * linux: 4.15.0-19.20 -proposed tracker (LP: #1766021) * Kernel 4.15.0-15 breaks Dell PowerEdge 12th Gen servers (LP: #1765232) - Revert "blk-mq: simplify queue mapping & schedule with each possisble CPU" - Revert "genirq/affinity: assign vectors to all possible CPUs" linux (4.15.0-18.19) bionic; urgency=medium * linux: 4.15.0-18.19 -proposed tracker (LP: #1765490) * [regression] Ubuntu 18.04:[4.15.0-17-generic #18] KVM Guest Kernel: meltdown: rfi/fallback displacement flush not enabled bydefault (kvm) (LP: #1765429) - powerpc/pseries: Fix clearing of security feature flags * signing: only install a signed kernel (LP: #1764794) - [Packaging] update to Debian like control scripts - [Packaging] switch to triggers for postinst.d postrm.d handling - [Packaging] signing -- switch to raw-signing tarballs - [Packaging] signing -- switch to linux-image as signed when available - [Config] signing -- enable Opal signing for ppc64el - [Packaging] printenv -- add signing options * [18.04 FEAT] Sign POWER host/NV kernels (LP: #1696154) - [Packaging] signing -- add support for signing Opal kernel binaries * Please cherrypick s390 unwind fix (LP: #1765083) - s390/compat: fix setup_frame32 * Ubuntu 18.04 installer does not detect any IPR based HDD/RAID array [S822L] [ipr] (LP: #1751813) - d-i: move ipr to storage-core-modules on ppc64el * drivers/gpu/drm/bridge/adv7511/adv7511.ko missing (LP: #1764816) - SAUCE: (no-up) rename the adv7511 drm driver to adv7511_drm * Miscellaneous Ubuntu changes - [Packaging] Add linux-oem to rebuild test blacklist. linux (4.15.0-17.18) bionic; urgency=medium * linux: 4.15.0-17.18 -proposed tracker (LP: #1764498) * Eventual OOM with profile reloads (LP: #1750594) - SAUCE: apparmor: fix memory leak when duplicate profile load linux (4.15.0-16.17) bionic; urgency=medium * linux: 4.15.0-16.17 -proposed tracker (LP: #1763785) * [18.04] [bug] CFL-S(CNP)/CNL GPIO testing failed (LP: #1757346) - [Config]: Set CONFIG_PINCTRL_CANNONLAKE=y * [Ubuntu 18.04] USB Type-C test failed on GLK (LP: #1758797) - SAUCE: usb: typec: ucsi: Increase command completion timeout value * Fix trying to "push" an already active pool VP (LP: #1763386) - SAUCE: powerpc/xive: Fix trying to "push" an already active pool VP * hisi_sas: Revert and replace SAUCE patches w/ upstream (LP: #1762824) - Revert "UBUNTU: SAUCE: scsi: hisi_sas: export device table of v3 hw to userspace" - Revert "UBUNTU: SAUCE: scsi: hisi_sas: config for hip08 ES" - scsi: hisi_sas: modify some register config for hip08 - scsi: hisi_sas: add v3 hw MODULE_DEVICE_TABLE() * Realtek card reader - RTS5243 [VEN_10EC_5260] (LP: #1737673) - misc: rtsx: Move Realtek Card Reader Driver to misc - updateconfigs for Realtek Card Reader Driver - misc: rtsx: Add support for RTS5260 - misc: rtsx: Fix symbol clashes * Mellanox [mlx5] [bionic] UBSAN: Undefined behaviour in ./include/linux/net_dim.h (LP: #1763269) - net/mlx5e: Fix int overflow * apparmor bug fixes for bionic (LP: #1763427) - apparmor: fix logging of the existence test for signals - apparmor: make signal label match work when matching stacked labels - apparmor: audit unknown signal numbers - apparmor: fix memory leak on buffer on error exit path - apparmor: fix mediation of prlimit * dangling symlinks to loaded apparmor policy (LP: #1755563) // apparmor bug fixes for bionic (LP: #1763427) - apparmor: fix dangling symlinks to policy rawdata after replacement * [OPAL] Assert fail: core/mem_region.c:447:lock_held_by_me(>free_list_lock) (LP: #1762913) - powerpc/watchdog: remove arch_trigger_cpumask_backtrace * [LTC Test] Ubuntu 18.04: tm_trap_test failed on P8 compat mode guest (LP: #1762928) - powerpc/tm: Fix endianness flip on trap * Add support for RT5660 codec based sound cards on Baytrail (LP: #1657674) - SAUCE: (no-up) ASoC: Intel: Support machine driver for RT5660 on Baytrail - SAUCE: (no-up) ASoC: rt5660: Add ACPI support - SAUCE: (no-up): ASoC: Intel: bytcr-rt5660: Add MCLK, quirks - [Config] CONFIG_SND_SOC_INTEL_BYTCR_RT5660_MACH=m, CONFIG_SND_SOC_RT5660=m * /dev/ipmi enumeration flaky on Cavium Sabre nodes (LP: #1762812) - i2c: xlp9xx: return ENXIO on slave address NACK - i2c: xlp9xx: Handle transactions with I2C_M_RECV_LEN properly - i2c: xlp9xx: Check for Bus state before every transfer - i2c: xlp9xx: Handle NACK on DATA properly * [18.04 FEAT] Add kvm_stat from kernel tree (LP: #1734130) - tools/kvm_stat: simplify the sortkey function - tools/kvm_stat: use a namedtuple for storing the values - tools/kvm_stat: use a more pythonic way to iterate over dictionaries - tools/kvm_stat:
[Kernel-packages] [Bug 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
** Changed in: linux (Ubuntu Artful) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Trusty) Status: In Progress => Fix Committed -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Committed Status in linux source package in Trusty: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0:mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
** Changed in: linux (Ubuntu Bionic) Status: In Progress => Fix Committed -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: Fix Committed Status in linux source package in Trusty: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Artful: In Progress Status in linux source package in Bionic: Fix Committed Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0:mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
** Description changed: + + [Impact] + + "ip a" command on a guest VM shows UNKNOWN status. + + [Test Case] + + * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. + * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: + + 2: eth0:mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 + . + + [Regression Potential] + + * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] + * The patch has been first accepted in net-next, then move into Linus's git. + + [1] - VIRTIO_NET_F_STATUS + Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. + + [Other Info] + + * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 + + * Net-next: + https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe + + [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Artful: In Progress Status in linux source package in Bionic: In Progress Bug description: [Impact] "ip a" command on a guest VM shows UNKNOWN status. [Test Case] * Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK. * Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example: 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 . [Regression Potential] * Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1] * The patch has been first accepted in net-next, then move into Linus's git. [1] - VIRTIO_NET_F_STATUS Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config. [Other Info] * Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 * Net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe [Original Description] It has been brought to our attention the following bug : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at
[Kernel-packages] [Bug 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
** Also affects: linux (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Trusty) Status: New => In Progress ** Changed in: linux (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Trusty) Assignee: (unassigned) => Eric Desrochers (slashd) -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Artful: In Progress Status in linux source package in Bionic: In Progress Bug description: It has been brought to my attention the following : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
For qemu and upstream DPDK, support is present for the VIRTIO_NET_F_STATUS capability, and as such should not experience the "UNKNOWN" operstate issue; jvosburgh checked qemu and don't see this issue when running it, but haven't set up DPDK to verify it's behavior. The opencontrail vrouter source code does not support VIRTIO_NET_F_STATUS, which dovetails with the prior analysis that suggests that this lack of support would lead to the operstate UNKNOWN. jvosburgh also examined the virtio specification itself. It indicates that if VIRTIO_NET_F_STATUS is not available, the "link should be assumed active." ** Tags added: sts -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Artful: In Progress Status in linux source package in Bionic: In Progress Bug description: It has been brought to my attention the following : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+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 1761534] Re: "ip a" command on a guest VM shows UNKNOWN status
https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718 ** Description changed: - Environment: The guest VM is using a canonical ubuntu image, and the - eth0 is a virtio-net adaptor, running on DPDK. + It has been brought to my attention the following : + + + Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. - static inline bool netif_oper_up(const struct net_device *dev) - { - return (dev->operstate == IF_OPER_UP || - dev->operstate == IF_OPER_UNKNOWN /* backward compat */); - } + static inline bool netif_oper_up(const struct net_device *dev) + { + return (dev->operstate == IF_OPER_UP || + dev->operstate == IF_OPER_UNKNOWN /* backward compat */); + } Code Ref: - 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 - 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 - 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt + 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 + 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 + 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt - Now, for traditional kernel mode network adapter drivers, this state is - supposed to be manipulated by the driver. And we can safely assume that - most current kernel model drivers do keep this updated. + Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. + -- 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/1761534 Title: "ip a" command on a guest VM shows UNKNOWN status Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Artful: In Progress Status in linux source package in Bionic: In Progress Bug description: It has been brought to my attention the following : Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK. Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free- electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about. static inline bool netif_oper_up(const struct net_device *dev) { return (dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN /* backward compat */); } Code Ref: 1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739 2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468 3. https://www.kernel.org/doc/Documentation/networking/operstates.txt Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761534/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe :