Will this fix make its way back into the bionic-updates?
Tim
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1811755
Title:
X1 Extreme: only one of the two SSDs is loaded
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
On Thinkpad X1 Extreme with two SSDs, if NQN in the firmware are
identical, then only one drive can be seen. NQN is supposed to be unique
but some Intel drives do not follow that.
[Fix]
The device-supplied subnqn is ignored and one will be generated as if
the field is empty.
The upstream patch conflicts with a value in 'enum nvme_quirks' that we
added in a SAUCE patch, changed that from (1<<8) to (1<<15).
[Test]
With this fix, both drives can be seen.
[Regression Potential]
The fix limits to Intel 760p/Pro 7600p SSD, and the fix has been
verified by the bug reporter.
-
I bought a new Thinkpad X1 Extreme, and had it come with two SSDs, one
256G and the other 512G with the intention of keeping the windows on
the 256G disk and using the 512G for linux.
When dealing with the installer, it only ever saw one of the SSDs. I
did manged to get bionic installed on the 512, but on boot, sometimes
it doesn't find the 512G disk and I just get a blank screen. After a
hard power-off, and reboot, it drops into the grub selector, and
choosing linux, it failed again, but this time dropped into a VT.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-43-generic 4.15.0-43.46
ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
Uname: Linux 4.15.0-43-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: tim2003 F pulseaudio
/dev/snd/controlC0: tim2003 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Tue Jan 15 18:53:34 2019
InstallationDate: Installed on 2019-01-14 (0 days ago)
InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Beta amd64 (20190109)
MachineType: LENOVO 20MFCTO1WW
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-43-generic
root=UUID=9254da2f-0220-4b41-8770-ae4b0df0d114 ro quiet splash vt.handoff=1
RelatedPackageVersions:
linux-restricted-modules-4.15.0-43-generic N/A
linux-backports-modules-4.15.0-43-generic N/A
linux-firmware 1.173.3
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/21/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: N2EET35W (1.17 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20MFCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: SDK0R32862 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrN2EET35W(1.17):bd12/21/2018:svnLENOVO:pn20MFCTO1WW:pvrThinkPadX1Extreme:rvnLENOVO:rn20MFCTO1WW:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad X1 Extreme
dmi.product.name: 20MFCTO1WW
dmi.product.version: ThinkPad X1 Extreme
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1811755/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

I tried to do the "apport-collect 1814604" above, but I never got an
indication the browser was trying to connect to the https server. So, I
am changing status to confirmed, as shown above.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814604
Title:
Alt-F1 aborts program when moving away from screen
Status in linux package in Ubuntu:
Confirmed
Bug description:
This problem was introduced in the "4.15.0-44" or "4.15.0-45" kernel
in late January 2019. The same problem happens in 32 bit and 64 bit
systems -- both installed before January 2019 and AFTER the problem
was introduced (that is, complete new installations AFTER). I have an
Acer Aspire R15 laptop.
To reproduce the problem -- after the system boots:
Ctrl-Alt-F1 (unity) or Ctrl-Alt-F3 (gdm3). For arguments sake, I'll only
show unity.
type in:
cd /tmp
ed
a
And that puts you into the "ed" editor in "append" (add) mode.
Ctrl-Alt-F2 (or Alt-F2) and duplicate the typing in of F1 above
Ctrl-Alt-F3 (or Alt-F3) and duplicate the typing in of F1 above
Now, Ctrl-Alt-F1 (or Alt-F1) back to screen #1. It is at the system
prompt rather than and "ed" prompt, and the error "stdin: Resource
temporarily unavailable" is displayed. If you move to "Alt-F2" or
"Alt-F3", you don't see the error message there, and those screens
seem unaffected -- that is, it seems to affect only "Alt-F1". For
some reason screen #1 aborts the program that is running when you move
away from "Alt-F1". You can confirm that the program aborts when
moving away from "Alt-F1" rather than moving back to "Alt-F1" by doing
an "ssh" to that computer from another computer and doing a "ps -e |
egrep tty1" before and after moving away from "Alt-F1".
You can exit those "ed" sessions back to the system prompt by typing in:
.
q
lsb_release -rd
Description: Ubuntu 18.04.1 LTS
Release: 18.04
version.log --> Ubuntu 4.15.0-45.48-generic 4.15.18
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814604/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

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 1814604
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.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
** Tags added: bionic
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814604
Title:
Alt-F1 aborts program when moving away from screen
Status in linux package in Ubuntu:
Incomplete
Bug description:
This problem was introduced in the "4.15.0-44" or "4.15.0-45" kernel
in late January 2019. The same problem happens in 32 bit and 64 bit
systems -- both installed before January 2019 and AFTER the problem
was introduced (that is, complete new installations AFTER). I have an
Acer Aspire R15 laptop.
To reproduce the problem -- after the system boots:
Ctrl-Alt-F1 (unity) or Ctrl-Alt-F3 (gdm3). For arguments sake, I'll only
show unity.
type in:
cd /tmp
ed
a
And that puts you into the "ed" editor in "append" (add) mode.
Ctrl-Alt-F2 (or Alt-F2) and duplicate the typing in of F1 above
Ctrl-Alt-F3 (or Alt-F3) and duplicate the typing in of F1 above
Now, Ctrl-Alt-F1 (or Alt-F1) back to screen #1. It is at the system
prompt rather than and "ed" prompt, and the error "stdin: Resource
temporarily unavailable" is displayed. If you move to "Alt-F2" or
"Alt-F3", you don't see the error message there, and those screens
seem unaffected -- that is, it seems to affect only "Alt-F1". For
some reason screen #1 aborts the program that is running when you move
away from "Alt-F1". You can confirm that the program aborts when
moving away from "Alt-F1" rather than moving back to "Alt-F1" by doing
an "ssh" to that computer from another computer and doing a "ps -e |
egrep tty1" before and after moving away from "Alt-F1".
You can exit those "ed" sessions back to the system prompt by typing in:
.
q
lsb_release -rd
Description: Ubuntu 18.04.1 LTS
Release: 18.04
version.log --> Ubuntu 4.15.0-45.48-generic 4.15.18
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814604/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

Public bug reported:
This problem was introduced in the "4.15.0-44" or "4.15.0-45" kernel in
late January 2019. The same problem happens in 32 bit and 64 bit
systems -- both installed before January 2019 and AFTER the problem was
introduced (that is, complete new installations AFTER). I have an Acer
Aspire R15 laptop.
To reproduce the problem -- after the system boots:
Ctrl-Alt-F1 (unity) or Ctrl-Alt-F3 (gdm3). For arguments sake, I'll only show
unity.
type in:
cd /tmp
ed
a
And that puts you into the "ed" editor in "append" (add) mode.
Ctrl-Alt-F2 (or Alt-F2) and duplicate the typing in of F1 above
Ctrl-Alt-F3 (or Alt-F3) and duplicate the typing in of F1 above
Now, Ctrl-Alt-F1 (or Alt-F1) back to screen #1. It is at the system
prompt rather than and "ed" prompt, and the error "stdin: Resource
temporarily unavailable" is displayed. If you move to "Alt-F2" or
"Alt-F3", you don't see the error message there, and those screens seem
unaffected -- that is, it seems to affect only "Alt-F1". For some
reason screen #1 aborts the program that is running when you move away
from "Alt-F1". You can confirm that the program aborts when moving away
from "Alt-F1" rather than moving back to "Alt-F1" by doing an "ssh" to
that computer from another computer and doing a "ps -e | egrep tty1"
before and after moving away from "Alt-F1".
You can exit those "ed" sessions back to the system prompt by typing in:
.
q
lsb_release -rd
Description:Ubuntu 18.04.1 LTS
Release:18.04
version.log --> Ubuntu 4.15.0-45.48-generic 4.15.18
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
** Tags: bionic
** Attachment added: "lpsci-vnvn.log"
https://bugs.launchpad.net/bugs/1814604/+attachment/5235991/+files/lpsci-vnvn.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814604
Title:
Alt-F1 aborts program when moving away from screen
Status in linux package in Ubuntu:
Incomplete
Bug description:
This problem was introduced in the "4.15.0-44" or "4.15.0-45" kernel
in late January 2019. The same problem happens in 32 bit and 64 bit
systems -- both installed before January 2019 and AFTER the problem
was introduced (that is, complete new installations AFTER). I have an
Acer Aspire R15 laptop.
To reproduce the problem -- after the system boots:
Ctrl-Alt-F1 (unity) or Ctrl-Alt-F3 (gdm3). For arguments sake, I'll only
show unity.
type in:
cd /tmp
ed
a
And that puts you into the "ed" editor in "append" (add) mode.
Ctrl-Alt-F2 (or Alt-F2) and duplicate the typing in of F1 above
Ctrl-Alt-F3 (or Alt-F3) and duplicate the typing in of F1 above
Now, Ctrl-Alt-F1 (or Alt-F1) back to screen #1. It is at the system
prompt rather than and "ed" prompt, and the error "stdin: Resource
temporarily unavailable" is displayed. If you move to "Alt-F2" or
"Alt-F3", you don't see the error message there, and those screens
seem unaffected -- that is, it seems to affect only "Alt-F1". For
some reason screen #1 aborts the program that is running when you move
away from "Alt-F1". You can confirm that the program aborts when
moving away from "Alt-F1" rather than moving back to "Alt-F1" by doing
an "ssh" to that computer from another computer and doing a "ps -e |
egrep tty1" before and after moving away from "Alt-F1".
You can exit those "ed" sessions back to the system prompt by typing in:
.
q
lsb_release -rd
Description: Ubuntu 18.04.1 LTS
Release: 18.04
version.log --> Ubuntu 4.15.0-45.48-generic 4.15.18
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814604/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

Any movement on this?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1771276
Title:
linux 4.15 currupts ipsec packets over non ethernet devices
Status in linux package in Ubuntu:
Triaged
Status in linux source package in Bionic:
Confirmed
Bug description:
Linux 4.15 has a bug that currupts ipsec packets if they are received over a
non ethernet interface.
This is a serve showstopper bug for me since it breaks my VPN setup and locks
me out of my server.
see https://wiki.strongswan.org/issues/2571 and
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=87cdf3148b11
since 4.15 is already EOL, the only possibility is backporting the
linked patch
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1771276/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

I am seeing the same problem on a fully updated Ubuntu system running
Linux 4.15.0-45.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1814393
Title:
"make: write error: stdout" on parallel builds
Status in linux-signed package in Ubuntu:
New
Bug description:
- Release of Ubuntu: 18.04.1 LTS (Kubuntu).
- Package version: linux-image-4.15.0-44-generic,
linux-image-4.15.0-45-generic.
- Expected outcome: Large parallel make build completing properly.
- What happened instead: Build stops with "make: write error: stdout".
Full explanation:
Since the update to kernel 4.15.0-44 (linux-image-4.15.0-44-generic)
in Kubuntu Bionic I'm experiencing issues in my ThinkPad P52 laptop
during large parallel builds of source code (eg: a buildroot full
rebuild for a work project). Note that this reports isn't about kernel
builds, but about large project builds in general.
I don't think it's relevant, but I'm running those builds in an
schroot with the same Ubuntu Bionic distro I'm also using as main host
distro.
The specific error I get is this (in Spanish):
make[4]: error al escribir: stdout
I call Buildroot's make like this from KDE Konsole with "infinite
history buffer" enabled (uses a tmp file to store the logs):
V=1 make ...some stuff... 2>&1
However, the error is reproducible in Konsole even if I call make
without options and also if I use "limited (in-memory) history buffer"
as well as "no history buffer". Buildroot autoselects a
parallelization level (-j) automatically. In my case, I'm using a Xeon
E-2176 CPU with 12 threads.
Searching on the Internet I found a thread[1] where people from the
GNU Make project say that the error may be coming from the C runtime
library (and I suspect originating from the kernel).
I can NOT reproduce the issue on linux-image-4.15.0-43-generic
(selected from grub at boot), but I experience it with linux-
image-4.15.0-44-generic and linux-image-4.15.0-45-generic. That's why
I'm reporting this bug against the linux package.
Interestingly enough, I can NOT reproduce the issue on linux-
image-4.15.0-45-generic (haven't tried previous versions) when
building from xterm instead of Konsole. Unfortunately, this laptop has
a 4K screen and xterm isn't an option for me.
If I build redirecting stdout and stderr to different files to avoid
terminal output and then watching the stdout file with tail -f, the
tail command eventually finishes although the build continues and I
can keep watching it by running tail again. An infinite build loop
never finishes with this redirection (error not reproducible). Same
results with the 2>&1 redirection to a single file.
All this looks a bit like a poltergeist, but the only thing I'm sure
about is that it all started with the upgrade from 4.15.0-43 to -44
and it continues on -45.
Thank you.
[1]
http://gnu-make.2324884.n4.nabble.com/Spurious-quot-write-error-quot-on-parallel-builds-td15695.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1814393/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

From: https://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc2-trusty/CHANGES
I see the folowing changes for radeon:
Alex Deucher (13):
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
drm/radeon/dp: switch to the common i2c over aux code
drm/radeon: fix audio pin counts for DCE6+ (v2)
drm/radeon: disable mclk dpm on R7 260X
drm/radeon: fix runpm handling on APUs (v4)
drm/radeon: update CI DPM powertune settings
drm/radeon: add support for newer mc ucode on SI (v2)
drm/radeon: add support for newer mc ucode on CI (v2)
drm/radeon: re-enable mclk dpm on R7 260X asics
drm/radeon/si: make sure mc ucode is loaded before checking the size
drm/radeon/ci: make sure mc ucode is loaded before checking the size
Christian KÃ¶nig (2):
drm/radeon: apply more strict limits for PLL params v2
drm/radeon: improve PLL params if we don't match exactly v2
Christoph Jaeger (2):
...
drm/radeon: fix VCE fence command
Quentin Casasnovas (1):
drm/radeon: memory leak on bo reservation failure. v2
The:
Christian KÃ¶nig (2):
drm/radeon: apply more strict limits for PLL params v2
drm/radeon: improve PLL params if we don't match exactly v2
rings a bell for me, because I believe someone somewhere was saying that a
kernel parameter
speaking of PLL was fixing the problem... but people did not find PLL
parameters for radeon,
so people did not follow about that comment.
From:
https://www.x.org/releases/current/doc/man/man4/radeon.4.xhtml
I see:
Option "LVDSProbePLL" "boolean"
When BIOS panel information isn’t available (like on PowerBooks), it may still
be necessary to
use the firmware-provided PLL values for the panel or flickering will happen.
This option will
force probing of the current value programmed in the chip when X is launched in
that case.
This is only useful for LVDS panels (laptop internal panels). The default is on.
Also:
Option "DefaultTMDSPLL" "boolean"
Use the default driver provided TMDS PLL values rather than the ones provided
by the BIOS.
This option has no effect on Mac cards.
Enable this option if you are having problems with a DVI monitor using the
internal TMDS controller.
The default is off.
Also:
drm/radeon: update CI DPM powertune settings
ring an other bell, because I think I remember someone saying something about
DPM in some message.
Sorry for not being more specific.
A similar, older fixed closed bug:
https://bugzilla.kernel.org/show_bug.cgi?id=26552
** Bug watch added: Linux Kernel Bug Tracker #26552
https://bugzilla.kernel.org/show_bug.cgi?id=26552
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791312
Title:
ubuntu 18.04 flickering screen with Radeon X1600
Status in linux package in Ubuntu:
Confirmed
Bug description:
my laptop: HP Compaq nx9420
my grafic card:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV530/M56-P [Mobility Radeon X1600] (prog-if 00 [VGA controller])
attachment:
the bug-apport-file
Description:
I start ubuntu 18.04 LTS (Kernel 4.15.0.33) in textmode;
-> as soon as the kernel-module radeon.ko is loaded the screen starts
flickering
when starting the grafic-mode the flickering continues; so the screen is
unusable.
when setting the option "radeon.modeset=0" (thus: not use radeon drivers) the
screen does not flicker
but the resolution is limited to 1400x1050 (instead of natural 1680x1050)
so I can not use this as work-around
when using the old ubuntu 14.04.05 LTS (Kernel 3.13.0-157)
the screen is o.k. NO flickering in textmode, nice grafic, NO flickering
xrandr tells: 1680x1050 60.1
so I must stay on old ubuntu 14.04.05 ???
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791312/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

Ok, I have access at "work" on a Compaq nx9420, for a few days.
linux 3.15.0-rc2 is first one to flickers, but goes to busybox
linux 3.15.0-rc1 does not flickers, but goes to busybox
I found: mounting /dev/sda1 on /root: invalid argument
and then initrd not mounting.
previous version, 3.14.79: no flickers, boot to graphics mode
will try to study changes for 3.15.0-rc2
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791312
Title:
ubuntu 18.04 flickering screen with Radeon X1600
Status in linux package in Ubuntu:
Confirmed
Bug description:
my laptop: HP Compaq nx9420
my grafic card:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV530/M56-P [Mobility Radeon X1600] (prog-if 00 [VGA controller])
attachment:
the bug-apport-file
Description:
I start ubuntu 18.04 LTS (Kernel 4.15.0.33) in textmode;
-> as soon as the kernel-module radeon.ko is loaded the screen starts
flickering
when starting the grafic-mode the flickering continues; so the screen is
unusable.
when setting the option "radeon.modeset=0" (thus: not use radeon drivers) the
screen does not flicker
but the resolution is limited to 1400x1050 (instead of natural 1680x1050)
so I can not use this as work-around
when using the old ubuntu 14.04.05 LTS (Kernel 3.13.0-157)
the screen is o.k. NO flickering in textmode, nice grafic, NO flickering
xrandr tells: 1680x1050 60.1
so I must stay on old ubuntu 14.04.05 ???
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791312/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

This patch already landed in disco's Ubuntu-4.19.0-9.10 and since linux-
generic 4.19.0.12.13 landed in the disco release pocket today, I change
the disco entry from Fix Committed to Fix Released.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805802
Title:
[UBUNTU] qeth: fix length check in SNMP processing
Status in Ubuntu on IBM z Systems:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Cosmic:
Fix Released
Status in linux source package in Disco:
Fix Released
Bug description:
== SRU Justification ==
The response for a SNMP request can consist of multiple parts,
which the cmd callback stages into a kernel buffer until all
parts have been received. If the callback detects that the
staging buffer provides insufficient space, it bails out with
error.
This processing is buggy for the first part of the response -
while it initially checks for a length of 'data_len', it later
copies an additional amount of
'offsetof(struct qeth_snmp_cmd, data)' bytes.
== Fix ==
9a764c1e5968 ("s390/qeth: fix length check in SNMP processing")
== Regression Potential ==
Low. Changes limited to s390.
== Test Case ==
A test kernel was built with this patch and tested by the original bug
reporter.
The bug reporter states the test kernel resolved the bug.
== Original bug description ==
Description: qeth: fix length check in SNMP processing
Symptom: Undefined behaviour.
Problem: The response for a SNMP request can consist of multiple parts,
which the cmd callback stages into a kernel buffer until all
parts have been received. If the callback detects that the
staging buffer provides insufficient space, it bails out with
error.
This processing is buggy for the first part of the response -
while it initially checks for a length of 'data_len', it later
copies an additional amount of
'offsetof(struct qeth_snmp_cmd, data)' bytes.
Solution: Fix the calculation of 'data_len' for the first part of the
response.
Upstream-ID: 9a764c1e59684c0358e16ccaafd870629f2cfe67
Should be applied to all Ubuntu Releases in Service
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805802/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

Just verified that this patch already landed in disco kernel
Ubuntu-4.19.0-9.10, hence changing to Fix Released since we have linux-
generic 4.19.0.12.13 in disco as of today.
** Changed in: linux (Ubuntu Disco)
Status: Fix Committed => Fix Released
** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805802
Title:
[UBUNTU] qeth: fix length check in SNMP processing
Status in Ubuntu on IBM z Systems:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Cosmic:
Fix Released
Status in linux source package in Disco:
Fix Released
Bug description:
== SRU Justification ==
The response for a SNMP request can consist of multiple parts,
which the cmd callback stages into a kernel buffer until all
parts have been received. If the callback detects that the
staging buffer provides insufficient space, it bails out with
error.
This processing is buggy for the first part of the response -
while it initially checks for a length of 'data_len', it later
copies an additional amount of
'offsetof(struct qeth_snmp_cmd, data)' bytes.
== Fix ==
9a764c1e5968 ("s390/qeth: fix length check in SNMP processing")
== Regression Potential ==
Low. Changes limited to s390.
== Test Case ==
A test kernel was built with this patch and tested by the original bug
reporter.
The bug reporter states the test kernel resolved the bug.
== Original bug description ==
Description: qeth: fix length check in SNMP processing
Symptom: Undefined behaviour.
Problem: The response for a SNMP request can consist of multiple parts,
which the cmd callback stages into a kernel buffer until all
parts have been received. If the callback detects that the
staging buffer provides insufficient space, it bails out with
error.
This processing is buggy for the first part of the response -
while it initially checks for a length of 'data_len', it later
copies an additional amount of
'offsetof(struct qeth_snmp_cmd, data)' bytes.
Solution: Fix the calculation of 'data_len' for the first part of the
response.
Upstream-ID: 9a764c1e59684c0358e16ccaafd870629f2cfe67
Should be applied to all Ubuntu Releases in Service
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805802/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

** Tags added: disco
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1752251
Title:
Missing mcelog userspace package in bionic - or maybe linux kernel
config should disable mcelog_legacy
Status in linux package in Ubuntu:
Confirmed
Status in mcelog package in Ubuntu:
Confirmed
Bug description:
There is no mcelog package in bionic.
$ sudo apt install mcelog
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package mcelog is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'mcelog' has no installation candidate
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752251/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

** Changed in: linux (Ubuntu Trusty)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1764794
Title:
signing: only install a signed kernel
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Fix Committed
Status in linux source package in Xenial:
In Progress
Bug description:
We should switch the default kernel install to the signed kernel.
This makes it much harder to uninstall the signed kernel in
environments which enforce the kernel to be signed. Boot loaders
which can understand and validate it want the signed image, those
which do not should ignore the appended signature.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1764794/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

** Changed in: linux (Ubuntu Trusty)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1806380
Title:
linux-buildinfo: pull out ABI information into its own package
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Fix Committed
Status in linux source package in Xenial:
In Progress
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Cosmic:
Fix Released
Status in linux source package in Disco:
Fix Released
Bug description:
We have an increasing amount of ABI information which is currently
exposed via the primary binary packages. Little to none of this is
relevant to the end-user and does not deserve to use up space on their
system. Also the kernel developer who needs to update this data does
not want to downloads 10s of Megabytes of binary packages to extract
this information. Pull it all out and generate all data that would
require the actual binaries at kernel build time, package all of this
information into a new linux-buildinfo package for consumption. This
package is not installed by default.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806380/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

** Changed in: ubuntu-z-systems
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1812822
Title:
Guest crashed when detaching the ovs interface device
Status in Ubuntu on IBM z Systems:
Incomplete
Status in linux package in Ubuntu:
Incomplete
Status in qemu package in Ubuntu:
Incomplete
Bug description:
When detaching one openvswitch interface device with virsh detach-device, if
the port has been deleted from the ovs and the interface device has been
deleted. The virsh detach-device will fail with "error: Unable to read from
monitor: Connection reset by peer", the qemu is terminated and the log shows "
UNSETVNETLE ioctl() failed, File descriptor in bad state".
[Background] This error is originally found from the openstack KVM CI tempest
test. By investigating I found it's introduced by one ovs-vif patch, which
deletes the ovs port and delete the interface before detaching the device. You
can find the commit from https://bugs.launchpad.net/os-vif/+bug/1801072
Reproduced:
root@:~# ovs-vsctl del-port br0 tap9273235a-dd
root@:~# ip link del tap9273235a-dd
The interface device tap9273235a-dd has been removed from the host(ifconfg,
ovs-vsctl show) and can be found in the guest.(logon the guest, ip a it's in
down state)
root@:~# virsh detach-device kvm net.xml
error: Failed to detach device from net.xml
error: Unable to read from monitor: Connection reset by peer
The qemu has terminated and the log in /var/log/libvirt/qemu/kvm.log
TUNSETVNETLE ioctl() failed: File descriptor in bad state.
2019-01-18 08:16:11.304+: shutting down, reason=crashed
It seems the qemu tried to handle this interface, but in fact it has been
deleted. qemu couldn't read the file and give the error.
But I don't think the guest should be crashed directly for the file
descriptor error.
Environment:
Ubuntu 16.04.5 LTS
Linux (EC12) 4.4.0-141-generic
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5~cloud0)
libvirtd (libvirt) 4.0.0
net.xml
kvm.xml
kvm
59f71b47-16e4-401d-9d33-30bc1605a84a
524288
524288
1
/machine
hvm
destroy
restart
destroy
/usr/bin/qemu-system-s390x
libvirt-59f71b47-16e4-401d-9d33-30bc1605a84a
libvirt-59f71b47-16e4-401d-9d33-30bc1605a84a
+0:+0
+0:+0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1812822/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

Just verified that the 3 patches (bug description / SRU template) are included
in kernel 4.19 and since 4.19 laded in disco proposed today, I'm changing the
kernel entry to Fix Released (code is available in cosmic, too).
Changing project entry to Fix Released, too.
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1799184
Title:
[18.04 FEAT] zcrypt DD: introduce APQN tags to support deterministic
driver binding
Status in Ubuntu on IBM z Systems:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Bug description:
== SRU Justification ==
APQN tags in the zcrypt device driver are required to support
deterministic driver binding
With the introduction of KVM hw crypto virtualization (on s390x) the driver
bound to an AP queue device is no longer unique determined.
Therefore a deterministic hot plugging semantics of AP queues that may be
bound to multiple drivers is needed.
With the three listed commits here it will be possible to configure an AP
queue (APQN) as being bound to a particular driver even if the associate hw
gets intermittently lost and reconnected.
== Fixes ==
ac2b96f351d7d222 ("s390/zcrypt: code beautify")
7e0bdbe5c21cb831 ("s390/zcrypt: AP bus support for alternate driver(s)")
3d8f60d38e249f98 ("s390/zcrypt: hex string mask improvements for apmask and
aqmask")
== Patches ==
Git-commit: ac2b96f351d7d222
https://github.com/torvalds/linux/commit/ac2b96f351d7d222c46e524feca03005f3fa8d75
Author: Harald Freudenberger
Date: Fri Aug 17 12:36:01 2018 +0200
s390/zcrypt: code beautify
Code beautify by following most of the checkpatch suggestions:
- SPDX license identifier line complains by checkpatch
- missing space or newline complains by checkpatch
- octal numbers for permssions complains by checkpatch
- renaming of static sysfs functions complains by checkpatch
- fix of block comment complains by checkpatch
- fix printf like calls where function name instead of %s __func__
was used
- __packed instead of __attribute__((packed))
- init to zero for static variables removed
- use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros
No functional code changes or API changes!
Signed-off-by: Harald Freudenberger
Signed-off-by: Martin Schwidefsky
===
Git-commit 7e0bdbe5c21cb831
https://github.com/torvalds/linux/commit/7e0bdbe5c21cb8316a694e46ad5aad339f6894a6
Author: Harald Freudenberger
Date: Fri Jul 20 08:36:53 2018 +0200
s390/zcrypt: AP bus support for alternate driver(s)
The current AP bus, AP devices and AP device drivers implementation
uses a clearly defined mapping for binding AP devices to AP device
drivers. So for example a CEX6C queue will always be bound to the
cex4queue device driver.
The Linux Device Driver model has no sensitivity for more than one
device driver eligible for one device type. If there exist more than
one drivers matching to the device type, simple all drivers are tried
consecutively. There is no way to determine and influence the probing
order of the drivers.
With KVM there is a need to provide additional device drivers matching
to the very same type of AP devices. With a simple implementation the
KVM drivers run in competition to the regular drivers. Whichever
'wins' a device depends on build order and implementation details
within the common Linux Device Driver Model and is not
deterministic. However, a userspace process could figure out which
device should be bound to which driver and sort out the correct
binding by manipulating attributes in the sysfs.
If for security reasons a AP device must not get bound to the 'wrong'
device driver the sorting out has to be done within the Linux kernel
by the AP bus code. This patch modifies the behavior of the AP bus
for probing drivers for devices in a way that two sets of drivers are
usable. Two new bitmasks 'apmask' and 'aqmask' are used to mark a
subset of the APQN range for 'usable by the ap bus and the default
drivers' or 'not usable by the default drivers and thus available for
alternate drivers like vfio-xxx'. So an APQN which is addressed by
this masking only the default drivers will be probed. In contrary an
APQN which is not addressed by the masks will never be probed and
bound to default drivers but onny to alternate drivers.
Eventually the two masks give a way to divide the range of APQNs into
two pools: one pool of APQNs used by the AP bus and the default
drivers and thus via zcrypt drivers available to the userspace of the
system. And another pool where no zcrypt drivers are bound to and
which can be used by alternate

Just verified that the 3 patches (bug description / SRU template) are
included in kernel 4.19 and since 4.19 laded in disco proposed today,
I'm changing the kernel entry to Fix Committed (code is available in
cosmic, too).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1799184
Title:
[18.04 FEAT] zcrypt DD: introduce APQN tags to support deterministic
driver binding
Status in Ubuntu on IBM z Systems:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Bug description:
== SRU Justification ==
APQN tags in the zcrypt device driver are required to support
deterministic driver binding
With the introduction of KVM hw crypto virtualization (on s390x) the driver
bound to an AP queue device is no longer unique determined.
Therefore a deterministic hot plugging semantics of AP queues that may be
bound to multiple drivers is needed.
With the three listed commits here it will be possible to configure an AP
queue (APQN) as being bound to a particular driver even if the associate hw
gets intermittently lost and reconnected.
== Fixes ==
ac2b96f351d7d222 ("s390/zcrypt: code beautify")
7e0bdbe5c21cb831 ("s390/zcrypt: AP bus support for alternate driver(s)")
3d8f60d38e249f98 ("s390/zcrypt: hex string mask improvements for apmask and
aqmask")
== Patches ==
Git-commit: ac2b96f351d7d222
https://github.com/torvalds/linux/commit/ac2b96f351d7d222c46e524feca03005f3fa8d75
Author: Harald Freudenberger
Date: Fri Aug 17 12:36:01 2018 +0200
s390/zcrypt: code beautify
Code beautify by following most of the checkpatch suggestions:
- SPDX license identifier line complains by checkpatch
- missing space or newline complains by checkpatch
- octal numbers for permssions complains by checkpatch
- renaming of static sysfs functions complains by checkpatch
- fix of block comment complains by checkpatch
- fix printf like calls where function name instead of %s __func__
was used
- __packed instead of __attribute__((packed))
- init to zero for static variables removed
- use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros
No functional code changes or API changes!
Signed-off-by: Harald Freudenberger
Signed-off-by: Martin Schwidefsky
===
Git-commit 7e0bdbe5c21cb831
https://github.com/torvalds/linux/commit/7e0bdbe5c21cb8316a694e46ad5aad339f6894a6
Author: Harald Freudenberger
Date: Fri Jul 20 08:36:53 2018 +0200
s390/zcrypt: AP bus support for alternate driver(s)
The current AP bus, AP devices and AP device drivers implementation
uses a clearly defined mapping for binding AP devices to AP device
drivers. So for example a CEX6C queue will always be bound to the
cex4queue device driver.
The Linux Device Driver model has no sensitivity for more than one
device driver eligible for one device type. If there exist more than
one drivers matching to the device type, simple all drivers are tried
consecutively. There is no way to determine and influence the probing
order of the drivers.
With KVM there is a need to provide additional device drivers matching
to the very same type of AP devices. With a simple implementation the
KVM drivers run in competition to the regular drivers. Whichever
'wins' a device depends on build order and implementation details
within the common Linux Device Driver Model and is not
deterministic. However, a userspace process could figure out which
device should be bound to which driver and sort out the correct
binding by manipulating attributes in the sysfs.
If for security reasons a AP device must not get bound to the 'wrong'
device driver the sorting out has to be done within the Linux kernel
by the AP bus code. This patch modifies the behavior of the AP bus
for probing drivers for devices in a way that two sets of drivers are
usable. Two new bitmasks 'apmask' and 'aqmask' are used to mark a
subset of the APQN range for 'usable by the ap bus and the default
drivers' or 'not usable by the default drivers and thus available for
alternate drivers like vfio-xxx'. So an APQN which is addressed by
this masking only the default drivers will be probed. In contrary an
APQN which is not addressed by the masks will never be probed and
bound to default drivers but onny to alternate drivers.
Eventually the two masks give a way to divide the range of APQNs into
two pools: one pool of APQNs used by the AP bus and the default
drivers and thus via zcrypt drivers available to the userspace of the
system. And another pool where no zcrypt drivers are bound to and
which can be used by alternate drivers (like vfio-xxx) for their
needs. This division is hot-plug save and makes sure a APQN assigned
to an alternate driver is at no time somehow exploitable by the wrong
party.
The two masks are

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 1814555
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.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
** Tags added: cosmic
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814555
Title:
Ubuntu boot failure. 4.18.0-14 boot stalls. (does not boot)
Status in linux package in Ubuntu:
Incomplete
Bug description:
Today my Ubuntu (18.10) did an auto-upgrade to 4.18.0-14-generic,
requested a reboot, and was unable to boot. After the "Starting
Load/Save RF Kill Switch Status..." line it is waiting forever.
(Or/and doing something behind the scenes. After a while, even the HDD
indicator led go out.)
This is a permanent error, so kernel 4.18.0-14 does NOT boot.
I was able to boot with kernel 4.18.0-13. (By pressing Shift when grub
starts.)
My configuration is "nothing fancy", possibly-except the locale (ISO-8859-2,
hu and en), Xcfe4, gdm3, gnome-screensaver.
I have already upgraded to the latest packages. (sudo apt-get dist-upgrade)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814555/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

You have been subscribed to a public bug:
Today my Ubuntu (18.10) did an auto-upgrade to 4.18.0-14-generic,
requested a reboot, and was unable to boot. After the "Starting
Load/Save RF Kill Switch Status..." line it is waiting forever. (Or/and
doing something behind the scenes. After a while, even the HDD indicator
led go out.)
This is a permanent error, so kernel 4.18.0-14 does NOT boot.
I was able to boot with kernel 4.18.0-13. (By pressing Shift when grub starts.)
My configuration is "nothing fancy", possibly-except the locale (ISO-8859-2, hu
and en), Xcfe4, gdm3, gnome-screensaver.
I have already upgraded to the latest packages. (sudo apt-get dist-upgrade)
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: boot bot-comment
--
Ubuntu boot failure. 4.18.0-14 boot stalls. (does not boot)
https://bugs.launchpad.net/bugs/1814555
You received this bug notification because you are a member of Kernel Packages,
which is subscribed to linux in Ubuntu.
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

** Package changed: ubuntu => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814555
Title:
Ubuntu boot failure. 4.18.0-14 boot stalls. (does not boot)
Status in linux package in Ubuntu:
New
Bug description:
Today my Ubuntu (18.10) did an auto-upgrade to 4.18.0-14-generic,
requested a reboot, and was unable to boot. After the "Starting
Load/Save RF Kill Switch Status..." line it is waiting forever.
(Or/and doing something behind the scenes. After a while, even the HDD
indicator led go out.)
This is a permanent error, so kernel 4.18.0-14 does NOT boot.
I was able to boot with kernel 4.18.0-13. (By pressing Shift when grub
starts.)
My configuration is "nothing fancy", possibly-except the locale (ISO-8859-2,
hu and en), Xcfe4, gdm3, gnome-screensaver.
I have already upgraded to the latest packages. (sudo apt-get dist-upgrade)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814555/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1807686
Title:
efi-lockdown patch causes -EPERM for some debugfs files even though
CONFIG_LOCK_DOWN_KERNEL is not set
Status in Ubuntu on IBM z Systems:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Cosmic:
Fix Released
Status in linux source package in Disco:
Fix Released
Bug description:
== Comment: #0 - Dominik Klein - 2018-12-10
03:58:10 ==
There seems to be a bug in the efi-lockdown patch as applied on top of
vanilla for Cosmic kernels:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-cosmic.git/commit/fs/debugfs/file.c?id=a1ba65da9ceae481c154bfd1a2c1550e4566d986
Also seems to be present for Disco as of today:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-disco.git/commit/fs/debugfs/file.c?id=a1ba65da9ceae481c154bfd1a2c1550e4566d986
The problem is that part of the patch modifies kernel behavior
independently of CONFIG_LOCK_DOWN_KERNEL being set or not causing
issues on two debugfs files on s390x.
Vasily Gorbik has already analyzed the problem and has posted a proposed fix
here:
https://lkml.org/lkml/2018/11/21/634
https://lkml.org/lkml/2018/11/21/635
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1807686/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805414
Title:
[Ubuntu] kernel: zcrypt: reinit ap queue state machine
Status in Ubuntu on IBM z Systems:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Cosmic:
Fix Released
Status in linux source package in Disco:
Fix Released
Bug description:
== SRU Justification ==
The vfio device driver when receiving an ap queue device does
additional resets thereby removing the registration for
interrupts for the ap device done by the ap bus core
code. So when later the vfio driver releases the device and
one of the default zcrypt drivers takes care of the device
the interrupt registration needs to get renewed. The current
code does no renew and result is that requests send into such
a queue will never see a reply processed - the application
hangs.
This commit has also been cc'd to upstream stable.
== Fix ==
104f708fd ("s390/zcrypt: reinit ap queue state machine during device probe")
== Regression Potential ==
Low. Limited to s390.
== Original Bug Description ==
Description: kernel: zcrypt: reinit ap queue state machine
Symptom: Zcrypt ap queue device not operational at host level after a
kvm guest used it.
Problem: The vfio device driver when receiving an ap queue device does
additional resets thereby removing the registration for
interrupts for the ap device done by the ap bus core
code. So when later the vfio driver releases the device and
one of the default zcrypt drivers takes care of the device
the interrupt registration needs to get renewed. The current
code does no renew and result is that requests send into such
a queue will never see a reply processed - the application
hangs.
Solution: This patch adds a function which resets the aq queue state
machine for the ap queue device and triggers the walk through
the initial states (which are reset and registration for
interrupts). This function is now called before the driver's
probe function is invoked.
When the association between driver and device is released,
the driver's remove function is called. The current
implementation calls a ap queue function
ap_queue_remove(). This invokation has been moved to the ap
bus function to make the probe / remove pair for ap bus and
drivers more symmetric.
Reproduction: Set up an kvm guest to use one or more ap queues in
pass-through mode. Start the guest. Stop the guest. Reassign
the ap resources back to the host system. Run an application
which uses exactly this ap resources. Without the fix, the
application hangs; with the fix the application should run
fine.
Upstream commit(s):
104f708fd1241b22f808bdf066ab67dc5a051de5
Available on kernel.org
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805414/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp