bnx2x_attn_int_deasserted3:4323 MC assert!

Bug #1715519 reported by Daniel Axtens on 2017-09-07
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Daniel Axtens
Trusty
Undecided
Unassigned
Xenial
Undecided
Unassigned
Artful
Undecided
Unassigned

Bug Description

SRU Justification
=================

A ppc64le system runs as a guest under PowerVM. This guest has a bnx2x card attached, and uses openvswitch to bridge an ibmveth interface for traffic from other LPARs.

We see the following crash sometimes when running netperf:
May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f2)]MC assert!
May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: [bnx2x_mc_assert:720(enP24p1s0f2)]XSTORM_ASSERT_LIST_INDEX 0x2
May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: [bnx2x_mc_assert:736(enP24p1s0f2)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e42a7e 0x00462a38 0x00010052
May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: [bnx2x_mc_assert:750(enP24p1s0f2)]Chip Revision: everest3, FW Version: 7_13_1
May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: [bnx2x_attn_int_deasserted3:4329(enP24p1s0f2)]driver assert
May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: [bnx2x_panic_dump:923(enP24p1s0f2)]begin crash dump -----------------
... (dump of registers follows) ...

Subsequent debugging reveals that the packets causing the issue come through the ibmveth interface - from the AIX LPAR. The veth protocol is 'special' - communication between LPARs on the same chassis can use very large (64k) frames to reduce overhead. Normal networks cannot handle such large packets, so traditionally, the VIOS partition would signal to the AIX partitions that it was 'special', and AIX would send regular, ethernet-sized packets to VIOS, which VIOS would then send out.

This signalling between VIOS and AIX is done in a way that is not standards-compliant, and so was never made part of Linux. Instead, the Linux driver has always understood large frames and passed them up the network stack.

In some cases (e.g. with TCP), multiple TCP segments are coalesced into one large packet. In Linux, this goes through the generic receive offload code, using a similar mechanism to GSO. These segments can be very large which presents as a very large MSS (maximum segment size) or gso_size.

Normally, the large packet is simply passed to whatever network application on Linux is going to consume it, and everything is OK.

However, in this case, the packets go through Open vSwitch, and are then passed to the bnx2x driver. The bnx2x driver/hardware supports TSO and GSO, but with a restriction: the maximum segment size is limited to around 9700 bytes. Normally this is more than adequate. However, if a large packet with very large (>9700 byte) TCP segments arrives through ibmveth, and is passed to bnx2x, the hardware will panic.

[Impact]

bnx2x card panics, requiring power cycle to restore functionality.

The workaround is turning off TSO, which prevents the crash as the kernel resegments *all* packets in software, not just ones that are too big. This has a performance cost.

[Fix]

Test packet size in bnx2x feature check path and disable GSO if it is too large. To do this we move a function from one file to another and add another in the networking core.

[Regression Potential]

A/B/X: The changes to the network core are easily reviewed. The changes to behaviour are limited to the bnx2x card driver.
The most likely failure case is a false-positive on the size check, which would lead to a performance regression only.

T: This also involves a different change to the networking core to add the old-style GSO checking, which is more invasive. However the changes are simple and easily reviewed.

Daniel Axtens (daxtens) on 2018-02-06
description: updated
Daniel Axtens (daxtens) on 2018-02-06
description: updated
Daniel Axtens (daxtens) wrote :

This has been assigned CVE-2018-1000026.

description: updated
Daniel Axtens (daxtens) on 2018-02-09
description: updated
Launchpad Janitor (janitor) wrote :
Download full text (3.3 KiB)

This bug was fixed in the package linux - 4.15.0-10.11

---------------
linux (4.15.0-10.11) bionic; urgency=medium

  * linux: 4.15.0-10.11 -proposed tracker (LP: #1749250)

  * "swiotlb: coherent allocation failed" dmesg spam with linux 4.15.0-9.10
    (LP: #1749202)
    - swiotlb: suppress warning when __GFP_NOWARN is set
    - drm/ttm: specify DMA_ATTR_NO_WARN for huge page pools

  * linux-tools: perf incorrectly linking libbfd (LP: #1748922)
    - SAUCE: tools -- add ability to disable libbfd
    - [Packaging] correct disablement of libbfd

  * [Artful] Realtek ALC225: 2 secs noise when a headset plugged in
    (LP: #1744058)
    - ALSA: hda/realtek - update ALC225 depop optimize

  * [Artful] Support headset mode for DELL WYSE (LP: #1723913)
    - SAUCE: ALSA: hda/realtek - Add support headset mode for DELL WYSE

  * headset mic can't be detected on two Dell machines (LP: #1748807)
    - ALSA: hda/realtek - Support headset mode for ALC215/ALC285/ALC289
    - ALSA: hda - Fix headset mic detection problem for two Dell machines

  * Bionic update to v4.15.3 stable release (LP: #1749191)
    - ip6mr: fix stale iterator
    - net: igmp: add a missing rcu locking section
    - qlcnic: fix deadlock bug
    - qmi_wwan: Add support for Quectel EP06
    - r8169: fix RTL8168EP take too long to complete driver initialization.
    - tcp: release sk_frag.page in tcp_disconnect
    - vhost_net: stop device during reset owner
    - ipv6: addrconf: break critical section in addrconf_verify_rtnl()
    - ipv6: change route cache aging logic
    - Revert "defer call to mem_cgroup_sk_alloc()"
    - net: ipv6: send unsolicited NA after DAD
    - rocker: fix possible null pointer dereference in
      rocker_router_fib_event_work
    - tcp_bbr: fix pacing_gain to always be unity when using lt_bw
    - cls_u32: add missing RCU annotation.
    - ipv6: Fix SO_REUSEPORT UDP socket with implicit sk_ipv6only
    - soreuseport: fix mem leak in reuseport_add_sock()
    - net_sched: get rid of rcu_barrier() in tcf_block_put_ext()
    - net: sched: fix use-after-free in tcf_block_put_ext
    - media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION
    - media: soc_camera: soc_scale_crop: add missing
      MODULE_DESCRIPTION/AUTHOR/LICENSE
    - media: tegra-cec: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
    - gpio: uniphier: fix mismatch between license text and MODULE_LICENSE
    - crypto: tcrypt - fix S/G table for test_aead_speed()
    - Linux 4.15.3

  * bnx2x_attn_int_deasserted3:4323 MC assert! (LP: #1715519) //
    CVE-2018-1000026
    - net: create skb_gso_validate_mac_len()
    - bnx2x: disable GSO where gso_size is too big for hardware

  * ethtool -p fails to light NIC LED on HiSilicon D05 systems (LP: #1748567)
    - net: hns: add ACPI mode support for ethtool -p

  * CVE-2017-5715 (Spectre v2 Intel)
    - [Packaging] retpoline files must be sorted
    - [Packaging] pull in retpoline files

  * [Feature] PXE boot with Intel Omni-Path (LP: #1712031)
    - d-i: Add hfi1 to nic-modules

  * CVE-2017-5715 (Spectre v2 retpoline)
    - [Packaging] retpoline -- add call site validation
    - [Config] disable retpoline checks for first upload

  * Do not dup...

Read more...

Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Changed in linux (Ubuntu Artful):
status: New → Fix Committed
Changed in linux (Ubuntu Xenial):
status: New → Fix Committed
Changed in linux (Ubuntu Trusty):
status: New → Fix Committed
Stefan Bader (smb) wrote :

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
tags: added: verification-needed-xenial
Stefan Bader (smb) wrote :

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-artful
Stefan Bader (smb) wrote :

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!

r.stricklin (r.stricklin) wrote :

I am the end user who originally reported this problem. We have been working with Canonical through IBM Support to get this problem resolved -- When I last spoke with IBM about this a few weeks ago, I got the impression we'd have a little extra time to perform verification (e.g. the test period would be between 18 and 31 March) and planned for our test resources accordingly.

I now see that we'd need to perform verification by the 23rd, or possibly 26th? I will do what I can do increase urgency but even having a couple extra days would go a long way to help us get the verification done.

Please let me know ASAP if this is or is not possible.

Daniel Axtens (daxtens) wrote :

Hi,

I am the support engineer on the Canonical side who has been working on this with IBM Support on your behalf. Apologies for the confusion. I will contact our kernel team now and get this clarified for you as soon as I can.

Now, I can't speak for the kernel team or make any commitments on their behalf. However, I know the full test process is time-consuming, so in the mean time, if you are able to boot with each of the kernels and just quickly verify that there are no obvious regressions - just that boot succeeds and that the network card can still send and receive data - I think that would be a very good first step.

Regards,
Daniel

Po-Hsu Lin (cypressyew) wrote :

Hello r.stricklin,

The planned SRU schedule this cycle

 * Current cycle: 09-Mar through 31-Mar

               09-Mar Last day for kernel commits for this cycle.
      12-Mar - 17-Mar Kernel prep week.
      18-Mar - 30-Mar Bug verification & Regression testing.
               02-Apr Release to -updates.

So yeah don't worry about the deadline mentioned in #6

However it would be great to get this verified before the last day, in this case, if there is any issue with this fix we still have some time to pull it out.

Thanks

Stefan Bader (smb) wrote :

In addition to what Po-Hsu Lin and Daniel Axtens said, to have each of the kernels test-booted and checked for obvious regressions would be great and if in addition one of those can be tested for the reported problem being fixed, then this is sufficient. But mainly this procedure is to ensure we do not break things while trying to fix problems. And if there is some regression it takes time to isolate the change and revert it. Hence the urge to get reporter test as soon as possible.

Daniel Axtens (daxtens) wrote :

Hi,

As well as Po-Hsu's comment above, I also have this internal update from the kernel team:

    As this is also a security fix, don't stress too much. If things could be verified for at least for one of the kernels until next week that is better than nothing. We are rather unlikely rip out fixes if they have a CVE (and do not appear to regress other things)

(FYI, this issue is covered by CVE-2018-1000026.)

So, just to confirm, in order of priority:

 1) First confirm there are no new regressions (just a quick 'smoke test') on the 3 kernels.

 2) Second, do a full test of 1 of the kernels.

 3) Test the remaining 2 kernels.

Please keep this bug updated as you go through each step.

Hopefully this helps reduce the pressure for you!

Regards,
Daniel

r.stricklin (r.stricklin) wrote :

Ok, that works. I should be able to provide basic validation much more easily.

We are having trouble reproducing the crash with the unpatched kernel, as we've put many remediating workarounds in place and it's been an adventure to remember where they all are and how exactly they all interacted (and also there are some other bugs currently being worked on in our test environment that affect our ability to reproduce as well). We know it will crash though, and as soon as we get the test setup in place to reproduce the crash I'm confident we can repeat it every time and get a good validation that the patch is solving our problem as well.

If we still can't reproduce the crash by COB Monday, I'll switch gears to provide just a basic boot/function validation and will make sure I get that to you by Tuesday at the latest.

We only have the environment to test xenial ppc64el. We have xenial and trusty x86_64, but not with bnx2x. We don't have artful anywhere that I can test with. Based on that, I was only planning to provide a report for xenial ppc64el. Does the smoke testing make sense to perform without bnx2x hardware present?

r.stricklin (r.stricklin) wrote :

I was able to install the ppc64el 4.4.0-117 kernel from xenial-proposed. It boots and passes at least enough traffic to make an interactive ssh session function.

I'm having some DKMS issues, however, which are preventing me from validating the patch prevents crash as expected (one of the modules we need has BUILD_EXCLUSIVE for 4.8 and 4.10 only). I am working with the IBM development team who publishes these modules to get that resolved ASAP (they were surprised by this, so we are waiting for answers from individual engineers, probably Monday).

r.stricklin (r.stricklin) wrote :

Our validation tests pass with tso/gso enabled and 4.4.0-117 (no crash). We'll do a couple more tests but it's looking good so far.

tags: added: verification-done-xenial
removed: verification-needed-xenial
r.stricklin (r.stricklin) wrote :

We're not set up to test the artful kernel, but I can envision a near-to-mid-term future where we will need this patch to be present in the artful kernel. What's the best way for me to help make sure that future obtains?

Daniel Axtens (daxtens) wrote :

Hi,

Thanks for the Xenial test!

The kernel team process is that patches will always be committed from the most recent kernel first and then back to older kernels, so that no-one ends up with a regression if they upgrade to a more recent kernel. So if it is applied to Xenial it will be applied to Artful :) (FYI, it's already in the kernel that will be in Bionic next month.)

I don't know what you're compiling with DKMS; are you able to do any test at all without it? Just testing that the machine boots and that you can ping someone would make me more comfortable.

Regards,
Daniel

r.stricklin (r.stricklin) wrote :

These Linux LPARs are running Novalink, in a mode that allows them to serve in place of the traditional PowerVM AIX VIO server. So they're providing virtual I/O for other LPARs (this is how we ended up sending 64k packets into the bnx2x nics via open vswitch). The DKMS modules enable that function. It also serves to restrict what we can do with the OS in terms of trying other versions; the Novalink software is supported only on Xenial. Trying to rebuild a machine on artful without Novalink means none of the other LPARs on that machine will run, which will be very disruptive for us, even on a test machine.

We could probably find a way to test artful on a VM, but then that would be using a virtual ethernet adapter and we wouldn't be testing the bnx2x code. I don't know if that would be valuable to you?

r.stricklin (r.stricklin) wrote :

After conferring with the IBM Novalink dev team, we found a way to exploit some undocumented preliminary artful support in the DKMS, to successfully install the hwe-16.04 kernel (4.13.0-38) from xenial-proposed. It boots and passes traffic. I hope to report back later today or possibly tomorrow with full test results.

Please let me know if this is sufficient testing for applying the verification-done-artful tag.

r.stricklin (r.stricklin) wrote :

Full test passes. No crash with proposed hwe-16.04 kernel and tso/gso enabled.

Daniel Axtens (daxtens) wrote :

Fantastic!

If I understand correctly, that is sufficient for verification-done-artful, so I am changing that over for you.

The one remaining kernel is Trusty 3.13. I am guessing your module doesn't compile for that? If it doesn't, there probably isn't much point on booting with just a virtual ethernet adaptor as the change is specifically to the bnx2x code.

Thanks again for your prompt testing efforts!

Regards,
Daniel

tags: added: verification-done-artful
removed: verification-needed-artful
r.stricklin (r.stricklin) wrote :

I didn't think Trusty would even run baremetal on ppc64el?

Launchpad Janitor (janitor) wrote :
Download full text (18.9 KiB)

This bug was fixed in the package linux - 4.13.0-38.43

---------------
linux (4.13.0-38.43) artful; urgency=medium

  * linux: 4.13.0-38.43 -proposed tracker (LP: #1755762)

  * Servers going OOM after updating kernel from 4.10 to 4.13 (LP: #1748408)
    - i40e: Fix memory leak related filter programming status
    - i40e: Add programming descriptors to cleaned_count

  * [SRU] Lenovo E41 Mic mute hotkey is not responding (LP: #1753347)
    - platform/x86: ideapad-laptop: Increase timeout to wait for EC answer

  * fails to dump with latest kpti fixes (LP: #1750021)
    - kdump: write correct address of mem_section into vmcoreinfo

  * headset mic can't be detected on two Dell machines (LP: #1748807)
    - ALSA: hda/realtek - Support headset mode for ALC215/ALC285/ALC289
    - ALSA: hda - Fix headset mic detection problem for two Dell machines
    - ALSA: hda - Fix a wrong FIXUP for alc289 on Dell machines

  * CIFS SMB2/SMB3 does not work for domain based DFS (LP: #1747572)
    - CIFS: make IPC a regular tcon
    - CIFS: use tcon_ipc instead of use_ipc parameter of SMB2_ioctl
    - CIFS: dump IPC tcon in debug proc file

  * i2c-thunderx: erroneous error message "unhandled state: 0" (LP: #1754076)
    - i2c: octeon: Prevent error message on bus error

  * hisi_sas: Add disk LED support (LP: #1752695)
    - scsi: hisi_sas: directly attached disk LED feature for v2 hw

  * EDAC, sb_edac: Backport 1 patch to Ubuntu 17.10 (Fix missing DIMM sysfs
    entries with KNL SNC2/SNC4 mode) (LP: #1743856)
    - EDAC, sb_edac: Fix missing DIMM sysfs entries with KNL SNC2/SNC4 mode

  * [regression] Colour banding and artefacts appear system-wide on an Asus
    Zenbook UX303LA with Intel HD 4400 graphics (LP: #1749420)
    - drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA

  * DVB Card with SAA7146 chipset not working (LP: #1742316)
    - vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems

  * [Asus UX360UA] battery status in unity-panel is not changing when battery is
    being charged (LP: #1661876) // AC adapter status not detected on Asus
    ZenBook UX410UAK (LP: #1745032)
    - ACPI / battery: Add quirk for Asus UX360UA and UX410UAK

  * ASUS UX305LA - Battery state not detected correctly (LP: #1482390)
    - ACPI / battery: Add quirk for Asus GL502VSK and UX305LA

  * support thunderx2 vendor pmu events (LP: #1747523)
    - perf pmu: Extract function to get JSON alias map
    - perf pmu: Pass pmu as a parameter to get_cpuid_str()
    - perf tools arm64: Add support for get_cpuid_str function.
    - perf pmu: Add helper function is_pmu_core to detect PMU CORE devices
    - perf vendor events arm64: Add ThunderX2 implementation defined pmu core
      events
    - perf pmu: Add check for valid cpuid in perf_pmu__find_map()

  * lpfc.ko module doesn't work (LP: #1746970)
    - scsi: lpfc: Fix loop mode target discovery

  * Ubuntu 17.10 crashes on vmalloc.c (LP: #1739498)
    - powerpc/mm/book3s64: Make KERN_IO_START a variable
    - powerpc/mm/slb: Move comment next to the code it's referring to
    - powerpc/mm/hash64: Make vmalloc 56T on hash

  * ethtool -p fails to light NIC LED on HiSilicon D05 systems (LP: #1748567)
    - net...

Changed in linux (Ubuntu Artful):
status: Fix Committed → Fix Released
Daniel Axtens (daxtens) wrote :

Hi,

We do ship an iso for ppc64le for Trusty - I'm not sure whether it does bare metal/PowerNV or just as an LPAR under PowerVM, but it's probably a bit moot at this point.

The good news is that as you can see, the artful kernel was released with the fix.
The Xenial kernel also contains the fix; I'm not sure why that wasn't auto-added to this bug, but the release notes contain this fix: https://launchpad.net/ubuntu/+source/linux/4.4.0-119.143

I am not sure what the final status of the patch in Trusty is, I will let you know when I find out.

Regards,
Daniel

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 3.13.0-144.193

---------------
linux (3.13.0-144.193) trusty; urgency=medium

  * linux: 3.13.0-144.193 -proposed tracker (LP: #1755227)

  * CVE-2017-12762
    - isdn/i4l: fix buffer overflow

  * CVE-2017-17807
    - KEYS: add missing permission check for request_key() destination

  * bnx2x_attn_int_deasserted3:4323 MC assert! (LP: #1715519) //
    CVE-2018-1000026
    - net: Add ndo_gso_check
    - net: create skb_gso_validate_mac_len()
    - bnx2x: disable GSO where gso_size is too big for hardware

  * CVE-2017-17448
    - netfilter: nfnetlink_cthelper: Add missing permission checks

  * CVE-2017-11089
    - cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE

  * CVE-2018-5332
    - RDS: Heap OOB write in rds_message_alloc_sgs()

  * ppc64el: Do not call ibm,os-term on panic (LP: #1736954)
    - powerpc: Do not call ppc_md.panic in fadump panic notifier

  * CVE-2017-17805
    - crypto: salsa20 - fix blkcipher_walk API usage

  * [Hyper-V] storvsc: do not assume SG list is continuous when doing bounce
    buffers (LP: #1742480)
    - SAUCE: storvsc: do not assume SG list is continuous when doing bounce
      buffers

  * Shutdown hang on 16.04 with iscsi targets (LP: #1569925)
    - scsi: libiscsi: Allow sd_shutdown on bad transport

  * CVE-2017-17741
    - KVM: Fix stack-out-of-bounds read in write_mmio

  * CVE-2017-5715 (Spectre v2 Intel)
    - [Packaging] pull in retpoline files

 -- Stefan Bader <email address hidden> Thu, 15 Mar 2018 15:08:03 +0100

Changed in linux (Ubuntu Trusty):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (56.9 KiB)

This bug was fixed in the package linux - 4.4.0-119.143

---------------
linux (4.4.0-119.143) xenial; urgency=medium

  * linux: 4.4.0-119.143 -proposed tracker (LP: #1760327)

  * Dell XPS 13 9360 bluetooth scan can not detect any device (LP: #1759821)
    - Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

linux (4.4.0-118.142) xenial; urgency=medium

  * linux: 4.4.0-118.142 -proposed tracker (LP: #1759607)

  * Kernel panic with AWS 4.4.0-1053 / 4.4.0-1015 (Trusty) (LP: #1758869)
    - x86/microcode/AMD: Do not load when running on a hypervisor

  * CVE-2018-8043
    - net: phy: mdio-bcm-unimac: fix potential NULL dereference in
      unimac_mdio_probe()

linux (4.4.0-117.141) xenial; urgency=medium

  * linux: 4.4.0-117.141 -proposed tracker (LP: #1755208)

  * Xenial update to 4.4.114 stable release (LP: #1754592)
    - x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
    - usbip: prevent vhci_hcd driver from leaking a socket pointer address
    - usbip: Fix implicit fallthrough warning
    - usbip: Fix potential format overflow in userspace tools
    - x86/microcode/intel: Fix BDW late-loading revision check
    - x86/retpoline: Fill RSB on context switch for affected CPUs
    - sched/deadline: Use the revised wakeup rule for suspending constrained dl
      tasks
    - can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
    - can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
    - PM / sleep: declare __tracedata symbols as char[] rather than char
    - time: Avoid undefined behaviour in ktime_add_safe()
    - timers: Plug locking race vs. timer migration
    - Prevent timer value 0 for MWAITX
    - drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
    - drivers: base: cacheinfo: fix boot error message when acpi is enabled
    - PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
    - PCI: layerscape: Fix MSG TLP drop setting
    - mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
    - fs/select: add vmalloc fallback for select(2)
    - hwpoison, memcg: forcibly uncharge LRU pages
    - cma: fix calculation of aligned offset
    - mm, page_alloc: fix potential false positive in __zone_watermark_ok
    - ipc: msg, make msgrcv work with LONG_MIN
    - x86/ioapic: Fix incorrect pointers in ioapic_setup_resources()
    - ACPI / processor: Avoid reserving IO regions too early
    - ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
    - ACPICA: Namespace: fix operand cache leak
    - netfilter: x_tables: speed up jump target validation
    - netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed
      in 64bit kernel
    - netfilter: nf_dup_ipv6: set again FLOWI_FLAG_KNOWN_NH at flowi6_flags
    - netfilter: nf_ct_expect: remove the redundant slash when policy name is
      empty
    - netfilter: nfnetlink_queue: reject verdict request from different portid
    - netfilter: restart search if moved to other chain
    - netfilter: nf_conntrack_sip: extend request line validation
    - netfilter: use fwmark_reflect in nf_send_reset
    - ext2: Don't clear SGID when inheriting ACLs
    - reiserfs: fix race in prealloc discard
    - re...

Changed in linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers