APST gets enabled against explicit kernel option

Bug #1699004 reported by Nils
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Kai-Heng Feng
Yakkety
Won't Fix
Undecided
Unassigned
Zesty
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
The NVMe driver doesn't set APSTE on APST quirked devices at initialization. If the BIOS or NVMe enables APST before driver loading, APST will never be disabled, it also ignores explicit kernel option as result.
So the faulty NVMe may not work as intended.

[Test Case]
$ sudo nvme get-feature -f 0x0c -H /dev/nvme0
...will show APST is "Disabled" instead of "Enabled"

[Regression Potential]
Very low.
This SRU didn't change anything really - it just explicitly set APSTE at initialization.

---

I have a Lenovo ThinkPad X270 with a Toshiba nvme SSD

$ sudo nvme list
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 177S10WYTAMT THNSF5256GPUK TOSHIBA 1 256.06 GB / 256.06 GB 512 B + 0 B 51025KLA

I was affected by this bug
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184?comments=all
before. After disabling APST by adding "nvme_core.default_ps_max_latency_us=0" in /etc/default/grub, the bug went away.

Since yesterday, however the bug has returned, with the system dying with I/O errors after an hour or so.

I verified, that the kernel option is still being set

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.10.0-22-generic.efi.signed root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 vt.handoff=7

however it turns out that it is being ignored for some reason, and running

$ sudo nvme get-feature -f 0x0c -H /dev/nvme0

reports that APST is enabled. I can successfully disable it manually using

$ sudo nvme set-feature -f 0x0c -v=0 /dev/nvme0

and the problem goes away. However, after any reboot and even after waking the system from suspend, it is reenabled, causing the system to crash after a short while.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: linux-image-4.10.0-22-generic 4.10.0-22.24
ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
Uname: Linux 4.10.0-22-generic x86_64
ApportVersion: 2.20.4-0ubuntu4.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC0D0p: maeher 1669 F...m pulseaudio
 /dev/snd/controlC0: maeher 1669 F.... pulseaudio
CurrentDesktop: Unity:Unity7
Date: Mon Jun 19 23:29:31 2017
InstallationDate: Installed on 2017-04-17 (64 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
MachineType: LENOVO 20HN001RUS
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-22-generic.efi.signed root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.10.0-22-generic N/A
 linux-backports-modules-4.10.0-22-generic N/A
 linux-firmware 1.164.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/16/2017
dmi.bios.vendor: LENOVO
dmi.bios.version: R0IET30W (1.08 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20HN001RUS
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrR0IET30W(1.08):bd01/16/2017:svnLENOVO:pn20HN001RUS:pvrThinkPadX270:rvnLENOVO:rn20HN001RUS:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.name: 20HN001RUS
dmi.product.version: ThinkPad X270
dmi.sys.vendor: LENOVO

Revision history for this message
Nils (maeher) wrote :
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

What's the value of `cat /sys/module/nvme_core/parameters/default_ps_max_latency_us`?

Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please attach the value of `sudo find /sys -name '*latency*' | grep nvme0 | xargs cat` as well.

Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
Revision history for this message
Nils (maeher) wrote :

I get

$ cat /sys/module/nvme_core/parameters/default_ps_max_latency_us
0

which kind of surprises me.

$ sudo find /sys -name '*latency*' | grep nvme0 | xargs cat

does not return anything.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Can you install latest mainline kernel [1], add "nvme_core.dyndbg=+p" to your kernel parameter, and do

$ dmesg | grep -i nvme
$ sudo nvme get-feature -f 0x0c -H /dev/nvme0

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12-rc5/linux-headers-4.12.0-041200rc5-generic_4.12.0-041200rc5.201706112031_amd64.deb

Revision history for this message
Nils (maeher) wrote :
Download full text (5.4 KiB)

I installed the kernel you linked to and set the kernel parameter.
On first boot the system immediately crashed with I/O errors upon login.
After reboot I could run the commands:

$ dmesg | grep -i nvme
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7
[ 2.225100] nvme nvme0: pci function 0000:04:00.0
[ 2.441319] nvme0n1: p1 p2
[ 4.220749] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.411077] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro

$ sudo nvme get-feature -f 0x0c -H /dev/nvme0
get-feature:0xc (Autonomous Power State Transition), Current value:0x000001
 Autonomous Power State Transition Enable (APSTE): Enabled
 Auto PST Entries .................
 Entry[ 0]
 .................
 Idle Time Prior to Transition (ITPT): 50 ms
 Idle Transition Power State (ITPS): 4
 .................
 Entry[ 1]
 .................
 Idle Time Prior to Transition (ITPT): 50 ms
 Idle Transition Power State (ITPS): 4
 .................
 Entry[ 2]
 .................
 Idle Time Prior to Transition (ITPT): 50 ms
 Idle Transition Power State (ITPS): 4
 .................
 Entry[ 3]
 .................
 Idle Time Prior to Transition (ITPT): 10000 ms
 Idle Transition Power State (ITPS): 5
 .................
 Entry[ 4]
 .................
 Idle Time Prior to Transition (ITPT): 10000 ms
 Idle Transition Power State (ITPS): 5
 .................
 Entry[ 5]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 5
 .................
 Entry[ 6]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[ 7]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[ 8]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[ 9]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[10]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[11]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[12]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[13]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[14]
 .................
 Idle Time Prior to Transition (ITPT): 0 ms
 Idle Transition Power State (ITPS): 0
 .................
 Entry[15]
 ...................

Read more...

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

It means the quirk doesn't work:

commit be56945c4edd5a3da15f8254b68d1ddb1588d0c4
Author: Andy Lutomirski <email address hidden>
Date: Thu Apr 20 13:37:56 2017 -0700

    nvme: Quirk APST off on "THNSF5256GPUK TOSHIBA"

Can you do
$ dmesg | grep -i apst
instead?

Revision history for this message
Nils (maeher) wrote :

$ dmesg | grep -i apst

does not return anything.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

That's weird. 4.12-rc5 should have APST message if dynamic debug is enabled.

Revision history for this message
Nils (maeher) wrote :

It is indeed very odd.

dmesg | grep dyndbg
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7

seems to indicate, that I DID actually set the kernel parameter.
Is there some way to check whether dynamic debug is ACTUALLY enabled?

Given that the system seems to quietly ignore "nvme_core.default_ps_max_latency_us=0", maybe it also ignores "nvme_core.dyndbg=+p".

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

I don't know (yet) how kernel parses its cmdline parameters - can you remove "nvme_core.default_ps_max_latency_us=0" but keep "nvme_core.dyndbg=+p", then do the grep again?

Revision history for this message
Nils (maeher) wrote :

$ dmesg | grep -i apst

still does not return anything

$ dmesg | grep -i nvme
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7
[ 2.230941] nvme nvme0: pci function 0000:04:00.0
[ 2.446574] nvme0n1: p1 p2
[ 4.145140] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.342813] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro

appears to be the same (minus the "nvme_core.default_ps_max_latency_us=0")

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

"nvme_core.default_ps_max_latency_us=0" is still in the kernel parameter.

Revision history for this message
Nils (maeher) wrote :

Sorry, you are indeed correct, apparently I forgot to update-grub.

Nevertheless, I get the same results

$ dmesg | grep -i apst
$ dmesg | grep -i nvme
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.dyndbg=+p vt.handoff=7
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-041200rc5-generic root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.dyndbg=+p vt.handoff=7
[ 2.230470] nvme nvme0: pci function 0000:04:00.0
[ 2.446516] nvme0n1: p1 p2
[ 4.291495] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.494027] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please try this one:
http://people.canonical.com/~khfeng/lp1699004/

I added several messages to debug what code path it took.

Grep apst again:
$ dmesg | grep -i apst

Revision history for this message
Nils (maeher) wrote :

Now I get the following:

$ dmesg | grep -i apst
[ 2.232133] nvme nvme0: apsta = 0, no APST
[ 2.448134] nvme 0000:04:00.0: NVME_QUIRK_NO_APST
[ 2.448135] nvme 0000:04:00.0: disabling APST.
[ 2.448137] nvme nvme0: apsta = 0, no APST

It seems like those messages are telling me that apst should be disabled?
However, I still get

sudo nvme get-feature -f 0x0c -H /dev/nvme0
get-feature:0xc (Autonomous Power State Transition), Current value:0x000001
 Autonomous Power State Transition Enable (APSTE): Enabled
 Auto PST Entries .................
 Entry[ 0]
 .................
 Idle Time Prior to Transition (ITPT): 50 ms
 Idle Transition Power State (ITPS): 4
 .................
 Entry[ 1]
 .................
 Idle Time Prior to Transition (ITPT): 50 ms
 Idle Transition Power State (ITPS): 4
 .................
 Entry[ 2]
 .................
 Idle Time Prior to Transition (ITPT): 50 ms
 Idle Transition Power State (ITPS): 4
 .................
 Entry[ 3]
 .................
 Idle Time Prior to Transition (ITPT): 10000 ms
 Idle Transition Power State (ITPS): 5
 .................
 Entry[ 4]
 .................
 Idle Time Prior to Transition (ITPT): 10000 ms
 Idle Transition Power State (ITPS): 5
...

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

So APST is not enabled in NVMe driver. I have no idea who does it, probably BIOS or NVMe firmware?

Did you upgrade them before the issue reappear?

Anyway, we probably need to explicitly disable APST in the NVMe driver.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Nils (maeher) wrote :

I have not upgraded the BIOS or the firmware, no.
This is really weird.

I tried the new kernel, however my system does not boot up with it.
It also does not show me an error that i can interpret, and the boot messages do not seem to be logged anywhere. I'm assuming that the system has problems writing the log-file, but I'm not sure.

The messages on screen when it stops booting do contain a call trace that has something to do with nvme_core, but I'm not sure what it's about. As I said I cannot find any logs.

Best I can do right now is a picture of the call trace as it appears on screen.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Built a new kernel for testing:
http://people.canonical.com/~khfeng/lp1699004/linux-image-4.12.0-rc6+_4.12.0-rc6+-6_amd64.deb

Also, you can remove "nvme_core.default_ps_max_latency_us=0" - the model you use is already in the quirk table. Keep "nvme_core.dyndbg=+p" in the meantime.

Attach `dmesg | grep -i nvme` afterwards.

Revision history for this message
Nils (maeher) wrote :

With the new kernel the system boots up.
I get the following:

$ dmesg | grep -i nvme
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-rc6+ root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.dyndbg=+p vt.handoff=7
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-rc6+ root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.dyndbg=+p vt.handoff=7
[ 2.228574] nvme nvme0: pci function 0000:04:00.0
[ 2.444448] nvme 0000:04:00.0: NVME_QUIRK_NO_APST
[ 2.444449] nvme 0000:04:00.0: disabling APST.
[ 2.444451] nvme nvme0: Disable APST at first time
[ 2.444452] nvme nvme0: APST disabled
[ 2.446363] nvme0n1: p1 p2
[ 4.140319] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.358751] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro

And indeed, this time APST is disabled!

$ sudo nvme get-feature -f 0x0c -H /dev/nvme0
get-feature:0xc (Autonomous Power State Transition), Current value:00000000
 Autonomous Power State Transition Enable (APSTE): Disabled

So whatever it was you changes works! I hope it will be in the standard kernel soon.
Thanks a lot for taking the time to look into this, in particular because I seem to be the only person affected by it. I appreciate it.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Your system somehow saves APST config across reboots. The current code logic will skip configuring APST if the device is in quirk table - so the new APST value will never get set despite default_ps_max_latency_us=0.

I'll send a patch for this issue. Also, thanks for your testing =)

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Can you do one more testing? If now you boot with Ubuntu's 4.10 kernel with default_ps_max_latency_us=0, is APST enabled or disabled?

Revision history for this message
Nils (maeher) wrote :

In that case it's enabled again:

$ dmesg | grep -i nvme
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-24-generic.efi.signed root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-24-generic.efi.signed root=UUID=365f1a9c-9598-4ad5-a387-d02f771767a1 ro quiet splash nvme_core.default_ps_max_latency_us=0 nvme_core.dyndbg=+p vt.handoff=7
[ 2.372993] nvme nvme0: pci function 0000:04:00.0
[ 2.587597] nvme0n1: p1 p2
[ 3.343336] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.548268] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro

sudo nvme get-feature -f 0x0c -H /dev/nvme0
get-feature:0xc (Autonomous Power State Transition), Current value:0x000001
 Autonomous Power State Transition Enable (APSTE): Enabled

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Looks like your system enables APST by default. So we can't assume APST is disabled by default - APST needs to be set on all circumstances.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Andy Lutomirski (luto-mit) wrote :

Nils, what the actual failure mode on a bad kernel? Do you have dmesg output?

Revision history for this message
Nils (maeher) wrote :

I'm not sure what exactly you're asking. The kernel above that does not boot? The boot seems to fail before the drive is mounted, so I have no logfiles whatsoever. The only thing I have is a photo of the last messages on screen.

Or are you talking about something else?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Nils,

Andy means what exactly error message when booting with kernel like 4.10.0-22. Bad means "APST is enabled all the time" bad.

description: updated
Seth Forshee (sforshee)
Changed in linux (Ubuntu):
status: Confirmed → Fix Committed
Changed in linux (Ubuntu Zesty):
status: New → Fix Committed
Changed in linux (Ubuntu Yakkety):
status: New → Fix Committed
Revision history for this message
Kleber Sacilotto de Souza (kleber-souza) 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-zesty' to 'verification-done-zesty'. If the problem still exists, change the tag 'verification-needed-zesty' to 'verification-failed-zesty'.

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-zesty
Revision history for this message
Nils (maeher) wrote :

I'm sorry, for taking so long to respond.

I do not have any logs, since they cannot be written to my hard drive in the event of failure. (The SSD is my only hard drive and it can no longer be accessed.)

But the error messages are something like:

EXT4-fs error (device nvme0n1p2): ext4_find_entry:1463: inode #12059331: comm NetworkManager: reading directory lblock 0

Basically the only things that change are the specific inode numbers and what I assume is the process name.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

@Nils,

Wha you need to do is to enable -proposed repository, and verify that the Linux kernel in -proposed actually fixes the problem.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Just realized you were replying previous comment...

Revision history for this message
Andy Whitcroft (apw) wrote : Closing unsupported series nomination.

This bug was nominated against a series that is no longer supported, ie yakkety. The bug task representing the yakkety nomination is being closed as Won't Fix.

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

Changed in linux (Ubuntu Yakkety):
status: Fix Committed → Won't Fix
Revision history for this message
Nils (maeher) wrote :

I really don't understand what's going on here and what I'm expected to do.

After enabling -proposed, my system boots with kernel

4.12.0-041200rc5-generic

and APST is enabled again (and my system crashed after about 10 Minutes with exactly the same behaviour as before). Should that kernel contain the fix? If it does then it's not working.
If it does not, then I'm not sure which kernel I'm supposed to test.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

@Nils,

You need to remove 4.12.0-041200rc5-generic, or other mainline/testing kernel you installed.
After that, boot with kernel 4.10.0-29, verify if this bug still happen to your system.

Revision history for this message
Kleber Sacilotto de Souza (kleber-souza) wrote :

Hi @Nils,

Could you please test the Zesty kernel that's currently in proposed (4.10.0-29.33)?

Thank you.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (6.6 KiB)

This bug was fixed in the package linux - 4.10.0-30.34

---------------
linux (4.10.0-30.34) zesty; urgency=low

  * CVE-2017-7533
    - dentry name snapshots

linux (4.10.0-29.33) zesty; urgency=low

  * linux: 4.10.0-29.33 -proposed tracker (LP: #1704961)

  * Opal and POWER9 DD2 (LP: #1702159)
    - powerpc/powernv: Tell OPAL about our MMU mode on POWER9
    - powerpc/powernv: Fix boot on Power8 bare metal due to opal_configure_cores()

  * CVE-2017-1000364
    - mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack
    - mm/mmap.c: expand_downwards: don't require the gap if !vm_prev

  * [Xenial] nvme: Quirks for PM1725 controllers (LP: #1704435)
    - nvme: Quirks for PM1725 controllers

  * hns: under heavy load, NIC may fail and require reboot (LP: #1704146)
    - net: hns: Bugfix for Tx timeout handling in hns driver

  * New ACPI identifiers for ThunderX SMMU (LP: #1703437)
    - iommu/arm-smmu: Plumb in new ACPI identifiers

  * CVE-2017-7482
    - rxrpc: Fix several cases where a padded len isn't checked in ticket decode

  * CVE-2017-1000365
    - fs/exec.c: account for argv/envp pointers

  * CVE-2017-10810
    - drm/virtio: don't leak bo on drm_gem_object_init failure

  * Data corruption with hio driver (LP: #1701316)
    - SAUCE: hio: Fix incorrect use of enum req_opf values

  * arm64: fix crash reading /proc/kcore (LP: #1702749)
    - fs/proc: kcore: use kcore_list type to check for vmalloc/module address
    - arm64: mm: select CONFIG_ARCH_PROC_KCORE_TEXT

  * cxlflash update request in the Xenial SRU stream (LP: #1702521)
    - scsi: cxlflash: Refactor context reset to share reset logic
    - scsi: cxlflash: Support SQ Command Mode
    - scsi: cxlflash: Cleanup prints
    - scsi: cxlflash: Cancel scheduled workers before stopping AFU
    - scsi: cxlflash: Enable PCI device ID for future IBM CXL Flash AFU
    - scsi: cxlflash: Separate RRQ processing from the RRQ interrupt handler
    - scsi: cxlflash: Serialize RRQ access and support offlevel processing
    - scsi: cxlflash: Implement IRQ polling for RRQ processing
    - scsi: cxlflash: Update sysfs helper routines to pass config structure
    - scsi: cxlflash: Support dynamic number of FC ports
    - scsi: cxlflash: Remove port configuration assumptions
    - scsi: cxlflash: Hide FC internals behind common access routine
    - scsi: cxlflash: SISlite updates to support 4 ports
    - scsi: cxlflash: Support up to 4 ports
    - scsi: cxlflash: Fence EEH during probe
    - scsi: cxlflash: Remove unnecessary DMA mapping
    - scsi: cxlflash: Fix power-of-two validations
    - scsi: cxlflash: Fix warnings/errors
    - scsi: cxlflash: Improve asynchronous interrupt processing
    - scsi: cxlflash: Support multiple hardware queues
    - scsi: cxlflash: Add hardware queues attribute
    - scsi: cxlflash: Introduce hardware queue steering
    - cxl: Enable PCI device IDs for future IBM CXL adapters
    - scsi: cxlflash: Select IRQ_POLL
    - scsi: cxlflash: Combine the send queue locks
    - scsi: cxlflash: Update cxlflash_afu_sync() to return errno
    - scsi: cxlflash: Reset hardware queue context via specified register
    - scsi: cxlflash: Schedule asynchronous res...

Read more...

Changed in linux (Ubuntu Zesty):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (24.9 KiB)

This bug was fixed in the package linux - 4.11.0-13.19

---------------
linux (4.11.0-13.19) artful; urgency=low

  * CVE-2017-7533
    - dentry name snapshots

linux (4.11.0-12.18) artful; urgency=low

  * linux: 4.11.0-12.18 -proposed tracker (LP: #1707635)
    - no change rebuild to pick up the new binutils.

  * Adt tests of src:linux time out often on armhf lxc containers (LP: #1705495)
    - [Packaging] tests -- reduce rebuild test to one flavour
    - [Packaging] tests -- reduce rebuild test to one flavour -- use filter

  * [ARM64] config EDAC_GHES=y depends on EDAC_MM_EDAC=y (LP: #1706141)
    - [Config] set EDAC_MM_EDAC=y for ARM64

  * [Hyper-V] hv_netvsc: Exclude non-TCP port numbers from vRSS hashing
    (LP: #1690174)
    - hv_netvsc: Exclude non-TCP port numbers from vRSS hashing

  * ath10k doesn't report full RSSI information (LP: #1706531)
    - ath10k: add per chain RSSI reporting

  * ideapad_laptop don't support v310-14isk (LP: #1705378)
    - platform/x86: ideapad-laptop: Add several models to no_hw_rfkill

  * Ubuntu 16.04.3: Qemu fails on P9 (LP: #1686019)
    - KVM: PPC: Pass kvm* to kvmppc_find_table()
    - KVM: PPC: Use preregistered memory API to access TCE list
    - KVM: PPC: VFIO: Add in-kernel acceleration for VFIO
    - powerpc/powernv/iommu: Add real mode version of iommu_table_ops::exchange()
    - powerpc/iommu/vfio_spapr_tce: Cleanup iommu_table disposal
    - powerpc/vfio_spapr_tce: Add reference counting to iommu_table
    - powerpc/mmu: Add real mode support for IOMMU preregistered memory
    - KVM: PPC: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number
    - KVM: PPC: Book3S HV: Add radix checks in real-mode hypercall handlers

  * hns: ethtool selftest crashes system (LP: #1705712)
    - net/hns:bugfix of ethtool -t phy self_test

  * ThunderX: soft lockup on 4.8+ kernels when running qemu-efi with vhost=on
    (LP: #1673564)
    - KVM: arm/arm64: vgic-v3: Use PREbits to infer the number of ICH_APxRn_EL2
      registers
    - KVM: arm/arm64: vgic-v3: Fix nr_pre_bits bitfield extraction
    - arm64: Add a facility to turn an ESR syndrome into a sysreg encoding
    - KVM: arm/arm64: vgic-v3: Add accessors for the ICH_APxRn_EL2 registers
    - KVM: arm64: Make kvm_condition_valid32() accessible from EL2
    - KVM: arm64: vgic-v3: Add hook to handle guest GICv3 sysreg accesses at EL2
    - KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler
    - KVM: arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler
    - KVM: arm64: vgic-v3: Add ICV_IAR1_EL1 handler
    - KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
    - KVM: arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler
    - KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler
    - KVM: arm64: vgic-v3: Enable trapping of Group-1 system registers
    - KVM: arm64: Enable GICv3 Group-1 sysreg trapping via command-line
    - KVM: arm64: vgic-v3: Add ICV_BPR0_EL1 handler
    - KVM: arm64: vgic-v3: Add ICV_IGNREN0_EL1 handler
    - KVM: arm64: vgic-v3: Add misc Group-0 handlers
    - KVM: arm64: vgic-v3: Enable trapping of Group-0 system registers
    - KVM: arm64: Enable GICv3 Group-0 sysreg trapping via command-line
    - arm64: Add MIDR values for Cavium cn83XX SoCs
    - arm64: Add wor...

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.