dpdk 18.11.2-4 ADT test failure with linux 5.4.0-1.2 - MRE 18.11.3 to E/D - 17.11.7 to B

[Seth Forshee]

This bug tracks an update for the DPDK packages, version 18.11.3.

This update includes bugfixes only following the SRU policy exception defined at https://wiki.ubuntu.com/StableReleaseUpdates/DPDK.

[Impact]

Stable release update so not directly applicable; see the exception policy document.

[Major Changes]

Many bugfixes, but no individual "major" change as it isn't a feature release.
=> http://mails.dpdk.org/archives/announce/2019-October/000283.html

[Test Plan]

See https://wiki.ubuntu.com/StableReleaseUpdates/DPDK#SRU_TestVerify
TODO: attach a log of executing said tests from a ppa with the upload
TODO: if there are any non passing tests - explain why that is ok in this case.
(This will be done once in proposed)

[Regression Potential]

Upstream performs extensive testing before release, giving us a high degree of confidence in the general case. There problems are most likely to manifest in Ubuntu-specific integrations, such as in relation to the versions of dependencies available and other packaging-specific matters.

No further specific regressions come to my mind by reading the changelog.

Testing failed on:
    amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/d/dpdk/20191016_150105_5be2e@/log.gz
    arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/d/dpdk/20191016_153833_5be2e@/log.gz
    ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/d/dpdk/20191016_150934_5be2e@/log.gz

[Christian Ehrhardt  (paelzer)]

Thanks Seth for the report!

The issue is (as usual) a DKMS build against the new kernel version.

I know - and thanks you for that - that you do those checks in advance.
Could you outline the expected timing and target releases for this kernel (including HWEs) so that I know the deadlines to fix this?

THe 5.4-rc3 at https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4-rc3/ seems to lack full headers.
With both packages installed I get broken symlinks like

/usr/src/linux-headers-5.4.0-050400rc3-generic/... -> ../linux-headers-5.4.0-050400rc3
The latter doesn't exist.
Might be the reason for:
  ERROR (dkms apport): kernel package linux-headers-5.4.0-050400rc3-generic is not supported

Do you have another place to fetch a 5.4 kernel for the full DKMS log, to then identify the upstream patch (if it exists)?

[Cheyenne Wills (ccwills)]

I'm running into the same problem trying to build a module. The Makefile in /usr/src/linux-headers-5.4.0-050400rc3-generic is a broken symlink.

It appears that none of the .deb files in https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4-rc3/ (all or amd64) contain the Makefile.

for i in *.deb;do echo $i;dpkg -c $i|grep Makefile;done
linux-headers-5.4.0-050400rc3_5.4.0-050400rc3.201910132031_all.deb
linux-headers-5.4.0-050400rc3-generic_5.4.0-050400rc3.201910132031_amd64.deb
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/Makefile -> ../linux-headers-5.4.0-050400rc3/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/arch/x86/Makefile -> ../../../linux-headers-5.4.0-050400rc3/arch/x86/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/arch/x86/Makefile.um -> ../../../linux-headers-5.4.0-050400rc3/arch/x86/Makefile.um
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/arch/x86/Makefile_32.cpu -> ../../../linux-headers-5.4.0-050400rc3/arch/x86/Makefile_32.cpu
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/arch/x86/entry/Makefile -> ../../../../linux-headers-5.4.0-050400rc3/arch/x86/entry/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/arch/x86/entry/syscalls/Makefile -> ../../../../../linux-headers-5.4.0-050400rc3/arch/x86/entry/syscalls/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/arch/x86/kernel/Makefile -> ../../../../linux-headers-5.4.0-050400rc3/arch/x86/kernel/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/arch/x86/tools/Makefile -> ../../../../linux-headers-5.4.0-050400rc3/arch/x86/tools/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/kernel/Makefile -> ../../linux-headers-5.4.0-050400rc3/kernel/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/scripts/Makefile -> ../../linux-headers-5.4.0-050400rc3/scripts/Makefile
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/scripts/Makefile.asm-generic -> ../../linux-headers-5.4.0-050400rc3/scripts/Makefile.asm-generic
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/scripts/Makefile.build -> ../../linux-headers-5.4.0-050400rc3/scripts/Makefile.build
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/scripts/Makefile.clean -> ../../linux-headers-5.4.0-050400rc3/scripts/Makefile.clean
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/scripts/Makefile.dtbinst -> ../../linux-headers-5.4.0-050400rc3/scripts/Makefile.dtbinst
lrwxrwxrwx root/root 0 2019-10-14 00:43 ./usr/src/linux-headers-5.4.0-050400rc3-generic/scripts/Makefile.extrawarn -> ../../linux-headers-5.4.0-050400rc3/scripts/...

[Christian Ehrhardt  (paelzer)]

[23:45] <Cheyenne> I'm trying to perform a test build against a 5.4 mainline kernel, it appears that the Makefile is missing from the linux headers (it's a broken symlink)
[23:45] <Cheyenne> I'm pulling the linux stuff from: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4-rc3/
[23:46] <Cheyenne> (the test build is for a linux module)
[23:51] <Cheyenne> looks like I might have found a related bug: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1848585
[23:51] <ubot5> Launchpad bug 1848585 in dpdk (Ubuntu) "dpdk 18.11.2-4 ADT test failure with linux 5.4.0-1.2" [Undecided,Incomplete]
[23:57] <-- chrisccoulson (~chrisccou@ubuntu/member/chrisccoulson) has left this server (Ping timeout: 240 seconds).
[00:03] --> ricotz_ (~ricotz@ubuntu/member/ricotz) has joined this channel.
[00:05] <apw> Cheyenne, what packages specifically did you install
[00:06] <-- ricotz (~ricotz@ubuntu/member/ricotz) has left this server (Ping timeout: 245 seconds).
[00:13] <Cheyenne> I installed all the all.deb and amd64.deb packages from the above link
[00:13] <-- cgregan (~cgregan@ubuntu/member/cgregan) has left this server (Remote host closed the connection).
[00:14] <Cheyenne> The code I'm trying to build is a kernel module that is outside the linux tree
[00:15] <Cheyenne> (the actual failure at this point is one of the configure tests -- that tests kernel module builds)
[00:15] <-- ricotz_ (~ricotz@ubuntu/member/ricotz) has left this server (Quit: Leaving).
[00:18] <Cheyenne> (as a side note, I've successfully built my module against the current linux-5.4-rc3 from the main linux git repo)
[00:19] <Cheyenne> the problem I'm trying to resolve at the moment is one of our buildbots is failing (it's a buildbot builder that uses the ubuntu mainline kernels as a build validation test)
[00:39] <apw> Cheyenne: oh is all very small? it might be a bug i fixed this morning
[00:41] <Cheyenne> It looks like the Makefiles are missing (there are a bunch of broken links in the linux-headers directory).
[00:43] <Cheyenne> building "external" kernel modules has been an adventure with 5.4 -- there was a bug in modpost that was fixed in linux-5.4-rc3
[00:44] <apw> ahh yes that one got bit, the all package is empty
[00:44] <apw> it needs a rebuild
[00:45] <Cheyenne> Oh.. I misread your "oh is all very small".. yes it's only 2012 bytes
[00:45] <-- tcrawford (~tcrawford@209.212.58.90) has left this server (Quit: leaving).
[00:45] <apw> Cheyenne: yeah broken, i386 no longer builds which broke that all
[00:46] <Cheyenne> Ah...
[00:46] <apw> Cheyenne: resubmitted, should pop out in an hour or so, hopefully that will make it happy
[00:50] <Cheyenne> Okay... I'll watch for it and give it a try
[01:00] <Cheyenne> apw: Thanks. I'll give the build a shot after dinner.

[Christian Ehrhardt  (paelzer)]

I marked it to affect kernel as well, but it seems from above discussion that it might already be solved by a rebuild now.
Checking ...

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1848585

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Christian Ehrhardt  (paelzer)]

Confirmed the new rebuild of the mainline kernels resolved the issue

[Christian Ehrhardt  (paelzer)]

After that detour now back to DKMS on DPDK.
The issue is this:

make: Entering directory '/usr/src/linux-headers-5.4.0-050400rc3-generic'
  CC [M] /var/lib/dkms/dpdk-rte-kni/18.11.2/build/kni_net.o
  CC [M] /var/lib/dkms/dpdk-rte-kni/18.11.2/build/kni_misc.o
  CC [M] /var/lib/dkms/dpdk-rte-kni/18.11.2/build/kni_ethtool.o
  CC [M] /var/lib/dkms/dpdk-rte-kni/18.11.2/build/ethtool/ixgbe/ixgbe_ethtool.o
In file included from /usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/ixgbe_osdep.h:26,
                 from /usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/ixgbe_type.h:16,
                 from /usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/ixgbe_dcb.h:17,
                 from /usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/ixgbe.h:37,
                 from /usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/ixgbe_ethtool.c:25:
/usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/kcompat.h:2225:10: fatal error: linux/pci-aspm.h: No such file or directory
 2225 | #include <linux/pci-aspm.h>
      | ^~~~~~~~~~~~~~~~~~
compilation terminated.

[Christian Ehrhardt  (paelzer)]

## DPDK in Ubuntu ##
18.11.x:
$ grep -Hrn pci-aspm *
kernel/linux/kni/ethtool/ixgbe/kcompat.h:2225:#include <linux/pci-aspm.h>
kernel/linux/kni/ethtool/igb/kcompat.h:2417:#include <linux/pci-aspm.h>
The same is true for DPDK 17.11.x in Bionic.
That is in the file of dpdk-rte-kni-dkms:
/usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/kcompat.h

Affected are:
18.11.x - Disco/Eoan - since they are part of UCA backportsthat are still active and might meet an HWE kernel in Bionic due to that (Or people install own 5.4 kernels).
19.11.x - Focal will move to that and not be affected
17.11.x - Bionic - due to >=5.4 HWE kernel showing up at some point

## Upstream DPDK ##
Nothing about that on latest dpdk master, but that is due to ethtool support being fully removed: https://git.dpdk.org/dpdk/commit/?id=ea6b39b5b847655cf65f283d3cc25d7ab629d039
Therefore there won't ever be an upstream fix on master.
But there might be on the stable branches.

## Kernel change ##
Related kernel change is: https://lkml.org/lkml/2019/8/27/695
So the solution might be to just include linux/pci.h instead depending on kernel version.

## Upstream stable branches ##
There is no change yet for the upstream stable branches.

[Christian Ehrhardt  (paelzer)]

Here is the fix for the first issue that was hit (attached), but there is more after that, now I hit:

/usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/kcompat.h:239:27: error: ‘smp_num_cpus’ undeclared (first use in this function)
  239 | #define num_online_cpus() smp_num_cpus

[Christian Ehrhardt  (paelzer)]

Probably related to kernel change:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c09ab96fc820109d63097a2adcbbd20836b655f

[Christian Ehrhardt  (paelzer)]

Fix the next issue around num_online_cpus

[Christian Ehrhardt  (paelzer)]

Next issue is around skb_frag_size_sub skb_frag_dma_map skb_frag_address

/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:5352:12: error: assignment to ‘struct skb_frag_struct *’ from incompatible pointer type ‘skb_frag_t *’ {aka ‘struct bio_vec *’} [-Werror=incompatible-pointer-types]
 5352 | for (frag = &skb_shinfo(skb)->frags[0];; frag++) {
      | ^
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:5352:47: error: increment of pointer to an incomplete type ‘struct skb_frag_struct’
 5352 | for (frag = &skb_shinfo(skb)->frags[0];; frag++) {
      | ^~
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:5393:24: error: passing argument 1 of ‘skb_frag_size’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 5393 | size = skb_frag_size(frag);
      | ^~~~
      | |
      | struct skb_frag_struct *
In file included from ./include/linux/if_ether.h:19,
                 from ./include/uapi/linux/ethtool.h:19,
                 from ./include/linux/ethtool.h:18,
                 from ./include/linux/netdevice.h:37,
                 from /usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:18:
./include/linux/skbuff.h:325:60: note: expected ‘const skb_frag_t *’ {aka ‘const struct bio_vec *’} but argument is of type ‘struct skb_frag_struct *’
  325 | static inline unsigned int skb_frag_size(const skb_frag_t *frag)
      | ~~~~~~~~~~~~~~~~~~^~~~
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:5396:40: error: passing argument 2 of ‘skb_frag_dma_map’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 5396 | dma = skb_frag_dma_map(tx_ring->dev, frag, 0,
      | ^~~~
      | |
      | struct skb_frag_struct *
In file included from ./include/linux/if_ether.h:19,
                 from ./include/uapi/linux/ethtool.h:19,
                 from ./include/linux/ethtool.h:18,
                 from ./include/linux/netdevice.h:37,
                 from /usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:18:
./include/linux/skbuff.h:3050:26: note: expected ‘const skb_frag_t *’ {aka ‘const struct bio_vec *’} but argument is of type ‘struct skb_frag_struct *’
 3050 | const skb_frag_t *frag,
      | ~~~~~~~~~~~~~~~~~~^~~~
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c: In function ‘igb_pull_tail’:
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:8234:33: error: initialization of ‘struct skb_frag_struct *’ from incompatible pointer type ‘skb_frag_t *’ {aka ‘struct bio_vec *’} [-Werror=incompatible-pointer-types]
 8234 | struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[0];
      | ^
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:8243:24: error: passing argument 1 of ‘skb_frag_address’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 8243 | va = skb_frag_address(frag);
      | ^~~~
      | |
      | ...

[Christian Ehrhardt  (paelzer)]

Actually the bug here has nothing to so with the kernel bug which was just a build issue, lets remove the kernel task to not distract.

[Christian Ehrhardt  (paelzer)]

skb_shinfo

skb_frag_dma_map is the same signature.

That is called from the dkms modules with frag that is initialized like:
  frag = &skb_shinfo(skb)->frags[0]
And then iterated.

That must (in the past) have been
  skb_frag_t *
but now is
  struct skb_frag_struct *

And yes, the kernel changed skb_frag_t here https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8842d285bafa9ff7719f4107b6545a11dcd41995

[Christian Ehrhardt  (paelzer)]

The pattern still is in the kernel
In __i40e_chk_linearize:
const skb_frag_t *frag
..
frag = &skb_shinfo(skb)->frags[0];

And even in the DPDK mod code this works still:

  size = skb_frag_size(frag);

That function signature still is unchanged.
It only changed to return the new bv_len which is a union with the old size.

So both functions called have
   const skb_frag_t *frag
in their signature
static inline dma_addr_t skb_frag_dma_map(struct device *dev, const skb_frag_t *frag,
static inline unsigned int skb_frag_size(const skb_frag_t *frag)

That is 'const skb_frag_t *frag' for both, but only on the latter does it complain?
Ah no, flooded by errors - it complains at both.

The start of it all is the derive from that pointer:
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:5352:12: error: assignment to ‘struct skb_frag_struct *’ from incompatible pointer type ‘skb_frag_t *’ {aka ‘struct bio_vec *’} [-Werror=incompatible-pointer-types]
 5352 | for (frag = &skb_shinfo(skb)->frags[0];; frag++) {

[Christian Ehrhardt  (paelzer)]

Now all these changes also have to be backward compatible ...

[Christian Ehrhardt  (paelzer)]

BTW recommendation from upstream:
[11:18] <tmonjalo> cpaelzer: Drop KNI ethtool from your package!
[11:20] <tmonjalo> That's a lot easier than maintaining this... thing
[11:31] <cpaelzer> tmonjalo: that is true and correct for the future, which also reflects what happened in master branch
[11:31] <cpaelzer> tmonjalo: but the past is the past and I guess I need to fix it there
[11:34] <tmonjalo> cpaelzer: there is another way: drop it and wait for requests ;)

Just saying to make it clear how supported that is, and also the package is (intentionally) only in universe for the very same reason.

[Christian Ehrhardt  (paelzer)]

BTW - testcase:
$ apt install dpdk-rte-kni-dkms

In case you need to rerun (adapt for your kernel):
$ /usr/lib/dkms/dkms_autoinstaller start 5.4.0-050400rc3-generic

[Christian Ehrhardt  (paelzer)]

As expected there are complexities ahead:
- Iterations on bio_vec should actually use bio_for_each_segment (for bio_vec) and I was not intendeing to maintain a bigger rewrite
- as shown for backward compatibility this
- upstream has given up and removed it

I think I have a way for some backportability (5.3) but not yet tested 4.15 and didn't check what Debian might need.

I'd want to talk with Luca first, to decide if we should follow upstream and remove it.
Or just do so from newer releases (we will remove it for 19.11 anyway), but also adapt the tests to not fail on >5.4 in older releases - it has some right to stay for <5.4 kernels without causing too much work for now. Best would be if there is some DKMS trickery to mark it only valid <5.4 maybe?

[Christian Ehrhardt  (paelzer)]

Updated the fix to be backward compatible with 5.3

[Christian Ehrhardt  (paelzer)]

Sent upstream for discussion http://mails.dpdk.org/archives/stable/2019-October/017965.html

[Seth Forshee (sforshee)]

On Fri, Oct 18, 2019 at 06:59:56AM -0000, Christian Ehrhardt  wrote:
> I know - and thanks you for that - that you do those checks in advance.
> Could you outline the expected timing and target releases for this kernel (including HWEs) so that I know the deadlines to fix this?

Ideally the target for landing 5.4 into focal is probably ~4 weeks from
now. That might be a tad optimistic due to focusing most of our
attention for the last few weeks on the eoan 5.3 kernel, but hopefully
it's not far off.

I don't have an exact timeline for moving hwe-edge, but it cannot happen
until 5.3 moves from hwe-edge to hwe, so it will happen later.

[Christian Ehrhardt  (paelzer)]

My changes got accepted in 18.11.3 so that will be the release and update that fixes it.
A few more days/weeks for that ...

[Christian Ehrhardt  (paelzer)]

While D/E will never get a 5.4 kernel the DPDK version in here is in the cloud archive and therefore sooner or later will meet the HWE kernel in Bionic.
Furthermore people might use more recent kernels on their own and it isn't bad to prevent those breaking.

[Christian Ehrhardt  (paelzer)]

=> http://mails.dpdk.org/archives/announce/2019-October/000283.html

[Christian Ehrhardt  (paelzer)]

FYI: uploaded 18.11.3 which contains my fixes to Debian which will auto-sync to Ubuntu once complete there.

[Launchpad Janitor (janitor)]

This bug was fixed in the package dpdk - 18.11.3-1

---------------
dpdk (18.11.3-1) unstable; urgency=medium

  * Merge stable update to 18.11.3; For a list of changes see
    http://doc.dpdk.org/guides-18.11/rel_notes/release_18_11.html#id2
    - refresh d/p/0004-build-bump-minimum-Meson-version-to-0.47.1.patch
    - refresh d/p/avoid-as-needed-as-it-causes-overlinking.patch
    - d/dpdk-dev.install: dpdk-test is now properly in usr/bin
    - d/librte-security18.11.symbols: mark some symbols that now properly
      are experimental as such (none is gone)
    - among other things it fixes a dkms build issue with kernel 5.4
      (LP: #1848585)

 -- Christian Ehrhardt <email address hidden> Mon, 28 Oct 2019 10:59:53 +0100

[Christian Ehrhardt  (paelzer)]

ok, time to prep 18.11.3 for D/E along the defined exception for MREs of DPDK.
17.11.x (Bionic) will still have to wait for 17.11.7 to be released.

[Christian Ehrhardt  (paelzer)]

MPs up fro D/E to review:
https://code.launchpad.net/~paelzer/ubuntu/+source/dpdk/+git/dpdk/+merge/374896
https://code.launchpad.net/~paelzer/ubuntu/+source/dpdk/+git/dpdk/+merge/374897

[Christian Ehrhardt  (paelzer)]

Uploaded Disco and Eoan changes to -unapproved for the SRU Team to review and accept.

As mentioned before 17.11.7 still takes a while, so Bionic will follow somewhen later.

[Launchpad Janitor (janitor)]

This bug was fixed in the package dpdk - 18.11.4-1ubuntu0.19.04.1

---------------
dpdk (18.11.4-1ubuntu0.19.04.1) disco-security; urgency=medium

  * SECURITY UPDATE: Updated to 18.11.4 to fix security issue.
    - CVE-2019-14818

 -- Marc Deslauriers <email address hidden> Tue, 12 Nov 2019 09:33:01 -0500

[Christian Ehrhardt  (paelzer)]

18.11.4-1ubuntu0.19.10.1 is in eoan as well.
So is 17.11.8-0~ubuntu18.04.2 in Bionic which got all currently known kni build issues applied.