Activity log for bug #1761534

Date Who What changed Old value New value Message
2018-04-05 15:57:37 Eric Desrochers bug added bug
2018-04-05 15:58:38 Eric Desrochers tags sts
2018-04-05 15:59:34 Eric Desrochers linux (Ubuntu): assignee Eric Desrochers (slashd)
2018-04-05 15:59:37 Eric Desrochers linux (Ubuntu): status New In Progress
2018-04-05 15:59:40 Eric Desrochers linux (Ubuntu): importance Undecided Medium
2018-04-05 15:59:48 Eric Desrochers nominated for series Ubuntu Bionic
2018-04-05 15:59:48 Eric Desrochers bug task added linux (Ubuntu Bionic)
2018-04-05 15:59:48 Eric Desrochers nominated for series Ubuntu Xenial
2018-04-05 15:59:48 Eric Desrochers bug task added linux (Ubuntu Xenial)
2018-04-05 15:59:48 Eric Desrochers nominated for series Ubuntu Artful
2018-04-05 15:59:48 Eric Desrochers bug task added linux (Ubuntu Artful)
2018-04-05 15:59:58 Eric Desrochers linux (Ubuntu Artful): assignee Eric Desrochers (slashd)
2018-04-05 16:00:00 Eric Desrochers linux (Ubuntu Xenial): assignee Eric Desrochers (slashd)
2018-04-05 16:00:01 Eric Desrochers linux (Ubuntu Artful): importance Undecided Medium
2018-04-05 16:00:03 Eric Desrochers linux (Ubuntu Xenial): importance Undecided Medium
2018-04-05 16:00:06 Eric Desrochers linux (Ubuntu Artful): status New In Progress
2018-04-05 16:00:08 Eric Desrochers linux (Ubuntu Xenial): status New In Progress
2018-04-05 16:02:23 Eric Desrochers description 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. 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. ------------------------------------------------
2018-04-05 16:29:43 Eric Desrochers nominated for series Ubuntu Trusty
2018-04-05 16:29:43 Eric Desrochers bug task added linux (Ubuntu Trusty)
2018-04-05 16:29:50 Eric Desrochers linux (Ubuntu Trusty): status New In Progress
2018-04-05 16:29:52 Eric Desrochers linux (Ubuntu Trusty): importance Undecided Medium
2018-04-05 16:29:54 Eric Desrochers linux (Ubuntu Trusty): assignee Eric Desrochers (slashd)
2018-04-05 18:05:48 Eric Desrochers 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. ------------------------------------------------ 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. ------------------------------------------------
2018-04-05 18:09:59 Eric Desrochers bug added subscriber Jay Vosburgh
2018-04-05 19:38:39 Eric Desrochers 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. ------------------------------------------------ [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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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. ------------------------------------------------
2018-04-09 20:57:56 Seth Forshee linux (Ubuntu Bionic): status In Progress Fix Committed
2018-04-19 16:41:24 Stefan Bader linux (Ubuntu Artful): status In Progress Fix Committed
2018-04-19 16:41:28 Stefan Bader linux (Ubuntu Xenial): status In Progress Fix Committed
2018-04-19 16:41:31 Stefan Bader linux (Ubuntu Trusty): status In Progress Fix Committed
2018-04-23 23:51:27 Launchpad Janitor linux (Ubuntu Bionic): status Fix Committed Fix Released
2018-04-23 23:51:27 Launchpad Janitor cve linked 2017-5715
2018-04-23 23:51:27 Launchpad Janitor cve linked 2017-5753
2018-04-23 23:51:27 Launchpad Janitor cve linked 2017-5754
2018-04-25 14:33:59 Brad Figg tags sts sts verification-needed-trusty
2018-04-27 19:02:29 Brad Figg tags sts verification-needed-trusty sts verification-needed-artful verification-needed-trusty
2018-04-27 19:12:16 Brad Figg tags sts verification-needed-artful verification-needed-trusty sts verification-needed-artful verification-needed-trusty verification-needed-xenial
2018-05-04 12:24:02 Eric Desrochers tags sts verification-needed-artful verification-needed-trusty verification-needed-xenial sts verification-done-artful verification-done-trusty verification-done-xenial
2018-05-21 23:59:29 Launchpad Janitor linux (Ubuntu Trusty): status Fix Committed Fix Released
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-12134
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-13220
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-13305
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-17449
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-18079
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-18203
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-18204
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-18208
2018-05-21 23:59:29 Launchpad Janitor cve linked 2017-18221
2018-05-21 23:59:29 Launchpad Janitor cve linked 2018-3639
2018-05-21 23:59:29 Launchpad Janitor cve linked 2018-8822
2018-05-22 00:00:38 Launchpad Janitor linux (Ubuntu Xenial): status Fix Committed Fix Released
2018-05-22 00:00:38 Launchpad Janitor cve linked 2017-16995
2018-05-22 00:00:38 Launchpad Janitor cve linked 2017-17862
2018-05-22 00:00:38 Launchpad Janitor cve linked 2018-1000004
2018-05-22 00:04:32 Launchpad Janitor linux (Ubuntu Artful): status Fix Committed Fix Released
2018-05-22 00:04:32 Launchpad Janitor cve linked 2017-17975
2019-02-14 13:11:26 Brad Figg tags sts verification-done-artful verification-done-trusty verification-done-xenial sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic
2019-02-14 15:51:38 Andy Whitcroft tags sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial
2019-02-14 16:09:31 Brad Figg tags kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic
2019-02-14 16:15:47 Andy Whitcroft tags kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial
2019-02-14 16:18:42 Andy Whitcroft tags kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-bionic verification-done-trusty verification-done-xenial