** Description changed:
[NOTE]
- * Patches will be sent to the kernel-team mailing list
-once the test kernel has been verified by the reporter.
+ * Patches will be sent to the kernel-team mailing list
+ once the test kernel has been verified by the reporter.
[Impact]
- * Us
DROP
NOTE: Patches will be sent to the kernel-team mailing list
and more details/testing will be provided later today.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Mauricio Faria de Oliveira (mfo)
Status: Confirmed
** Changed in: linux (Ubuntu)
Assignee
** Description changed:
[NOTE]
* Patches will be sent to the kernel-team mailing list
once the test kernel has been verified by the reporter.
[Impact]
* Users may experience cpu hard lockups when performing
rigorous writes to NVMe drives.
* The fix addresses an s
** Description changed:
[NOTE]
* Patches will be sent to the kernel-team mailing list
once the test kernel has been verified by the reporter.
[Impact]
* Users may experience cpu hard lockups when performing
rigorous writes to NVMe drives.
* The fix addresses an s
** Description changed:
- [NOTE]
-
- * Patches will be sent to the kernel-team mailing list
- once the test kernel has been verified by the reporter.
-
[Impact]
* Users may experience cpu hard lockups when performing
rigorous writes to NVMe drives.
* The fix addresses an s
** Description changed:
- The following iptables connlimit rule can be breached
- with a multithreaded client and network device driver,
- due to a race in the conncount/connlimit code:
+ [Impact]
- # iptables -A INPUT -p tcp -m tcp --syn --dport \
- -m connlimit --connlimit-above 2000 -
Patch series posted to kernel-team mailing list:
[SRU B][PATCH 00/13] blk-wbt: fix for LP#1810998
https://lists.ubuntu.com/archives/kernel-team/2019-January/097675.html
[SRU C][PATCH 0/8] blk-wbt: fix for LP#1810998
https://lists.ubuntu.com/archives/kernel-team/2019-January/097689.html
--
You r
** Description changed:
[Impact]
- * Users may experience cpu hard lockups when performing
- rigorous writes to NVMe drives.
+ * Users may experience cpu hard lockups when performing
+rigorous writes to NVMe drives.
- * The fix addresses an scheduling issue in the original
- i
Patch v2 series posted to the kernel-team mailing list:
[SRU B][PATCH v2 0/7] blk-wbt: fix for LP#1810998
https://lists.ubuntu.com/archives/kernel-team/2019-January/097831.html
[SRU C][PATCH v2 0/6] blk-wbt: fix for LP#1810998
https://lists.ubuntu.com/archives/kernel-team/2019-January/097840.html
[SRU T][PATCH 0/3] netfilter: nf_conncount: fix for LP#1811094
https://lists.ubuntu.com/archives/kernel-team/2019-January/097878.html
[SRU X][PATCH 0/6] netfilter: nf_conncount: fix for LP#1811094
https://lists.ubuntu.com/archives/kernel-team/2019-January/097698.html
[SRU B][PATCH 0/5] netfilter:
Verification done for Cosmic.
cosmic-proposed:
---
- server:
root@shuckle:~# uname -a
Linux shuckle 4.18.0-14-generic #15-Ubuntu SMP Mon Jan 14 09:01:02 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
- client:
root@dixie:~# ruby client.rb 10.230.56.116 6000 3
Connecting to ["10.230.56.116"]:77
Verification done for Bionic.
bionic-proposed:
---
- server:
root@shuckle:~# uname -a
Linux shuckle 4.15.0-44-generic #47-Ubuntu SMP Mon Jan 14 11:26:59 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
- client:
root@dixie:~# ruby client.rb 10.230.56.116 6000 3
Connecting to ["10.230.56.116"]:777
Verification done on Cosmic (no errors seen on dmesg).
Waiting for verification on Bionic by the reporter.
root@shuckle:~# uname -a
Linux shuckle 4.18.0-14-generic #15-Ubuntu SMP Mon Jan 14 09:01:02 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
root@shuckle:~# fdisk /dev/nvme0n1 # create one partition
Verification done on Xenial.
- server:
root@shuckle:~# uname -a
Linux shuckle 4.4.0-142-generic #168-Ubuntu SMP Wed Jan 16 21:00:45 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
root@shuckle:~# iptables -F
root@shuckle:~# iptables -A INPUT -p tcp -m tcp --syn --dport -m connlimit
--connlimit-abo
Verification done on Cosmic for regression on an older adapter model,
I/O stress (iozone) finishes successfully, no errors seen in dmesg.
Waiting for verification on Bionic by the reporter.
root@dixie:~# fdisk /dev/sdb # create one partition
root@dixie:~# mkfs.ext4 /dev/sdb1
root@dixie:~# mount /
Verification done on Bionic, with the HWE kernel in Xenial
(i.e., 4.15.0-44.47~16.04.1 per the original reporter's environment)
The mpt3sas driver is running correctly -- the sosreport shows the
previous kernel had mpt3sas fault_state error messages repeatedly within
less than 10 minutes, and the
Verification done on Bionic (no errors seen on dmesg).
Still waiting on verification by the reporter (different hardware), but this
verification shows no regression in dmesg.
Same steps as described in the previous comment.
** Tags removed: verification-needed-bionic
** Tags added: verification-
The reporter verified the Bionic kernel successfully as well.
--
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/1810998
Title:
CPU hard lockup with rigorous writes to NVMe drive
Status in
Also marking Ubuntu / Groovy as Fix Released, as Groovy/devel has the
5.8 kernel already, which ships the fix.
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu Groovy)
Status: Won't Fix => Fix Released
--
You received this bug notifi
Marking X/F/G as Fix Released.
X/F got the patch via stable updates, thus no LP tag / bot messages.
Xenial version: 4.4.0-189.219
Focal version: 5.4.0-45.49
Groovy version: 5.8 and later.
** Changed in: linux (Ubuntu Xenial)
Status: Fix Committed => Fix Released
** Changed in: linux (U
Hey Brendan,
Thanks for reporting this bug.
It looks like the crashdump files didn't come through?
Could you please try to reproduce with the 5.8 kernel from Groovy on
your Bionic install?
These are the steps to install it.
Please remove the .list file as soon as you install the packages, to avo
Oops, please remove the --dry-run from apt install.
--
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/1895563
Title:
Kernel Oops: Rsyncing to bcache device w/o backing cache kernel panic
S
Hey Martin.
The issues reported on comment 1 and commment 24 have different stack
trace signatures, and do not seem to be the same issue at all.
I'll thus mark this bug as Invalid as apparently you couldn't reproduce
the original issue anymore.
If the new issue is still present with the latest 5
Hi Petar,
Thanks for the bug report.
Unfortunately there's little details about the error.
Could you please post a picture of your compute screen
once the 5.4 kernel fails to boot?
(after you removed the 'quiet' and 'splash' options in
the grub editor, and pressed ctrl-x to boot.)
Mainly looki
Thanks.
Ok, so there's nothing printed to console after grub loads the kernel
and initramfs.
The parameters in your grub config look good (kernel+initramfs+cmdline
w/ root= and ro.)
Could you please try without 'quiet splash' again, but add the options:
'earlyprintk=vga ignore_loglevel' ?
That
Ok, so nothing yet on the screen seems to suggest either
a graphics-related issue or a different, early problem.
The successful test to boot into recovery mode provides
a very good lead; thanks for coming up with that.
These are the 3 kernel options added by the recovery mode,
per the kern.log fi
Interesting.
For that you can add 'dis_ucode_ldr' in GRUB_CMDLINE_LINUX_DEFAULT in
/etc/default/grub.
Then run 'sudo update-grub', and confirm the change with 'grep dis_ucode_ldr
/boot/grub/grub.cfg'.
You should see non-recovery lines w/ that option as well.
Could you please upload /proc/cpuinf
Hi ~richard-from-davel and ~marco-zannoni,
Could you please test kernel 5.4.0-48, just released to
focal-updates a few hours ago and confirm it that helps?
It has fixes for two of the four patches introduced between
5.4.0-42 and 5.4.0-45/-47 (reported to be good/bad versions.)
Thanks,
Mauricio
Hi Petar,
Thanks for providing the files.
The original issue, boot failure, seems to be a conflict between the 5.4
kernel and the intel-microcode blob, since the same blob works fine in
the 4.15 kernel.
(For the printout alignment issue, let's track that on another bug
report.)
Let's try to bis
Details:
4.15 kernel:
[0.00] kernel: microcode: microcode updated early to revision
0xdc, date = 2020-04-27
[0.00] kernel: Linux version 4.15.0-112-generic
(buildd@lcy01-amd64-027)
[0.00] kernel: Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0
Hi Richard,
That's really good news that the 5.4.0-48 kernel does seem to fix it.
Thanks for the quick turnaround on testing under these circumstances.
cheers,
Mauricio
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
htt
Oh sorry, I'm not familiar with OCFS2, but maybe you need to have
both servers/whole cluster on same kernel version to verify 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/1895526
T
Thanks Richard and Marco!
Looking forward for further testing/results. :)
Fingers crossed it will all go well.
--
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/1895526
Title:
ocfs2 file s
** Tags removed: sts-sponsor-mfo
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1869465
Title:
Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Status in makedumpfile packa
Hi Jim,
This is a conflict between the (un)signed kernel packages; but it's easy
to solve:
Please remove the linux-image-5.4.0-47-generic package and try
installing again; e.g.,
$ sudo apt purge linux-image-5.4.0-47-generic # confirm to remove the running
kernel if asked.
$ sudo dpkg -i *.deb #
Hey,
Could you please collect the stack traces of the kworker process while
the issue happens?
1) Once it starts, get its PID (eg, 86069) and run:
$ pid=86069; while sleep 1; do ts="$(date +'%F-%H-%M-%S')"; sudo cat
/proc/$pid/stack > /tmp/stack.$pid.$ts; done
2) Once it stops, press ctrl-c to
It looks like you have secure boot enabled.
Unfortunately test kernels are unsigned and thus require it to be disabled in
your BIOS/EFI menu.
--
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
Hey Jim,
That's very good news!
I believe Alex should send you more test kernels,
with different sets of patches included/removed,
so to bisect/identify which specific patch(es)
resolve the problem.
If you could help with testing that as well,
that would be great, so a smaller patch(set)
can be
Hi Jim,
You can install on top of the previous ones without removing them first.
The versioning of the test packages used the same 5.4.0-47 number,
so unfortunately they will keep overwriting themselves (including
the original/non-test 5.4.0-47 kernel.)
I'd think this is why you only see two ent
The kworker processes are generic in that they can do work for many kernel
parts,
so a particular kworker/number unfortunately doesn't help much to understand the
actual thing that the kworker was doing; we'll need the stack traces for that.
:)
Yes, if and once the issue starts happening again,
Petar, thanks.
Good news that a previous 5.4 kernel works; it makes the search smaller.
- 5.4.0-26 good
- 5.4.0-48 bad
Let's try 5.4.0-37.
Could you please download its .deb files, install with 'dpkg -i *.deb',
and test it without dis_ucode_ldr?
This list includes linux-modules-extra and heade
Sure, that would work more efficiently.
The URLs change for every new version/package build.
You can get get to the .deb files this way:
1) Go to https://launchpad.net/ubuntu/focal/+source/linux
2) Click on the version under 'Releases in Ubuntu'
(some versions are listed multiple times, but poin
Hi Petar,
Thanks for the bisection, but it seems something is a bit off.
The only change between 5.4.0-26 and -28 is a patch for s390x,
which is a different architecture, nothing to do with amd64,
and no common files are changed.
Could you please review the dis_ucode_ldr parameter is what
you ex
Hi Petar,
I just asked for a double-check of -26 and -28 as you've done.
Thanks, and sorry if that wasn't clear.
The difference in the source code is just for reference purposes,
you don't have to act on it -- the available packages/builds are
already with (-28) and without (-26) it.
Your test d
Hi Chris,
Thanks for reporting this bug.
The faulting memory addresses alone are not sufficient to have an idea
of what is going on.
Also, they might not necessarily indicate a memory problem, but
incorrect code in whatever part of the kernel, targeting a memory
address that is incorrectly calcu
Hi Brendan,
Thanks for testing! Glad that 5.0 and 5.8 works, so this is already
fixed.
For now, I'd suggest bisecting with the already available/built kernel
packages from the launchpad archive, which should be faster;
then eventually get down to git to identify it more closely.
Since you know t
Ah, there's a more recent 4.18.0-26 package, in the cosmic linux archive,
if it comes down to this.
https://launchpad.net/ubuntu/cosmic/+source/linux
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.
alg_accept+0x15/0x20 [af_alg]
+ SYSC_accept4+0xff/0x210
+ SyS_accept+0x10/0x20
+ do_syscall_64+0x73/0x130
+ entry_SYSCALL_64_after_hwframe+0x3d/0xa2
** Also affects: linux (Ubuntu Groovy)
Importance: Medium
Assignee: Mauricio Faria de Oliveira (mfo)
Status: Con
** Description changed:
[Impact]
- * Users of the Linux kernel's crypto userspace API
-reported BUG() / kernel NULL pointer dereference
-errors after kernel upgrades.
+ * Users of the Linux kernel's crypto userspace API
+ reported BUG() / kernel NULL pointer dereference
+ erro
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Bionic)
Focal: testing
=
$ ./stress-ng --version
stress-ng, version 0.11.14 (gcc 9.3, x86_64 Linux 5.4.0-38-generic) 💻🔥
$ sudo modprobe -a \
$(modinfo \
/lib/modules/$(uname -r)/kernel/crypto/*.ko \
/lib/modules/$(uname -r)/kernel/arch/*/crypto/*.ko \
[E/F/Unstable][PATCH 0/1] crypto: fix regression/use-after-free in
af_alg_accept()
https://lists.ubuntu.com/archives/kernel-team/2020-June/111620.html
[E/F/Unstable][PATCH 1/1] crypto: af_alg - fix use-after-free in
af_alg_accept() due to bh_lock_sock()
https://lists.ubuntu.com/archives/kernel-
Eoan: testing
original:
$ uname -rv
5.3.0-62-generic #56-Ubuntu SMP Tue Jun 23 11:20:52 UTC 2020
$ ./stress-ng --version
stress-ng, version 0.11.14 (gcc 9.2, x86_64 Linux 5.3.0-62-generic) 💻🔥
$ ./stress-ng --af-alg 0 --timeout 1h 2>&1 | tee
Bionic: testing
==
original:
$ uname -rv
4.15.0-107-generic #108-Ubuntu SMP Mon Jun 8 17:51:33 UTC 2020
$ ./stress-ng --version
stress-ng, version 0.11.14 (gcc 7.5, x86_64 Linux 4.15.0-107-generic) 💻🔥
$ ./stress-ng --af-alg 0 --timeout 1h 2>&
Xenial
==
original:
$ uname -rv
4.4.0-185-generic #215-Ubuntu SMP Mon Jun 8 21:53:19 UTC 2020
$ ./stress-ng --version
stress-ng, version 0.11.14 (gcc 5.4, x86_64 Linux 4.4.0-185-generic) 💻🔥
$ ./stress-ng --af-alg 0 --timeout 30m 2>&1 | tee
.
Disco: testing
=
original:
$ uname -rv
5.0.0-38-generic #41-Ubuntu SMP Tue Dec 3 00:27:35 UTC 2019
$ ./stress-ng --version
stress-ng, version 0.11.14 (gcc 8.3, x86_64 Linux 5.0.0-38-generic) 💻🔥
$ ./stress-ng --af-alg 0 --timeo
Common to all test runs: stress-ng version,
and command to load as many crypto modules
as found/possible in the system.
$ ./stress-ng --version
stress-ng, version 0.11.14 () 💻🔥
$ sudo modprobe -a \
$(modinfo \
/lib/modules/$(uname -r)/kernel/crypto/*.ko \
/li
Hi Matthew,
This looks like the symptoms of an Intel processor errata,
'Unexpected Page Faults in Guest Virtualization Environment'.
It should be fixed with Intel microcode updates of 2019/11/15.
This has been shipped on Ubuntu intel-microcode package
version 3.20191115.1ubuntu0.18.04.1 for Bion
This fix has already been released as part of the kernel stable updates.
** Changed in: linux (Ubuntu Xenial)
Status: Incomplete => Opinion
** Changed in: linux (Ubuntu Xenial)
Status: Opinion => Fix Released
** Changed in: linux (Ubuntu Bionic)
Status: Incomplete => Fix Rel
Verification done on Eoan.
The apparmor label refcnt inc/dec-rements properly on accept()/release(), no
leaks.
$ lsb_release -cs
eoan
$ uname -rv
5.3.0-63-generic #57-Ubuntu SMP Thu Jul 2 10:38:35 UTC 2020
$ apt-cache policy linux-image-$(uname -r)
linux-image-5.3.0-63-generic:
...
*** 5.3.0-6
Medium
Assignee: Mauricio Faria de Oliveira (mfo)
Status: In Progress
** Also affects: linux (Ubuntu Eoan)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided =
Xenial / Testing
==
modified
$ uname -rv
4.4.0-186-generic #216+lp1867916.1 SMP Mon Jul 6 18:45:47 -03 2020
$ sudo make-bcache --bdev $DEV --block 8k
[ 60.860259] bcache: bcache_device_init() bcache0: sb/logical block size
(8192) greater than page size (4096) falling back to devi
Bionic / Testing
==
modified
$ uname -rv
4.15.0-110-generic #111+lp1867916.1 SMP Mon Jul 6 19:09:14 -03 2020
$ sudo make-bcache --bdev $DEV --block 8k
[ 22.066760] bcache: bcache_device_init() bcache0: sb/logical block size
(8192) greater than page size (4096) falling back to dev
Disco / Testing
=
* Using the linux-hwe-5.0 from "Disco" (EOL) on Bionic for the 5.0
kernel.
modified
$ uname -rv
5.0.0-57-generic #61~18.04.1+lp1867916.1 SMP Mon Jul 6 19:27:05 -03 2020
$ sudo make-bcache --bdev $DEV --block 8k
[ 109.818171] bcache: bcache_device_init() bcache0:
Eoan / Testing
modified
$ uname -rv
5.3.0-63-generic #57+lp1867916.1 SMP Mon Jul 6 18:33:27 -03 2020
$ sudo make-bcache --bdev $DEV --block 8k
[ 29.620685] bcache: bcache_device_init() bcache0: sb/logical block size
(8192) greater than page size (4096) falling back to device log
Focal / Testing
=
modified
$ uname -rv
5.4.0-41-generic #45+lp1867916.1 SMP Mon Jul 6 16:41:46 -03 2020
$ sudo make-bcache --bdev $DEV --block 8k
[ 29.593270] bcache: bcache_device_init() bcache0: sb/logical block size
(8192) greater than page size (4096) falling back to device l
[X/B/D/E/F][PATCH 0/1] bcache: fix oops for block size > page size
https://lists.ubuntu.com/archives/kernel-team/2020-July/111846.html
--
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/1867916
Test kernels with the fix are available in:
https://people.canonical.com/~mfo/lp1867916/
--
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/1867916
Title:
Regression in kernel 4.15.0-91 caus
Hey Sebastian! Great; thanks for testing!
--
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/1867916
Title:
Regression in kernel 4.15.0-91 causes kernel panic with Bcache
Status in Linux:
tu Xenial)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Eoan)
Status: In Progress => Fix Committed
--
You received this bug notification because you are
Hi Pedro,
It's curious that the message is repeatedly showing up at the rate of a few
seconds.
It would initially suggest something might be wrong with the PCI device.
(As Alex mentioned the errors are correctable, so not a serious issue,
but the fact they're being repeatedly logged doesn't soun
Indeed; I was hoping to check what's under the root port just in case,
but acknowledge that might not be helpful / have too much stuff under,
being a desktop system. Let's see. :)
Per the repeated messages I'd imagine this is a device-related error,
but wanted to check the kernel version log in ca
Verification done on "Disco" (linux-hwe-5.0)
---
# uname -rv
5.0.0-58-generic #62~18.04.1-Ubuntu SMP Tue Jul 14 03:37:30 UTC 2020
For some other reason the kprobes module is not picking up on accept,
only on release. This is unrelated to this patchset.
I used kprobe events instead, which is work
Hi Sebastian, don't worry, we'll use the synthetic reproducer for the
verification steps.
--
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/1867916
Title:
Regression in kernel 4.15.0-91 cau
Verification done on xenial-proposed.
The kernel in -proposed logs the block size change.
The kernel in -updates fails.
xenial-proposed:
---
$ uname -rv
4.4.0-187-generic #217-Ubuntu SMP Tue Jul 21 04:18:15 UTC 2020
$ apt-cache madison linux-image-4.4.0-187-generic
Hi Benjamin,
Thanks for the detailed report.
Does this system show signs of memory pressure?
bch_mca_scan() is part of bcache's memory shrinker, and thus should be
called when the system is trying to release memory from its several
caches.
Also, the bucket lock usage is widespread in bcache (fr
Hi Benjamin,
It's interesting that the memory shrinkers are being invoked without memory
pressure.
I'll try to understand it better, maybe I'm missing something.
I guess the before/after memory sizes for the test are swapped?
i.e., to alleviate potential memory pressure the VM's memory had
been
Hi Rauno,
Thanks for reporting this bug; nice finding on pci=noats.
$ grep -A1 noats ~/git/linux/Documentation/admin-guide/kernel-parameters.txt
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
Wonderin
Hi Petar,
Thanks for letting us know, and sorry it wasn't possible to get back to
this bug.
I'll mark it as Invalid as the root cause isn't know; but glad it's
working now.
** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a
Hi Anand,
Yes, that patch is available since 4.4.0-185.215.
Please note that this version if for the linux-image-4.4.0-185-generic
package.
You mentioned version numbers for the linux-generic meta package (which
pulls in linux-image--generic package as a dependency.)
Either way, the first numbe
Verification done for Bionic.
$ uname -rv
4.15.0-113-generic #114-Ubuntu SMP Sun Aug 9 07:27:58 UTC 2020
$ sudo make-bcache --bdev $DEV --block 8k
...
[ 18.467465] bcache: bcache_device_init() bcache0: sb/logical block size
(8192) greater than page size (4096) falling back to device logical bl
Verification done for Bionic.
$ uname -rv
4.15.0-113-generic #114-Ubuntu SMP Sun Aug 9 07:27:58 UTC 2020
$ ./aa-refcnt-af_alg &
$ sudo insmod kmod.ko
...
[ 335.387236] release() :: comm = aa-refcnt-af_al, pid = 5764,
sk->sk_security->label->c
Verification done for Focal.
$ uname -rv
5.4.0-43-generic #47-Ubuntu SMP Sat Aug 8 06:34:35 UTC 2020
$ ./aa-refcnt-af_alg &
$ sudo insmod kmod.ko
...
[ 171.672847] accept() :: comm = aa-refcnt-af_al, pid = 1600,
sk->sk_security->label->count = 0x583
[ 171.674249] release() :: comm = aa-refcnt-
Verification done for Focal.
$ uname -rv
5.4.0-43-generic #47-Ubuntu SMP Sat Aug 8 06:34:35 UTC 2020
$ sudo make-bcache --bdev $DEV --block 8k
...
[ 71.251993] bcache: bcache_device_init() bcache0: sb/logical block size
(8192) greater than page size (4096) falling back to device logical block
Verification done for bionic-proposed.
The reporter user confirmed that the organic reproducer (Varnish Cache
Plus with the Crypto vmod) ran successfully over the weekend with the
4.15.0-114-generic kernel, to approximately 3 days (2d 20h runtime.)
The same workload used to trigger the bug with a
Verification done on "eoan" (5.3/linux-hwe on Bionic)
$ uname -rv
5.3.0-65-generic #59-Ubuntu SMP Tue Jul 28 07:27:41 UTC 2020
$ sudo make-bcache --bdev $DEV --block 8k
...
[ 103.766185] bcache: bcache_device_init() bcache0: sb/logical block size
(8192) greater than page size (4096) falling bac
I've also ran stress-ng as in comment #1 (below) on 4 CPUs for 8 hours
on X/B/F.
No signs of issues: it finishes successfully and no weird messages in
the kernel logs.
$ sudo modprobe -a \
$(modinfo \
/lib/modules/$(uname -r)/kernel/crypto/*.ko \
/lib/modules
Oh, and for "Eoan" (5.3/linux-hwe on Bionic), all good with stress-ng as
well.
$ uname -rv
5.3.0-66-generic #60-Ubuntu SMP Tue Aug 11 08:42:43 UTC 2020
$ ./stress-ng --version && ./stress-ng --af-alg 0 --timeout 2h 2>&1 | tee
../stress-ng.log.eoan-bionic-proposed
stress-ng, version 0.11.14 (gcc
/torvalds/linux.git/commit/?id=7c15d41016dc886cc011e3854d855e219759ae68
** Affects: linux (Ubuntu)
Importance: Medium
Assignee: Mauricio Faria de Oliveira (mfo)
Status: Fix Committed
** Affects: linux (Ubuntu Bionic)
Importance: High
Assignee: Mauricio Faria de Oliv
[224259.453356] [ cut here ]
[224259.453360] kernel BUG at
/build/linux-eTBZpZ/linux-4.15.0/fs/btrfs/ctree.c:3233!
[224259.453390] illegal operation: 0001 ilc:1 [#1] SMP
[224259.453392] Modules linked in: vhost_net xt_nat macvtap tap veth macvlan
ipt_MASQUERADE nf_nat_masq
Regression testing done with 3 approaches:
1) synthetic reproducer in kernel.org BZ#202833 [1]
2) stress-ng --class filesystem,io
3) xfstests (aka fstests)
No regressions observed in Bionic/Focal/Groovy between original/patched
kernels, in s390x native VMs in canonistack-bos01.
--
You received
[1] kernel.org BZ#202833
https://bugzilla.kernel.org/show_bug.cgi?id=202833
--
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/1902254
Title:
Bionic: btrfs: kernel BUG at /build/linux-
3) xfstests (aka fstests)
Compared the 'consistently fail set' and 'likelyhood to fail' in flaky tests
(see below.)
No regressions.
Details:
---
Source:
- git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
- commit 31f6949f ("ext4: verify unwritten extent conversion in buff-io")
The test se
Bionic/xfstests
==
Original/patched kernel versions:
$ grep -h ^PLATFORM xfstests.log.* | sort -u
PLATFORM -- Linux/s390x mfo-s390x-bionic 4.15.0-122-generic
#124+test20201026b1 SMP Mon Oct 26 13:10:37 -03 2020
PLATFORM -- Linux/s390x mfo-s390x-bioni
2) stress-ng --class filesystem,io
Compared the stress-ng output and kernel log between original/patched kernels.
No regressions.
Actually, in Bionic the original kernel didn't even finish stress-ng in ~20
hours, while the patched kernel finished it in ~1.5 hours (in line w/ other the
releases.
Focal/xfstests
=
"pre-original"/original/patched kernel versions:
$ grep -h ^PLATFORM xfstests.log.* | sort -u
PLATFORM -- Linux/s390x mfo-s390x-focal 5.4.0-52-generic
#57+test20201026b1 SMP Mon Oct 26 19:12:47 -03 2020
PLATFORM -- Linux/s390x mfo-s3
1) synthetic reproducer
The reproducer consists in a crafted disk/btrfs image and C test-case.
This has not been helpful.
In Bionic, the crafted disk/btrfs image does not even mount.
In Focal/Groovy it does mount, but the test-case does not trigger any errors.
Anyway, the behavior is the same in
Groovy/xfstests
==
Original/patched kernel versions:
$ grep -h ^PLATFORM xfstests.log.* | sort -u
PLATFORM -- Linux/s390x mfo-s390x-groovy 5.8.0-25-generic
#26+test20201026b1 SMP Mon Oct 26 19:02:54 -03 2020
PLATFORM -- Linux/s390x mfo-s390x-groovy 5
[B/F/G][PATCH 0/7] btrfs: Fix kernel BUG at fs/btrfs/ctree.c:3233 /
btrfs_set_item_key_safe()
https://lists.ubuntu.com/archives/kernel-team/2020-October/114398.html
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https:/
Verification done for groovy-proposed.
No regressions in consistent/flaky fail set.
Proposed kernel:
---
$ uname -rv
5.8.0-30-generic #32-Ubuntu SMP Mon Nov 9 21:02:16 UTC 2020
$ VERSION='5.8.0-30-generic #32-Ubuntu'
Number of runs:
$ grep -h -e ^Fail -e ^PLATFORM xfstests.log.* | grep -A1 "$V
301 - 400 of 727 matches
Mail list logo
