[Group.of.nepali.translators] [Bug 2046356] Re: Update URL for Support information in MOTD message
Notes: - Added bug task for Lunar (lunar MR is linked/approved; lunar-unapproved has an upload). - Checked that Bionic and Xenial have no conflicting packages/versions in the ESM archive. ** Also affects: base-files (Ubuntu Lunar) Importance: Undecided Status: New ** Changed in: base-files (Ubuntu Lunar) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/2046356 Title: Update URL for Support information in MOTD message Status in base-files package in Ubuntu: Fix Released Status in base-files source package in Xenial: In Progress Status in base-files source package in Bionic: In Progress Status in base-files source package in Focal: In Progress Status in base-files source package in Jammy: In Progress Status in base-files source package in Lunar: In Progress Status in base-files source package in Mantic: In Progress Status in base-files source package in Noble: Fix Released Bug description: [Impact] When users see the MOTD message, they are currently seeing an outdated url under the support information. Even though the outdated url redirects to new Ubuntu Pro webpage, we believe the users should still see the correct url from the start [Test Case] - Launch a LXD container for any of the affected releases - Install the package with this fix applied - Install `update-motd` package - Run `update-motd` and confirm the Support url is now the correct one [Regression Potential] If users are parsing MOTD for some reason, the url change might break that logic now. However, parsing MOTD messages is not a supported flow, so we believe regression potential is low here. [Discussion] Since we want users to be aware of what Ubuntu Pro is, we should highlight the right product name on any place that is still using the old "advantage" name. Updating the support URL here is a step into this direction [Original Bug Description] On the file 10-help-text, we are printing the following line on MOTD: * Support: https://ubuntu.com/advantage We should update the url to https://ubuntu.com/pro instead, as this will the default url for support information now To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2046356/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1873074] Re: kernel panic hit by kube-proxy iptables-save/restore caused by aufs
** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1873074 Title: kernel panic hit by kube-proxy iptables-save/restore caused by aufs Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Won't Fix Bug description: [Impact] * Systems with aufs mounts are vulnerable to a kernel BUG(), which can turn into a panic/crash if panic_on_oops is set. * It is exploitable by unprivileged local users; and also remote access operations (e.g., web server) potentially. * This issue has also manifested in Kubernetes deployments with a kernel panic in iptables-save or iptables-restore after a few weeks of uptime, without user interaction. * Usually all Kubernetes worker nodes hit the issue around the same time. [Fix] * The issue is fixed with 2 patches in aufs4-linux.git: - 515a586eeef3 aufs: do not call i_readcount_inc() - f10aea57d39d aufs: bugfix, IMA i_readcount * The first addresses the issue, and the second addresses a regression in the aufs feature to change RW branches to RO. * The kernel v5.3 aufs patches had an equivalent fix to the second patch, which is present in the Focal aufs patchset (and on ubuntu-unstable/master & /master-5.8 on 20200629) - 1d26f910c53f aufs: for v5.3-rc1, maintain i_readcount (in aufs5-linux.git) [Test Case] * Repeatedly open/close the same file in read-only mode in aufs (UINT_MAX times, to overflow a signed int back to 0.) * Alternatively, monitor the underlying filesystems's file inode.i_readcount over several open/close system calls. (should not monotonically increase; rather, return to 0.) [Regression Potential] * This changes the core path that aufs opens files, so there is a risk of regression; however, the fix changes aufs for how other filesystems work, so this generally is OK to do. In any case, most regressions would manifest in open() or close() (where the VFS handles/checks inode.i_readcount.) * The aufs maintainer has access to an internal test-suite used to validate aufs changes, used to identify the first regression (in the branch RW/RO mode change), and then to validate/publish the patches upstream; should be good now. * This has also been tested with 'stress-ng --class filesystem' and with 'xfstests -overlay' (patch to use aufs vs overlayfs) on Xenial/Bionic/Focal (-proposed vs. -proposed + patches). No regressions observed in stress-ng/xfstests log or dmesg. [Other Info] * Applied on Unstable (branches master and master-5.8) * Not required on Groovy (still 5.4; should sync from Unstable) * Required on LTS releases: Bionic and Focal and Xenial. * Required on other releases: Disco and Eoan (for custom kernels) [Original Bug Description] Problem Report: -- An user reported several nodes in their Kubernetes clusters hit a kernel panic at about the same time, and periodically (usually 35 days of uptime, and in same order nodes booted.) The kernel panics message/stack trace are consistent across nodes, in __fput() by iptables-save/restore from kube-proxy. Example: """ [3016161.866702] kernel BUG at .../include/linux/fs.h:2583! [3016161.866704] invalid opcode: [#1] SMP ... [3016161.866780] CPU: 40 PID: 33068 Comm: iptables-restor Tainted: P OE 4.4.0-133-generic #159-Ubuntu ... [3016161.866786] RIP: 0010:[...] [...] __fput+0x223/0x230 ... [3016161.866818] Call Trace: [3016161.866823] [...] fput+0xe/0x10 [3016161.866827] [...] task_work_run+0x86/0xb0 [3016161.866831] [...] exit_to_usermode_loop+0xc2/0xd0 [3016161.866833] [...] syscall_return_slowpath+0x4e/0x60 [3016161.866839] [...] int_ret_from_sys_call+0x25/0x9f """ (uptime: 3016161 seconds / (24*60*60) = 34.90 days) They have provided a crashdump (privately available) used for analysis later in this bug report. Note: the root cause turns out to be independent of K8s, as explained in the Root Cause section. Related Report: -- This behavior matches this public bug of another user: https://github.com/kubernetes/kubernetes/issues/70229 """ I have several machines happen kernel panic，and these machine have same dump trace like below: KERNEL: /usr/lib/debug/boot/vmlinux-4.4.0-104-generic ... PANIC: "kernel BUG at .../include/linux/fs.h:2582!" ... COMMAND: "iptables-restor" ... crash> bt ... [exception RIP: __fput+541]
[Group.of.nepali.translators] [Bug 1884766] Re: use-after-free in af_alg_accept() due to bh_lock_sock()
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1884766
Title:
use-after-free in af_alg_accept() due to bh_lock_sock()
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Eoan:
Won't Fix
Status in linux source package in Focal:
Fix Released
Status in linux source package in Groovy:
Fix Released
Bug description:
[Impact]
* Users of the Linux kernel's crypto userspace API
reported BUG() / kernel NULL pointer dereference
errors after kernel upgrades.
* The stack trace signature is an accept() syscall
going through af_alg_accept() and hitting errors
usually in one of:
- apparmor_sk_clone_security()
- apparmor_sock_graft()
- release_sock()
[Fix]
* This is a regression introduced by upstream commit
37f96694cf73 ("crypto: af_alg - Use bh_lock_sock
in sk_destruct") which made its way through stable.
* The offending patch allows the critical regions
of af_alg_accept() and af_alg_release_parent() to
run concurrently; now with the "right" events on 2
CPUs it might drop the non-atomic reference counter
of the alg_sock then the sock, thus release a sock
that is still in use.
* The fix is upstream commit 34c86f4c4a7b ("crypto:
af_alg - fix use-after-free in af_alg_accept() due
to bh_lock_sock()") [1]. It changes alg_sock's ref
counter to atomic, which addresses the root cause.
[Test Case]
* There is a synthetic test case available, which
uses a kprobes kernel module to synchronize the
concurrent CPUs on the instructions responsible
for the problem; and a userspace part to run it.
* The organic reproducer is the Varnish Cache Plus
software with the Crypto vmod (which uses kernel
crypto userspace API) under long, very high load.
* The patch has been verified on both reproducers
with the 4.15 and 5.7 kernels.
* More tests performed with 'stress-ng --af-alg'
with 11 CPUs on Xenial/Bionic/Disco/Eoan/Focal
(all on same version of stress-ng, V0.11.14)
No regressions observed from original kernel.
(the af-alg stressor can exercise almost all
kernel crypto modules shipped with the kernel;
so it checks more paths/crypto alg interfaces.)
[Regression Potential]
* The fix patch does a fundamental change in how
alg_sock reference counters work, plus another
change to the 'nokey' counting. This of course
*has* a risk of regression.
* Regressions theoretically could manifest as use
after free errors (in case of undercounting) in
the af_alg functions or silent memory leaks (in
case of overcounting), but also other behaviors
since reference counting is key to many things.
* FWIW, this patch has been written by the crypto
subsystem maintainer, who certainly knows a lot
of the normal and corner cases, thus giving the
patch more credit.
* Testing with the organic reproducer ran as long
as 5 days, without issues, so it does look good.
[Other Info]
* Not sending for Groovy (should get via Unstable).
* [1] Patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34c86f4c4a7be3b3e35aa48bd18299d4c756064d
[Stack Trace Examples]
Examples:
BUG: unable to handle kernel NULL pointer dereference at
...
RIP: 0010:apparmor_sk_clone_security+0x26/0x70
...
Call Trace:
security_sk_clone+0x33/0x50
af_alg_accept+0x81/0x1c0 [af_alg]
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
general protection fault: [#1] SMP PTI
...
RIP: 0010:__release_sock+0x54/0xe0
...
Call Trace:
release_sock+0x30/0xa0
af_alg_accept+0x122/0x1c0 [af_alg]
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884766/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1848210] Re: ghostscript: ensure update of cups-filter
It looks like this wasn't needed in practice; marking as Won't Fix. ** Changed in: ghostscript (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: ghostscript (Ubuntu Xenial) Importance: Medium => Undecided ** Changed in: ghostscript (Ubuntu Xenial) Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned) ** Changed in: ghostscript (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: ghostscript (Ubuntu Bionic) Importance: Medium => Undecided ** Changed in: ghostscript (Ubuntu Bionic) Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1848210 Title: ghostscript: ensure update of cups-filter Status in cups-filters package in Ubuntu: Invalid Status in ghostscript package in Ubuntu: Fix Released Status in cups-filters source package in Xenial: Invalid Status in ghostscript source package in Xenial: Won't Fix Status in cups-filters source package in Bionic: Invalid Status in ghostscript source package in Bionic: Won't Fix Bug description: [Impact] * After an update of ghostscript but not cups-filters users may hit errors printing PDF files (LP#1828401). * This is possible as Landscape does not consider the -security pocket (has both ghostscript/cups-filters) but rather USN notices and ghostscript had a notice [0]. The regression on cups-filters was identified later, and doesn't warrant a USN notice. * So, to ensure that ghostscript and cups-filters are both updated, add a versioned 'Breaks:' relationship to ghostscript for older cups-filters versions which are not yet fixed. Per Debian Policy [1]: """ Normally a Breaks entry will have an “earlier than” version clause; such a Breaks is introduced in the version ... [that] reveals a bug in earlier versions of the broken package ... This use of Breaks will inform higher-level package management tools that the broken package must be upgraded before the new one. """ * A versioned 'Depends:' relationship is not possible as ghostscript doesn't depend on cups-filters, thus it's possible to have ghostscript installed without cups-filters at all. * This doesn't fix the current situation with Landscape and USNs so this same problem might still occur again, but at least it is already in place on future updates. [Test Case] * Install cups-filters version without fix for LP#1828401: 1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial. * Update ghostscript to/later than fix for CVE-2019-3839-1/-2 9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial. * Notice it does _not_ update cups-filters to version with fix: 1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial. * $ wget -O ppd-with-pdf-support.ppd \ 'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0=Brother-HL-1020=1' * $ wget -O dummy.pdf \ https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf ... Filetype: PDF GPL Ghostscript 9.26: Unrecoverable error, exit code 1 Process is dying with "Unable to determine number of pages, page count: -1 ", exit stat 3 ... * Note it's broken. * Install ghostscript (test) packages with the relationships 'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or 'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial. * Note it _does_ update cups-filters to version with fix. * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf ... Filetype: PDF File contains 1 pages Starting renderer with command: <...> ... * Note it's now working. [Regression Potential] * Low. This only causes an update to cups-filters to a version that fixes an already identified/resolved problem (LP#1828401), which is available in bionic- & xenial-updates since May 2019. [Other Info] * This is only required in Xenial and Bionic. * Trusty doesn't have the ghostscript update that causes the problem. * Disco/Eoan have the cups-filters fix that it requires (1.22.5+). [Links] [0] https://usn.ubuntu.com/3970-1/ [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpa
[Group.of.nepali.translators] [Bug 1970482] Re: Xenial: kernel BUG/Oops/crash in fuse_readdir() due to CVE-2020-36322 backport
The fix has been released on Xenial ESM (kernel version 4.4.0-224.257).
$ git log --oneline -1 341e4f5e9e07
341e4f5e9e07 UBUNTU: SAUCE: fuse: fix bad !inode in fuse_direntplus_link()
$ git describe --contains 341e4f5e9e07
Ubuntu-4.4.0-224.257~6
** Changed in: linux (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1970482
Title:
Xenial: kernel BUG/Oops/crash in fuse_readdir() due to CVE-2020-36322
backport
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Xenial:
Fix Released
Bug description:
[Impact]
* Users might hit kernel BUG/Oops/crash with fuse filesystems
on Xenial kernel 4.4.0-222.255 and later (backport from 4.9),
including the derivative/optimized kernels (linux-aws below).
* Introduced by the backport from 4.9 for CVE-2020-36322 [1]
[1] https://ubuntu.com/security/CVE-2020-36322
* Offending commit 8deb786162e1 ("fuse: fix bad inode")
linux-xenial$ git log --oneline origin/master-prep -- fs/fuse/dir.c | head
-n1
8deb786162e1 fuse: fix bad inode
linux-xenial$ git describe --contains 8deb786162e1
Ubuntu-4.4.0-222.255~6
[Fix]
* Check for non-NULL inode pointer before fuse_is_bad(inode)
in fuse_direntplus_link().
* (This is the only modified function/patch hunk which seems
to have issues; all others dereference 'inode' w/out check
at some point, even before this patch).
[Test Case]
* Not available at the moment.
[Regression Potential]
* Probably none, as this changes the hunk/code behavior to
what it was before the offending patch/backport w/ issue
was applied (where fuse_is_bad() wasn't called at all if
inode is NULL), and makes sense with the patch applied;
also, this same form is used in another hunk, where NULL
was checked.
[Example Stacktrace]
kernel: BUG: unable to handle kernel NULL pointer dereference at
02c0
kernel: IP: [] fuse_readdir+0x376/0x700
kernel: PGD 1e3e02c067 PUD 1c8b2aa067 PMD 0
kernel: Oops: [#5] SMP
kernel: Modules linked in: <...>
kernel: CPU: 1 PID: 12133 Comm: php-fpm Tainted: G D
4.4.0-1138-aws #152-Ubuntu
kernel: Hardware name: Amazon EC2 m5a.8xlarge/, BIOS 1.0 10/16/2017
kernel: task: 881bcf164600 ti: 881bcffec000 task.ti:
881bcffec000
kernel: RIP: 0010:[] []
fuse_readdir+0x376/0x700
kernel: RSP: 0018:881bcffefe10 EFLAGS: 00010206
kernel: RAX: c9000524bd00 RBX: 01a0 RCX:
kernel: RDX: 0001 RSI: c9000524bd00 RDI:
881ed25bf3d8
kernel: RBP: 881bcffefea0 R08: R09:
0050
kernel: R10: 881b942a0c68 R11: 881ed25bf380 R12:
881b942a0bd0
kernel: R13: 880f8ced0d80 R14: 881f25cb1800 R15:
881ed25bf380
kernel: FS: 7f884d100740() GS:880fb8c4()
knlGS:
kernel: CS: 0010 DS: ES: CR0: 80050033
kernel: CR2: 02c0 CR3: 001cbc963000 CR4:
003406f0
kernel: Stack:
kernel: 881bcffefef0 00441d7f 880fb1c6a000
881b942a0bf8
kernel: 881f25cb1800 ea006e50a800
881b942a0ca0
kernel: ae046100 880fae046100 00361c41ec1e
881b942a0c68
kernel: Call Trace:
kernel: [] iterate_dir+0x98/0x120
kernel: [] ? __audit_syscall_entry+0xab/0xf0
kernel: [] SyS_getdents+0x99/0x110
kernel: [] ? iterate_dir+0x120/0x120
kernel: [] entry_SYSCALL_64_fastpath+0x22/0xd0
kernel: Code: 49 39 80 38 02 00 00 75 12 41 0f b7 00 41 33 44 24 64 f6
c4 f0 0f 84 72 02 00 00 4c 89 ff 4c 89 45 90 e8 ae 65 f0 ff 4c 8b 45 90 <49> 8b
80 c0 02 00 00 4c 89 ff a8 08 0f 85 67 02 00 00 e8 63 5c
kernel: RIP [] fuse_readdir+0x376/0x700
kernel: RSP
kernel: CR2: 02c0
kernel: ---[ end trace f89ac23b1e9bb24c ]---
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1970482/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1970482] [NEW] Xenial: kernel BUG/Oops/crash in fuse_readdir() due to CVE-2020-36322 backport
Public bug reported:
[Impact]
* Users might hit kernel BUG/Oops/crash with fuse filesystems
on Xenial kernel 4.4.0-222.255 and later (backport from 4.9),
including the derivative/optimized kernels (linux-aws below).
* Introduced by the backport from 4.9 for CVE-2020-36322 [1]
[1] https://ubuntu.com/security/CVE-2020-36322
* Offending commit 8deb786162e1 ("fuse: fix bad inode")
linux-xenial$ git log --oneline origin/master-prep -- fs/fuse/dir.c | head
-n1
8deb786162e1 fuse: fix bad inode
linux-xenial$ git describe --contains 8deb786162e1
Ubuntu-4.4.0-222.255~6
[Fix]
* Check for non-NULL inode pointer before fuse_is_bad(inode)
in fuse_direntplus_link().
* (This is the only modified function/patch hunk which seems
to have issues; all others dereference 'inode' w/out check
at some point, even before this patch).
[Test Case]
* Not available at the moment.
[Regression Potential]
* Probably none, as this changes the hunk/code behavior to
what it was before the offending patch/backport w/ issue
was applied (where fuse_is_bad() wasn't called at all if
inode is NULL), and makes sense with the patch applied;
also, this same form is used in another hunk, where NULL
was checked.
[Example Stacktrace]
kernel: BUG: unable to handle kernel NULL pointer dereference at
02c0
kernel: IP: [] fuse_readdir+0x376/0x700
kernel: PGD 1e3e02c067 PUD 1c8b2aa067 PMD 0
kernel: Oops: [#5] SMP
kernel: Modules linked in: <...>
kernel: CPU: 1 PID: 12133 Comm: php-fpm Tainted: G D
4.4.0-1138-aws #152-Ubuntu
kernel: Hardware name: Amazon EC2 m5a.8xlarge/, BIOS 1.0 10/16/2017
kernel: task: 881bcf164600 ti: 881bcffec000 task.ti:
881bcffec000
kernel: RIP: 0010:[] []
fuse_readdir+0x376/0x700
kernel: RSP: 0018:881bcffefe10 EFLAGS: 00010206
kernel: RAX: c9000524bd00 RBX: 01a0 RCX:
kernel: RDX: 0001 RSI: c9000524bd00 RDI:
881ed25bf3d8
kernel: RBP: 881bcffefea0 R08: R09:
0050
kernel: R10: 881b942a0c68 R11: 881ed25bf380 R12:
881b942a0bd0
kernel: R13: 880f8ced0d80 R14: 881f25cb1800 R15:
881ed25bf380
kernel: FS: 7f884d100740() GS:880fb8c4()
knlGS:
kernel: CS: 0010 DS: ES: CR0: 80050033
kernel: CR2: 02c0 CR3: 001cbc963000 CR4:
003406f0
kernel: Stack:
kernel: 881bcffefef0 00441d7f 880fb1c6a000
881b942a0bf8
kernel: 881f25cb1800 ea006e50a800
881b942a0ca0
kernel: ae046100 880fae046100 00361c41ec1e
881b942a0c68
kernel: Call Trace:
kernel: [] iterate_dir+0x98/0x120
kernel: [] ? __audit_syscall_entry+0xab/0xf0
kernel: [] SyS_getdents+0x99/0x110
kernel: [] ? iterate_dir+0x120/0x120
kernel: [] entry_SYSCALL_64_fastpath+0x22/0xd0
kernel: Code: 49 39 80 38 02 00 00 75 12 41 0f b7 00 41 33 44 24 64 f6
c4 f0 0f 84 72 02 00 00 4c 89 ff 4c 89 45 90 e8 ae 65 f0 ff 4c 8b 45 90 <49> 8b
80 c0 02 00 00 4c 89 ff a8 08 0f 85 67 02 00 00 e8 63 5c
kernel: RIP [] fuse_readdir+0x376/0x700
kernel: RSP
kernel: CR2: 02c0
kernel: ---[ end trace f89ac23b1e9bb24c ]---
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Invalid
** Affects: linux (Ubuntu Xenial)
Importance: High
Assignee: Mauricio Faria de Oliveira (mfo)
Status: In Progress
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => High
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Released
** Changed in: linux (Ubuntu)
Status: Fix Released => Invalid
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1970482
Title:
Xenial: kernel BUG/Oops/crash in fuse_readdir() due to CVE-2020-36322
backport
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Xenial:
In Progress
Bug description:
[Impact]
* Users might hit kernel BUG/Oops/crash with fuse filesystems
on Xenial kernel 4.4.0-222.255 and later (backport from 4.9),
including the derivative/optimized kernels (linux-aws below).
* Introduced by the backport from 4
[Group.of.nepali.translators] [Bug 1802021] Re: [Hyper-V] srcu: Lock srcu_data structure in srcu_gp_start()
** Changed in: linux (Ubuntu Xenial) Status: Confirmed => New ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Changed in: linux (Ubuntu Xenial) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1802021 Title: [Hyper-V] srcu: Lock srcu_data structure in srcu_gp_start() Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux source package in Xenial: Invalid Status in linux-azure source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Bug description: We had a customer seeing traces like the following: tack trace from kern.log: 2018-10-10T04:43:08.542464+00:00 hbp2ann-2 kernel: INFO: task kworker/u16:0:16678 blocked for more than 120 seconds. 2018-10-10T04:43:08.542503+00:00 hbp2ann-2 kernel: Not tainted 4.15.0-1023-azure #24~16.04.1-Ubuntu 2018-10-10T04:43:08.542513+00:00 hbp2ann-2 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 2018-10-10T04:43:08.547366+00:00 hbp2ann-2 kernel: kworker/u16:0 D 0 16678 2 0x8000 2018-10-10T04:43:08.547386+00:00 hbp2ann-2 kernel: Workqueue: events_unbound fsnotify_mark_destroy_workfn 2018-10-10T04:43:08.547395+00:00 hbp2ann-2 kernel: Call Trace: 2018-10-10T04:43:08.547413+00:00 hbp2ann-2 kernel: __schedule+0x3d6/0x8b0 2018-10-10T04:43:08.547422+00:00 hbp2ann-2 kernel: ? check_preempt_wakeup+0xfb/0x240 2018-10-10T04:43:08.547431+00:00 hbp2ann-2 kernel: ? sched_clock_local+0x17/0x90 2018-10-10T04:43:08.547440+00:00 hbp2ann-2 kernel: schedule+0x36/0x80 2018-10-10T04:43:08.547448+00:00 hbp2ann-2 kernel: schedule_timeout+0x1db/0x370 2018-10-10T04:43:08.547458+00:00 hbp2ann-2 kernel: ? __enqueue_entity+0x5c/0x60 2018-10-10T04:43:08.547467+00:00 hbp2ann-2 kernel: ? enqueue_entity+0x112/0x670 2018-10-10T04:43:08.547477+00:00 hbp2ann-2 kernel: wait_for_completion+0xb4/0x140 2018-10-10T04:43:08.547486+00:00 hbp2ann-2 kernel: ? wake_up_q+0x70/0x70 2018-10-10T04:43:08.547510+00:00 hbp2ann-2 kernel: __synchronize_srcu.part.13+0x85/0xb0 2018-10-10T04:43:08.547535+00:00 hbp2ann-2 kernel: ? trace_raw_output_rcu_utilization+0x50/0x50 2018-10-10T04:43:08.547560+00:00 hbp2ann-2 kernel: synchronize_srcu+0xd3/0xe0 2018-10-10T04:43:08.547594+00:00 hbp2ann-2 kernel: ? synchronize_srcu+0xd3/0xe0 2018-10-10T04:43:08.547604+00:00 hbp2ann-2 kernel: fsnotify_mark_destroy_workfn+0x7c/0xe0 2018-10-10T04:43:08.547612+00:00 hbp2ann-2 kernel: process_one_work+0x14d/0x410 2018-10-10T04:43:08.547620+00:00 hbp2ann-2 kernel: worker_thread+0x4b/0x460 2018-10-10T04:43:08.547628+00:00 hbp2ann-2 kernel: kthread+0x105/0x140 2018-10-10T04:43:08.547637+00:00 hbp2ann-2 kernel: ? process_one_work+0x410/0x410 2018-10-10T04:43:08.547645+00:00 hbp2ann-2 kernel: ? kthread_destroy_worker+0x50/0x50 2018-10-10T04:43:08.547654+00:00 hbp2ann-2 kernel: ? do_syscall_64+0x73/0x130 2018-10-10T04:43:08.547677+00:00 hbp2ann-2 kernel: ? SyS_exit_group+0x14/0x20 2018-10-10T04:43:08.547685+00:00 hbp2ann-2 kernel: ret_from_fork+0x35/0x40 Error Code: INFO: task kworker/u16:0:16678 blocked for more than 120 seconds. We are seeing more issue with fsnotify related callbacks. These are not a soft/hard lockup but seem to significantly degrade the responsiveness of systemd (and from there everything else). The following upstream commit may fix this issue, but it is in Paul's RCU tree and not in linux-next or upstream yet: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux- rcu.git/commit/?h=dev=1a05c0cd2fee234a10362cc8f66057557cbb291f srcu: Lock srcu_data structure in srcu_gp_start() The srcu_gp_start() function is called with the srcu_struct structure's ->lock held, but not with the srcu_data structure's ->lock. This is problematic because this function accesses and updates the srcu_data structure's ->srcu_cblist, which is protected by that lock. Failing to hold this lock can result in corruption of the SRCU callback lists, which in turn can result in arbitrarily bad results. This commit therefore makes srcu_gp_start() acquire the srcu_data structure's ->lock across the calls to rcu_segcblist_advance() and rcu_segcblist_accelerate(), thus preventing this corruption. Please investigate this issue and evaluate the proposed fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1802021/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post
[Group.of.nepali.translators] [Bug 1884766] Re: use-after-free in af_alg_accept() due to bh_lock_sock()
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 (Ubuntu Focal)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu Groovy)
Status: Won't Fix => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1884766
Title:
use-after-free in af_alg_accept() due to bh_lock_sock()
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Eoan:
Won't Fix
Status in linux source package in Focal:
Fix Released
Status in linux source package in Groovy:
Fix Released
Bug description:
[Impact]
* Users of the Linux kernel's crypto userspace API
reported BUG() / kernel NULL pointer dereference
errors after kernel upgrades.
* The stack trace signature is an accept() syscall
going through af_alg_accept() and hitting errors
usually in one of:
- apparmor_sk_clone_security()
- apparmor_sock_graft()
- release_sock()
[Fix]
* This is a regression introduced by upstream commit
37f96694cf73 ("crypto: af_alg - Use bh_lock_sock
in sk_destruct") which made its way through stable.
* The offending patch allows the critical regions
of af_alg_accept() and af_alg_release_parent() to
run concurrently; now with the "right" events on 2
CPUs it might drop the non-atomic reference counter
of the alg_sock then the sock, thus release a sock
that is still in use.
* The fix is upstream commit 34c86f4c4a7b ("crypto:
af_alg - fix use-after-free in af_alg_accept() due
to bh_lock_sock()") [1]. It changes alg_sock's ref
counter to atomic, which addresses the root cause.
[Test Case]
* There is a synthetic test case available, which
uses a kprobes kernel module to synchronize the
concurrent CPUs on the instructions responsible
for the problem; and a userspace part to run it.
* The organic reproducer is the Varnish Cache Plus
software with the Crypto vmod (which uses kernel
crypto userspace API) under long, very high load.
* The patch has been verified on both reproducers
with the 4.15 and 5.7 kernels.
* More tests performed with 'stress-ng --af-alg'
with 11 CPUs on Xenial/Bionic/Disco/Eoan/Focal
(all on same version of stress-ng, V0.11.14)
No regressions observed from original kernel.
(the af-alg stressor can exercise almost all
kernel crypto modules shipped with the kernel;
so it checks more paths/crypto alg interfaces.)
[Regression Potential]
* The fix patch does a fundamental change in how
alg_sock reference counters work, plus another
change to the 'nokey' counting. This of course
*has* a risk of regression.
* Regressions theoretically could manifest as use
after free errors (in case of undercounting) in
the af_alg functions or silent memory leaks (in
case of overcounting), but also other behaviors
since reference counting is key to many things.
* FWIW, this patch has been written by the crypto
subsystem maintainer, who certainly knows a lot
of the normal and corner cases, thus giving the
patch more credit.
* Testing with the organic reproducer ran as long
as 5 days, without issues, so it does look good.
[Other Info]
* Not sending for Groovy (should get via Unstable).
* [1] Patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34c86f4c4a7be3b3e35aa48bd18299d4c756064d
[Stack Trace Examples]
Examples:
BUG: unable to handle kernel NULL pointer dereference at
...
RIP: 0010:apparmor_sk_clone_security+0x26/0x70
...
Call Trace:
security_sk_clone+0x33/0x50
af_alg_accept+0x81/0x1c0 [af_alg]
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
general protection fault: [#1] SMP PTI
...
RIP: 0010:__release_sock+0x54/0xe0
...
Call Trace:
release_sock+0x30/0xa0
af_alg_accept+0x122/0x1c0 [af_alg]
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884766/+subscriptions
___
Mailing list:
[Group.of.nepali.translators] [Bug 1867916] Re: Regression in kernel 4.15.0-91 causes kernel panic with Bcache
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 notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1867916
Title:
Regression in kernel 4.15.0-91 causes kernel panic with Bcache
Status in Linux:
Confirmed
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Eoan:
Won't Fix
Status in linux source package in Focal:
Fix Released
Status in linux source package in Groovy:
Fix Released
Bug description:
[Impact]
* Users of bcache who manually specified a block size
greater than the page size when creating the device
with 'make-bcache' started to hit a kernel BUG/oops
after kernel upgrades. (This is not widely used.)
* The issue has been exposed with commit ad6bf88a6c19
("block: fix an integer overflow in logical block size")
because it increased the range of values accepted as
logical block size, which used to overflow to zero,
and thus receive a default of 512 via block layer.
* The issue existed previously, but with fewer values
exposed (e.g. 8k, 16k, 32k); the regression reports
happened with larger values (512k) for RAID stripes.
[Fix]
* The upstream commit dcacbc1242c7 ("bcache: check and
adjust logical block size for backing devices") checks
the block size and adjusts it if needed, to the value
of the underlying device's logical block size.
* It is merged as of v5.8-rcN, and sent to v5.7 stable.
[Test Case]
* Run make-bcache with block size greater than page size.
$ sudo make-bcache --bdev $DEV --block 8k
* Expected results: bcache device registered; no BUG/oops.
* Details steps on comment #43.
[Regression Potential]
* Restricted to users who specify a bcache block size
greater than page size.
* Regressions could theoretically manifest on bcache
device probe/register, if the underlying device's
logical block size for whatever triggers issues not
seen previously with the overflow/default 512 bytes.
[Other Info]
* Unstable has the patch on both master/master-5.7.
* Groovy should get it on rebase.
[Original Bug Description]
After upgrading from kernel 4.15.0-88 to 4.15.0-91 one of our systems does
not boot any longer. It always crashes during boot with a kernel panic.
I suspect that this crash might be related to Bcache because this is
the only one of our systems where we use Bcache and the kernel panic
appears right after Bcache initialization.
I already checked that this bug still exists in the 4.15.0-92.93
kernel from proposed.
Unfortunately, I cannot do a bisect because this is a critical
production system and we do not have any other system with a similar
configuration.
I attached a screenshot with the trace of the kernel panic.
The last message that appears before the kernel panic (or rather the
last one that I can see - there is a rather long pause between that
message and the panic and I cannot scroll up far enough to ensure that
there are no other messages in between) is:
bcache: register_bcache() error /dev/dm-0: device already registered
When booting with kernel 4.15.0-88 that does not have this problem,
the next message is
bcache: register_bcache() error /dev/dm-12: device already registered
(emitting change event)
After that the next message is:
Begin: Loading essential drivers ... done
This message also appears after the kernel panic, but the boot process
stalls and the system can only be recovered by doing a hardware reset.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-88-generic 4.15.0-88.88
ProcVersionSignature: Ubuntu 4.15.0-88.88-generic 4.15.18
Uname: Linux 4.15.0-88-generic x86_64
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Mar 17 21:08 seq
crw-rw 1 root audio 116, 33 Mar 17 21:08 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
ApportVersion: 2.20.9-0ubuntu7.11
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord':
'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
Date: Wed Mar 18 12:55:18 2020
HibernationDevice: RESUME=UUID=40512ea2-9fce-40f5-8362-5daf955cc26a
InstallationDate: Installed on 2013-07-02 (2450 days ago)
InstallationMedia: Ubuntu-Server 12.04.2 LTS "Precise Pangolin" - Release
amd64 (20130214)
MachineType: HP ProLiant DL160 G6
[Group.of.nepali.translators] [Bug 1873074] Re: kernel panic hit by kube-proxy iptables-save/restore caused by aufs
Marking as fix released for X/B/F on kernel packages versions: - Xenial: 4.4.0-186.216 - Bionic: 4.15.0-112.113 - Focal: 5.4.0-42.46 Covered in USNs: https://usn.ubuntu.com/4425-1 https://usn.ubuntu.com/4426-1 https://usn.ubuntu.com/4427-1 ** Changed in: linux (Ubuntu Bionic) Status: In Progress => Fix Released ** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Released ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Xenial) Status: New => Fix Released ** Changed in: linux (Ubuntu 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 a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1873074 Title: kernel panic hit by kube-proxy iptables-save/restore caused by aufs Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Eoan: Fix Committed Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Won't Fix Bug description: [Impact] * Systems with aufs mounts are vulnerable to a kernel BUG(), which can turn into a panic/crash if panic_on_oops is set. * It is exploitable by unprivileged local users; and also remote access operations (e.g., web server) potentially. * This issue has also manifested in Kubernetes deployments with a kernel panic in iptables-save or iptables-restore after a few weeks of uptime, without user interaction. * Usually all Kubernetes worker nodes hit the issue around the same time. [Fix] * The issue is fixed with 2 patches in aufs4-linux.git: - 515a586eeef3 aufs: do not call i_readcount_inc() - f10aea57d39d aufs: bugfix, IMA i_readcount * The first addresses the issue, and the second addresses a regression in the aufs feature to change RW branches to RO. * The kernel v5.3 aufs patches had an equivalent fix to the second patch, which is present in the Focal aufs patchset (and on ubuntu-unstable/master & /master-5.8 on 20200629) - 1d26f910c53f aufs: for v5.3-rc1, maintain i_readcount (in aufs5-linux.git) [Test Case] * Repeatedly open/close the same file in read-only mode in aufs (UINT_MAX times, to overflow a signed int back to 0.) * Alternatively, monitor the underlying filesystems's file inode.i_readcount over several open/close system calls. (should not monotonically increase; rather, return to 0.) [Regression Potential] * This changes the core path that aufs opens files, so there is a risk of regression; however, the fix changes aufs for how other filesystems work, so this generally is OK to do. In any case, most regressions would manifest in open() or close() (where the VFS handles/checks inode.i_readcount.) * The aufs maintainer has access to an internal test-suite used to validate aufs changes, used to identify the first regression (in the branch RW/RO mode change), and then to validate/publish the patches upstream; should be good now. * This has also been tested with 'stress-ng --class filesystem' and with 'xfstests -overlay' (patch to use aufs vs overlayfs) on Xenial/Bionic/Focal (-proposed vs. -proposed + patches). No regressions observed in stress-ng/xfstests log or dmesg. [Other Info] * Applied on Unstable (branches master and master-5.8) * Not required on Groovy (still 5.4; should sync from Unstable) * Required on LTS releases: Bionic and Focal and Xenial. * Required on other releases: Disco and Eoan (for custom kernels) [Original Bug Description] Problem Report: -- An user reported several nodes in their Kubernetes clusters hit a kernel panic at about the same time, and periodically (usually 35 days of uptime, and in same order nodes booted.) The kernel panics message/stack trace are consistent across nodes, in __fput() by iptables-save/restore from kube-proxy. Example: """ [3016161.866702] kernel BUG at .../include/linux/fs.h:2583! [3016161.866704] invalid opcode: [#1] SMP ... [3016161.866780] CPU: 40 PID: 33068 Comm: iptables-restor Tainted: P OE 4.4.0-133-generic #159-Ubuntu ... [3016161.866786] RIP: 0010:[...] [...] __fput+0x223/0x230 ... [3016161.866818] Call Trace: [3016161.866823] [...] fput+0xe/0x10 [3016161.866827] [...] task_work_run+0x86/0xb0 [3016161.866831] [...] exit_to_usermode_loop+0xc2/0xd0 [3016161.866833] [...] syscall_return
[Group.of.nepali.translators] [Bug 1867916] Re: Regression in kernel 4.15.0-91 causes kernel panic with Bcache
Test-case
=
echo 9 | sudo tee /proc/sys/kernel/printk # all messages on console
IMG="$HOME/disk.img"
rm -f $IMG
truncate --size 1G $IMG
DEV="$(sudo losetup --find --show $IMG)"
sudo modprobe bcache # just in case
sudo make-bcache --bdev $DEV --block 8k
** Also affects: linux (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Groovy)
Importance: 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 => Medium
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Bionic)
Status: New => In Progress
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Eoan)
Status: New => In Progress
** Changed in: linux (Ubuntu Eoan)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Eoan)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Groovy)
Status: In Progress => Won't Fix
** Changed in: linux (Ubuntu Groovy)
Importance: Medium => Undecided
** Changed in: linux (Ubuntu Groovy)
Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Committed
** Description changed:
- After upgrading from kernel 4.15.0-88 to 4.15.0-91 one of our systems
- does not boot any longer. It always crashes during boot with a kernel
- panic.
+ [Impact]
+
+ * Users of bcache who manually specified a block size
+greater than the page size when creating the device
+with 'make-bcache' started to hit a kernel BUG/oops
+after kernel upgrades. (This is not widely used.)
+
+ * The issue has been exposed with commit ad6bf88a6c19
+("block: fix an integer overflow in logical block size")
+because it increased the range of values accepted as
+logical block size, which used to overflow to zero,
+and thus receive a default of 512 via block layer.
+
+ * The issue existed previously, but with fewer values
+exposed (e.g. 8k, 16k, 32k); the regression reports
+happened with larger values (512k) for RAID stripes.
+
+ [Fix]
+
+ * The upstream commit dcacbc1242c7 ("bcache: check and
+adjust logical block size for backing devices") checks
+the block size and adjusts it if needed, to the value
+of the underlying device's logical block size.
+
+ * It is merged as of v5.8-rcN, and sent to v5.7 stable.
+
+ [Test Case]
+
+ * Run make-bcache with block size greater than page size.
+$ sudo make-bcache --bdev $DEV --block 8k
+
+ * Expected results: bcache device registered; no BUG/oops.
+ * Details steps on comment #.
+
+ [Regression Potential]
+
+ * Restricted to users who specify a bcache block size
+greater than page size.
+
+ * Regressions could theoretically manifest on bcache
+device probe/register, if the underlying device's
+logical block size for whatever triggers issues not
+seen previously with the overflow/default 512 bytes.
+
+ [Other Info]
+
+ * Unstable has the patch on both master/master-5.7.
+ * Groovy should get it on rebase.
+
+ [Original Bug Description]
+ After upgrading from kernel 4.15.0-88 to 4.15.0-91 one of our systems does
not boot any longer. It always crashes during boot with a kernel panic.
I suspect that this crash might be related to Bcache because this is the
only one of our systems where we use Bcache and the kernel panic appears
right after Bcache initialization.
I already checked that this bug still exists in the 4.15.0-92.93 kernel
from proposed.
Unfortunately, I cannot do a bisect because this is a critical
production system and we do not have any other system with a similar
configuration.
I attached a screenshot with the trace of the kernel panic.
The last message that appears before the kernel panic (or rather the
last one that I can see - there is a rather long pause between that
message and the panic and I cannot scroll up far enough to ensure that
there are no other messages in between) is:
bcache: register_bcache() erro
[Group.of.nepali.translators] [Bug 1840789] Re: bnx2x: fatal hardware error/reboot/tx timeout with LLDP enabled
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 Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1840789
Title:
bnx2x: fatal hardware error/reboot/tx timeout with LLDP enabled
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Disco:
Won't Fix
Status in linux source package in Eoan:
Fix Released
Bug description:
[Impact]
* The bnx2x driver may cause hardware faults (leading to
panic/reboot) and other behaviors as transmit timeouts,
after commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") is
introduced.
* This issue has been observed by an user shortly
after starting docker & kubelet, with adapters:
- Broadcom NetXtreme II BCM57800 [14e4:168a] from Dell [1028:1f5c]
- Broadcom NetXtreme II BCM57840 [14e4:16a1] from Dell [1028:1f79]
* If options to ignore hardware faults are used
(erst_disable=1 hest_disable=1 ghes.disable=1)
the system doesn't panic/reboot and continues
on to timeout on adapter stats, then transmit
timeouts, spewing some adapter firmware dumps,
but the network interface is non-functional.
* The issue only happened when LLDP is enabled
on the network switches, and crashdump shows
the bnx2x driver is stuck/waits for firmware
to complete the stop traffic command in LLDP
handling. Workaround used is to disable LLDP
in the network switches/ports.
* Analysis of the driver and firmware dumps
didn't help significantly towards finding
the root cause.
* Upstream/mainline recently just reverted the
patch, due to similar problem reports, while
looking for the root cause/proper fix.
[Test Case]
* No reproducible test case found outside
the user's systems/cluster, where it is
enough to start docker & kubelet & wait.
* The user verified test kernels for Xenial
and Bionic - the problem does not happen;
build-tested on Disco.
[Regression Potential]
* Users who significantly use/apply the non-default
traffic class (tc) / class of service (cos) might
possibly see performance changes (if any at all)
in such applications, however that's unclear now.
* This is a recent revert upstream (v5.3-rc'ish),
so there's chance things might change in this area.
* Nonetheless, the patch is authored by the driver
vendor, and made its way into stable kernels
(e.g., v5.2.8 which made Eoan/19.10 recently).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840789/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1884766] Re: use-after-free in af_alg_accept() due to bh_lock_sock()
** 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)
Status: New => In Progress
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Eoan)
Status: New => In Progress
** Changed in: linux (Ubuntu Eoan)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Eoan)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Groovy)
Status: Confirmed => Won't Fix
** Changed in: linux (Ubuntu Groovy)
Importance: Medium => Undecided
** Changed in: linux (Ubuntu Groovy)
Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
** Description changed:
[Impact]
* Users of the Linux kernel's crypto userspace API
reported BUG() / kernel NULL pointer dereference
errors after kernel upgrades.
* The stack trace signature is an accept() syscall
going through af_alg_accept() and hitting errors
usually in one of:
- apparmor_sk_clone_security()
- apparmor_sock_graft()
- release_sock()
[Fix]
* This is a regression introduced by upstream commit
37f96694cf73 ("crypto: af_alg - Use bh_lock_sock
in sk_destruct") which made its way through stable.
* The offending patch allows the critical regions
of af_alg_accept() and af_alg_release_parent() to
run concurrently; now with the "right" events on 2
CPUs it might drop the non-atomic reference counter
of the alg_sock then the sock, thus release a sock
that is still in use.
* The fix is upstream commit 34c86f4c4a7b ("crypto:
af_alg - fix use-after-free in af_alg_accept() due
to bh_lock_sock()") [1]. It changes alg_sock's ref
counter to atomic, which addresses the root cause.
[Test Case]
* There is a synthetic test case available, which
uses a kprobes kernel module to synchronize the
concurrent CPUs on the instructions responsible
for the problem; and a userspace part to run it.
* The organic reproducer is the Varnish Cache Plus
software with the Crypto vmod (which uses kernel
crypto userspace API) under long, very high load.
* The patch has been verified on both reproducers
with the 4.15 and 5.7 kernels.
- * More tests performed with 'stress-ng --af-alg'
-with 11 CPUs on Xenial/Bionic/Disco/Eoan/Focal
-(all on same version of stress-ng, V0.11.14)
+ * More tests performed with 'stress-ng --af-alg'
+ with 11 CPUs on Xenial/Bionic/Disco/Eoan/Focal
+ (all on same version of stress-ng, V0.11.14)
-No regressions observed from original kernel.
-(the af-alg stressor can exercise almost all
-kernel crypto modules shipped with the kernel;
-so it checks more paths/crypto alg interfaces.)
+ No regressions observed from original kernel.
+ (the af-alg stressor can exercise almost all
+ kernel crypto modules shipped with the kernel;
+ so it checks more paths/crypto alg interfaces.)
[Regression Potential]
* The fix patch does a fundamental change in how
alg_sock reference counters work, plus another
change to the 'nokey' counting. This of course
*has* a risk of regression.
* Regressions theoretically could manifest as use
after free errors (in case of undercounting) in
the af_alg functions or silent memory leaks (in
case of overcounting), but also other behaviors
since reference counting is key to many things.
* FWIW, this patch has been written by the crypto
subsystem maintainer, who certainly knows a lot
of the normal and corner cases, thus giving the
patch more credit.
* Testing with the organic reproducer ran as long
as 5 days, without issues, so it does look good.
[Other Info]
+
+ * Not sending for Groovy (should get via Unstable).
* [1] Patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34c86f4c4a7be3b3e35aa48bd18299d4c756064d
[Stack Trace Examples]
Examples:
BUG: unable to handle kernel NULL pointer dereference at
...
RIP: 0010:apparmor_sk_clone_security+0x26/0x70
...
Call Trace:
security_sk_clone+0x33/0x50
af_alg_accept+0x81/0x1c
[Group.of.nepali.translators] [Bug 1800566] Re: Make reset_devices parameter default for kdump
** Changed in: makedumpfile (Ubuntu Disco) Status: In Progress => Won't Fix ** Changed in: makedumpfile (Ubuntu Disco) Importance: High => Undecided ** Changed in: makedumpfile (Ubuntu Disco) Assignee: Guilherme G. Piccoli (gpiccoli) => (unassigned) ** Changed in: makedumpfile (Ubuntu Cosmic) Importance: High => Undecided ** Changed in: makedumpfile (Ubuntu Cosmic) Assignee: Guilherme G. Piccoli (gpiccoli) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1800566 Title: Make reset_devices parameter default for kdump Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Trusty: Won't Fix Status in makedumpfile source package in Xenial: In Progress Status in makedumpfile source package in Bionic: In Progress Status in makedumpfile source package in Cosmic: Won't Fix Status in makedumpfile source package in Disco: Won't Fix Status in makedumpfile source package in Eoan: In Progress Status in makedumpfile source package in Focal: Fix Released Bug description: [Impact] * Kdump does not configure by default the crash kernel to perform a device reset by default, by passing the "reset_devices" parameter. * Kernel has the "reset_devices" parameter that drivers can opt-in, and perform special activity in case this parameter is parsed from command-line. For example, in kdump kernels it hints the drivers that they are booting from a non-healthy condition and needs to issue some form of reset to the adapter, like clearing DMA mapping in their firmware for example. Users currently (kernel v5.5-rc2) are: aacraid, hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus. This should be enabled by default in the kdump config file to be added in the kdump kernel command-line for all versions. [Test Case] 1) Deploy a Bionic VM e.g. with uvt-kvm 2) Install the kdump-tools package 3) Run `kdump-config test`and check for the 'reset_devices' parameter: $ kdump-config test ... kexec command to be used: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz [Regression Potential] The regression potential is low, since it doesn't need any changes in makedumpfile code and we're only adding a parameter on the crash kernel command-line. The risks are related with bad behavior with the kernel when using "reset_devices", like if the driver has bugs in this path. It's considered safer to have the option (and this way prevent problems for booting a unhealthy kernel with potential stuck DMAs in the devices) than not having it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828596] Re: kdump fails when crash is triggered after DLPAR cpu add operation
Hi Guilherme, Thadeu, The re-spinned packages have been uploaded to Bionic and Eoan. Xenial didn't change, and is still in the upload queue (which I'll go check about on next week.) Disco didn't change, and has been removed from the upload queue. (After discussions with other people, it turns out uploading to Disco is not necessary given the short span until its EOL date.) cheers, Mauricio ** Changed in: makedumpfile (Ubuntu Disco) Status: In Progress => Won't Fix ** Changed in: makedumpfile (Ubuntu Disco) Assignee: Thadeu Lima de Souza Cascardo (cascardo) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828596 Title: kdump fails when crash is triggered after DLPAR cpu add operation Status in The Ubuntu-power-systems project: In Progress Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: In Progress Status in makedumpfile source package in Bionic: In Progress Status in makedumpfile source package in Cosmic: Won't Fix Status in makedumpfile source package in Disco: Won't Fix Status in makedumpfile source package in Eoan: In Progress Status in makedumpfile source package in Focal: Fix Released Bug description: [Impact] After a CPU add/hotplug operation on Power systems, kdump will fail after a crash. The kdump kernel needs to be reloaded after a CPU add/hotplug. [Test case] Do CPU add/hotplug, trigger a crash, and check for a successful kdump. [Regression potential] Multiple reloads caused by multiple sequential CPU adds may cause spurious log results, and systemd may fail to properly reload the kdump kernel. This has been handled by resetting the failure counter when doing such reloads. == Comment: #0 - Hari Krishna Bathini - 2019-05-10 05:55:40 == ---Problem Description--- kdump fails when crash is triggered after CPU add operation. Machine Type = na ---System Hang--- Crashed in early boot process of kdump kernel after crash Had to issue system reset from HMC to reclaim ---Steps to Reproduce--- 1. Configure kdump. 2. Add cpu from HMC. 3. Trigger crash. 4. Machine hangs after crash as below: --- [169250.213166] IPI complete [169250.234331] kexec: Starting switchover sequence. I'm in purgatory --- STRUCK HERE --- ---uname output--- na ---Debugger--- A debugger is not configured == Comment: #1 - Hari Krishna Bathini - 2019-05-10 05:56:46 == The problem is, kexec udev rule to restart kdump-tools service - when a core is added, is not being triggered. The old DT created by kexec (before the core is added) is being used by KDump Kernel. So, when system crashes on a thread from the added core(s), KDump kernel is failing to get the 'boot_cpuid' and eventually failing to boot.. == Comment: #2 - Hari Krishna Bathini - 2019-05-10 06:02:27 == The udev rule when CPU is added is not triggered because ppc64 does not eject add/remove event when a CPU is hot added/removed. It only ejects online/offline event to user space when CPU is hot added/removed. So, the below udev rules are never triggered when needed: SUBSYSTEM=="cpu", ACTION=="add", PROGRAM="/bin/systemctl try-restart kdump-tools.service" SUBSYSTEM=="cpu", ACTION=="remove", PROGRAM="/bin/systemctl try-restart kdump-tools.service" Also, with how CPU hot add & remove are handled in ppc64, a udev trigger to reload kdump after CPU is hot removed is NOT necessary. So, fix the CPU hot add case by updating the udev rule and drop the udev rule meant for CPU hot remove in the kdump udev rules file: SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try- restart kdump-tools.service" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1828596/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device
** Description changed: - description/debdiffs to be provided. + [Impact] - upstream commit: - https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424 + * Users with an XFS filesystem on top of bcache +(this is seen on some ceph, cloud deployments) +might fail to reference the bcache device by +UUID or other udev properties. + + * The journal of the regular XFS filesystem in +the bcache device is incorrectly detected as +an XFS external log; so two superblocks are +detected (bcache and xfs_external_log). + + * Thus blkid fails with ambivalent superblocks +detected then doesn't provide the usual udev +properties (UUID, etc.) + + * The fix improves the probe function for XFS +external log so it detects it's regular XFS +and bails out. + + [Test Case] + + * See test steps detailed in comment #. +- Create an XFS filesystem with the journal/log + in the beginning of the bcache device (< 256K). +- Stop the bcache device. +- Run '$ blkid -o udev -p $BCACHE_BACKING_DEVICE'. + +$ sudo make-bcache -B $BACKING_DEV +$ sudo mkfs.xfs -d agsize=16m -l agnum=0 -f $BCACHE_DEV +$ echo 1 | sudo tee /sys/block/$(basename $BCACHE_DEV)/bcache/stop +$ sudo blkid -o udev -p $BACKING_DEV + + [Regression Potential] + + * The patch only changes the detection function +for XFS external log to be more general about +the sector where the magic of regular XFS may +be found (which is shifted inside the bcache.) + + * It still checks at sector zero (the only one +checked previously), so this behavior didn't +change. + + * Possible regressions are actual XFS external +log devices that are not anymore detected as +such. (Although that would probably indicate +a different bug in libblkid.) + + [Other Info] + * upstream commit: + https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424 ** Bug watch added: Debian Bug tracker #948444 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948444 ** Also affects: util-linux (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948444 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1858802 Title: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device Status in util-linux package in Ubuntu: In Progress Status in util-linux source package in Xenial: In Progress Status in util-linux source package in Bionic: In Progress Status in util-linux source package in Disco: In Progress Status in util-linux source package in Eoan: In Progress Status in util-linux source package in Focal: In Progress Status in util-linux package in Debian: Unknown Bug description: [Impact] * Users with an XFS filesystem on top of bcache (this is seen on some ceph, cloud deployments) might fail to reference the bcache device by UUID or other udev properties. * The journal of the regular XFS filesystem in the bcache device is incorrectly detected as an XFS external log; so two superblocks are detected (bcache and xfs_external_log). * Thus blkid fails with ambivalent superblocks detected then doesn't provide the usual udev properties (UUID, etc.) * The fix improves the probe function for XFS external log so it detects it's regular XFS and bails out. [Test Case] * See test steps detailed in comment #. - Create an XFS filesystem with the journal/log in the beginning of the bcache device (< 256K). - Stop the bcache device. - Run '$ blkid -o udev -p $BCACHE_BACKING_DEVICE'. $ sudo make-bcache -B $BACKING_DEV $ sudo mkfs.xfs -d agsize=16m -l agnum=0 -f $BCACHE_DEV $ echo 1 | sudo tee /sys/block/$(basename $BCACHE_DEV)/bcache/stop $ sudo blkid -o udev -p $BACKING_DEV [Regression Potential] * The patch only changes the detection function for XFS external log to be more general about the sector where the magic of regular XFS may be found (which is shifted inside the bcache.) * It still checks at sector zero (the only one checked previously), so this behavior didn't change. * Possible regressions are actual XFS external log devices that are not anymore detected as such. (Although that would probably indicate a different bug in libblkid.) [Other Info] * upstream commit: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+subscriptions
[Group.of.nepali.translators] [Bug 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device
** Changed in: util-linux (Ubuntu Disco) Status: Invalid => In Progress ** Changed in: util-linux (Ubuntu Disco) Importance: Undecided => Medium ** Changed in: util-linux (Ubuntu Disco) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1858802 Title: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device Status in util-linux package in Ubuntu: In Progress Status in util-linux source package in Xenial: In Progress Status in util-linux source package in Bionic: In Progress Status in util-linux source package in Disco: In Progress Status in util-linux source package in Eoan: In Progress Status in util-linux source package in Focal: In Progress Bug description: description/debdiffs to be provided. upstream commit: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device
** Also affects: util-linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Focal) Importance: Undecided Assignee: Mauricio Faria de Oliveira (mfo) Status: In Progress ** Also affects: util-linux (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: util-linux (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: util-linux (Ubuntu Eoan) Status: New => In Progress ** Changed in: util-linux (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: util-linux (Ubuntu Eoan) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: util-linux (Ubuntu Disco) Status: New => Invalid ** Changed in: util-linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: util-linux (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: util-linux (Ubuntu Bionic) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: util-linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: util-linux (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: util-linux (Ubuntu Xenial) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Tags added: sts sts-sponsor-mfo -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1858802 Title: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device Status in util-linux package in Ubuntu: In Progress Status in util-linux source package in Xenial: In Progress Status in util-linux source package in Bionic: In Progress Status in util-linux source package in Disco: Invalid Status in util-linux source package in Eoan: In Progress Status in util-linux source package in Focal: In Progress Bug description: description/debdiffs to be provided. upstream commit: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1855481] Re: xenial: debian/tests/basic-smoke fails to debootstrap stable since the release of buster
** Description changed: [Impact] - * Autopkgtest reports failures/regressions for docker.io on Xenial -because debian/tests/basic-smoke fails to deboostrap Debian stable, -since the release of the new stable, Debian buster (July 6th 2019). + * Autopkgtest reports failures/regressions for docker.io on Xenial + because debian/tests/basic-smoke fails to deboostrap Debian stable, + since the release of the new stable, Debian buster (July 6th 2019). - * That caused changes to signatures and debootstrap procedures that -Xenial packages currently fail to handle. + * That caused changes to signatures and debootstrap procedures that + Xenial packages currently fail to handle. - * Such failures are false-positives of regressions with regards to -docker.io code *or* it's dependencies, which are thus flagged as -causing a regression to a reverse-dependency on autopkgtest.u.c. + * Such failures are false-positives of regressions with regards to + docker.io code *or* it's dependencies, which are thus flagged as + causing a regression to a reverse-dependency on autopkgtest.u.c. - * The solution is to revert to / stick with Debian stretch, which -has been the stable / status-quo before the buster release, and -is working correctly on both debian-archive-keyring/debootstrap -on Xenial. + * The solution is to revert to / stick with Debian stretch, which + has been the stable / status-quo before the buster release, and + is working correctly on both debian-archive-keyring/debootstrap + on Xenial. [Test Case] - * Run docker.io autopkgtests or just 'debian/tests/basic-smoke'. + * Run docker.io autopkgtests or just 'debian/tests/basic-smoke'. [Regression Potential] - * The 'debootstrap' command on 'debian/tests/basic-smoke' should -now continue to run past an early error, then hit other issues. + * The 'debootstrap' command on 'debian/tests/basic-smoke' should + now continue to run past an early error, then hit other issues. -At this time, it has been verified to finish sucessfully in the -autopkgtest.ubuntu.com infrastructure, tested against a PPA. + At this time, it has been verified to finish sucessfully in the + autopkgtest.ubuntu.com infrastructure, tested against a PPA. [Other Info] - * Currently only Xenial is being reported/fixed, although this -issue might hit Bionic and Focal in the future (with 2+years -support period, extending over Debian releases) depending on -whether further changes might be needed post-Buster release. + * Currently only Xenial is being reported/fixed, although this + issue might hit Bionic and Focal in the future (with 2+years + support period, extending over Debian releases) depending on + whether further changes might be needed post-Buster release. - * Debian's docker.io package only exists on Buster and later, -so are not susceptible to this problem right now. + * Debian's docker.io package only exists on Buster and later, + so are not susceptible to this problem right now. + + * Waiting a bit on feedback on Debian bug report / BTS 946313 [1]. + + [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946313 [Original Description] With the release of Debian Buster (July 2019) the 'stable' distribution symlink on Debian archives changed from 'stretch' to 'buster'. This caused issues to 'debootstrap stable ' on Xenial: (because of Xenial's older/pre-Buster debian-archive-keyring and debootstrap packages) 1. failure to check signature of the Release file (which can be worked-around with --no-check-gpg) 2. failure to unpack packages (which may need further changes) Thus just revert back to / stick with Debian Stretch as the suite to debootstrap for tests. This should prevent it to keep changing to newer releases, which depend on changes/fixes to other packages (not worth it just for the purpose of running 'true' in a docker container.) Original) + debootstrap --variant=minbase stable /tmp/tmp.CmnWmuSeHY http://httpredir.debian.org/debian I: Retrieving InRelease I: Checking Release signature E: Release signed by unknown key (key id DCC9EFBF77E11517) + doExit ... basic-smoke FAIL non-zero exit status 1 With --no-check-gpg) + debootstrap --no-check-gpg --variant=minbase stable /tmp/tmp.LbI1tZGEJb http://httpredir.debian.org/debian I: Retrieving InRelease I: Retrieving Packages ... I: Unpacking the base system... ... W: Failure while installing base packages. This will be re-attempted up to five times. W: See /tmp/tmp.LbI1tZGEJb/debootstrap/debootstrap.log for details + doExit ... basic-smoke FAIL non-zero exit status 1 With s/stable/stretch/) + debootstrap --variant=minbase stretch /tmp/tmp.Eyr81GS2o6 http://httpredir.debian.org/debian I: Retrieving InRelease I: Failed to retrieve InRelease I:
[Group.of.nepali.translators] [Bug 1855481] Re: xenial: debian/tests/basic-smoke fails to debootstrap stable since the release of buster
** Also affects: docker.io (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: docker.io (Ubuntu) Status: In Progress => Invalid ** Changed in: docker.io (Ubuntu Xenial) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1855481 Title: xenial: debian/tests/basic-smoke fails to debootstrap stable since the release of buster Status in docker.io package in Ubuntu: Invalid Status in docker.io source package in Xenial: In Progress Bug description: With the release of Debian Buster (July 2019) the 'stable' distribution symlink on Debian archives changed from 'stretch' to 'buster'. This caused issues to 'debootstrap stable ' on Xenial: (because of Xenial's older/pre-Buster debian-archive-keyring and debootstrap packages) 1. failure to check signature of the Release file (which can be worked-around with --no-check-gpg) 2. failure to unpack packages (which may need further changes) Thus just revert back to / stick with Debian Stretch as the suite to debootstrap for tests. This should prevent it to keep changing to newer releases, which depend on changes/fixes to other packages (not worth it just for the purpose of running 'true' in a docker container.) Original) + debootstrap --variant=minbase stable /tmp/tmp.CmnWmuSeHY http://httpredir.debian.org/debian I: Retrieving InRelease I: Checking Release signature E: Release signed by unknown key (key id DCC9EFBF77E11517) + doExit ... basic-smoke FAIL non-zero exit status 1 With --no-check-gpg) + debootstrap --no-check-gpg --variant=minbase stable /tmp/tmp.LbI1tZGEJb http://httpredir.debian.org/debian I: Retrieving InRelease I: Retrieving Packages ... I: Unpacking the base system... ... W: Failure while installing base packages. This will be re-attempted up to five times. W: See /tmp/tmp.LbI1tZGEJb/debootstrap/debootstrap.log for details + doExit ... basic-smoke FAIL non-zero exit status 1 With s/stable/stretch/) + debootstrap --variant=minbase stretch /tmp/tmp.Eyr81GS2o6 http://httpredir.debian.org/debian I: Retrieving InRelease I: Failed to retrieve InRelease I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010) I: Retrieving Packages ... I: Base system installed successfully. + tar -cC /tmp/tmp.5qp31fXQau . + docker import - debian ... + docker run --name test debian true ... ++ docker rm -f test ... ++ docker rmi debian ... + eval true ++ true ... basic-smoke PASS ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1855481/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1848210] Re: ghostscript: ensure update of cups-filter
** Patch added: "lp1848210_xenial.debdiff"
https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1848210/+attachment/5297503/+files/lp1848210_xenial.debdiff
** Changed in: cups-filters (Ubuntu)
Status: New => Invalid
** Changed in: cups-filters (Ubuntu Xenial)
Status: New => Invalid
** Changed in: cups-filters (Ubuntu Bionic)
Status: New => Invalid
** Changed in: cups-filters (Ubuntu Xenial)
Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)
** Changed in: cups-filters (Ubuntu Bionic)
Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)
** Changed in: cups-filters (Ubuntu Xenial)
Importance: Medium => Undecided
** Changed in: cups-filters (Ubuntu Bionic)
Importance: Medium => Undecided
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1848210
Title:
ghostscript: ensure update of cups-filter
Status in cups-filters package in Ubuntu:
Invalid
Status in ghostscript package in Ubuntu:
Fix Released
Status in cups-filters source package in Xenial:
Invalid
Status in ghostscript source package in Xenial:
In Progress
Status in cups-filters source package in Bionic:
Invalid
Status in ghostscript source package in Bionic:
In Progress
Bug description:
[Impact]
* After an update of ghostscript but not cups-filters
users may hit errors printing PDF files (LP#1828401).
* This is possible as Landscape does not consider the
-security pocket (has both ghostscript/cups-filters)
but rather USN notices and ghostscript had a notice [0].
The regression on cups-filters was identified later,
and doesn't warrant a USN notice.
* So, to ensure that ghostscript and cups-filters are
both updated, add a versioned 'Breaks:' relationship
to ghostscript for older cups-filters versions which
are not yet fixed.
Per Debian Policy [1]:
"""
Normally a Breaks entry will have an “earlier than” version clause;
such a Breaks is introduced in the version ... [that] reveals a bug
in earlier versions of the broken package ...
This use of Breaks will inform higher-level package management tools
that the broken package must be upgraded before the new one.
"""
* A versioned 'Depends:' relationship is not possible
as ghostscript doesn't depend on cups-filters, thus
it's possible to have ghostscript installed without
cups-filters at all.
* This doesn't fix the current situation with Landscape
and USNs so this same problem might still occur again,
but at least it is already in place on future updates.
[Test Case]
* Install cups-filters version without fix for LP#1828401:
1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial.
* Update ghostscript to/later than fix for CVE-2019-3839-1/-2
9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial.
* Notice it does _not_ update cups-filters to version with fix:
1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial.
* $ wget -O ppd-with-pdf-support.ppd \
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0=Brother-HL-1020=1'
* $ wget -O dummy.pdf \
https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf
* $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
...
Filetype: PDF
GPL Ghostscript 9.26: Unrecoverable error, exit code 1
Process is dying with "Unable to determine number of pages, page count: -1
", exit stat 3
...
* Note it's broken.
* Install ghostscript (test) packages with the relationships
'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.
* Note it _does_ update cups-filters to version with fix.
* $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
...
Filetype: PDF
File contains 1 pages
Starting renderer with command: <...>
...
* Note it's now working.
[Regression Potential]
* Low. This only causes an update to cups-filters to a version
that fixes an already identified/resolved problem (LP#1828401),
which is available in bionic- & xenial-updates since May 2019.
[Other Info]
* This is only required in Xenial and Bionic.
* Trusty doesn't have the ghostscript update that causes the problem.
* Disco/Eoan have the cups-filters fix that it requires (1.22.5+).
[Links]
[0] https://usn.ubuntu.com/3970-1/
[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subsc
[Group.of.nepali.translators] [Bug 1848210] [NEW] ghostscript: add Breaks: relationship to cups-filter
Public bug reported: Add a Breaks: relationship to cups-filter to prevent LP#1828401. Landscape allows packages updates to only USNs, so ghostscript can be updated to a version that breaks the older cups-filters. Patches to be provided shortly. ** Affects: ghostscript (Ubuntu) Importance: Undecided Status: Invalid ** Affects: ghostscript (Ubuntu Xenial) Importance: Medium Assignee: Mauricio Faria de Oliveira (mfo) Status: In Progress ** Affects: ghostscript (Ubuntu Bionic) Importance: Medium Assignee: Mauricio Faria de Oliveira (mfo) Status: In Progress ** Tags: sts ** Also affects: ghostscript (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: ghostscript (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: ghostscript (Ubuntu) Status: New => Invalid ** Changed in: ghostscript (Ubuntu Xenial) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: ghostscript (Ubuntu Bionic) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: ghostscript (Ubuntu Bionic) Status: New => In Progress ** Changed in: ghostscript (Ubuntu Xenial) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1848210 Title: ghostscript: add Breaks: relationship to cups-filter Status in ghostscript package in Ubuntu: Invalid Status in ghostscript source package in Xenial: In Progress Status in ghostscript source package in Bionic: In Progress Bug description: Add a Breaks: relationship to cups-filter to prevent LP#1828401. Landscape allows packages updates to only USNs, so ghostscript can be updated to a version that breaks the older cups-filters. Patches to be provided shortly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1848210/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1847512] Re: xenial: leftover scope units for Kubernetes transient mounts
*** This bug is a duplicate of bug 1846787 ***
https://bugs.launchpad.net/bugs/1846787
Marking this bug as a duplicate of bug 1846787 for the systemd fix.
** This bug has been marked a duplicate of bug 1846787
systemd-logind leaves leftover sessions and scope files
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1847512
Title:
xenial: leftover scope units for Kubernetes transient mounts
Status in systemd package in Ubuntu:
Invalid
Status in systemd source package in Xenial:
In Progress
Bug description:
[Impact]
When running Kubernetes on Xenial there's a leftover scope unit
for the transient mounts used by a pod (eg, secret volume mount)
together with its associate cgroup dirs, after the pod completes,
almost every time such pod is created:
$ systemctl list-units --type=scope | grep 'Kubernetes transient mount
for'
run-r560fcf858630417780c258c55fa21c8b.scope loaded active running
Kubernetes transient mount for
/var/snap/microk8s/common/var/lib/kubelet/pods/(...)/volumes/kubernetes.io~secret/(...)
/sys/fs/cgroup/devices/system.slice/run-r560fcf858630417780c258c55fa21c8b.scope
/sys/fs/cgroup/pids/system.slice/run-r560fcf858630417780c258c55fa21c8b.scope
/sys/fs/cgroup/blkio/system.slice/run-r560fcf858630417780c258c55fa21c8b.scope
/sys/fs/cgroup/memory/system.slice/run-r560fcf858630417780c258c55fa21c8b.scope
/sys/fs/cgroup/cpu,cpuacct/system.slice/run-r560fcf858630417780c258c55fa21c8b.scope
/sys/fs/cgroup/systemd/system.slice/run-r560fcf858630417780c258c55fa21c8b.scope
This problem becomes noticeable with Kubernetes CronJobs as time
goes by, as it repeatedly recreates pods to run the cronjob task.
Over time, the leftover units (and associated cgroup directories)
pile up to a significant amount, and start to cause problems for
other components, with effects on /sys/fs/cgroup/ scanning:
- Kubelet CPU/Memory Usage linearly increases using CronJob [1]
and systemd commands time out, breaking things like Ansible:
- failed: [...] (item=apt-daily-upgrade.service) => {[...]
"msg": "Unable to disable service apt-daily-upgrade.service:
Failed to execute operation: Connection timed out\n"}
The problem seems to be related to empty cgroup notification
on the legacy/classic hierarchy; it doesn't happen on hybrid
or unified hierarchies.
The fix is upstream systemd commit d8fdc62037b5 ("core: use
an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification").
That patch is already in progress/review in bug 1846787 [2],
and is present on Bionic and later, only Xenial is required.
[Test Case]
Create K8s pods with secret volume mounts (example below)
on Xenial/4.15 kernel, and check this after it completes:
$ sudo systemctl list-units --type=scope | grep 'Kubernetes
transient mount for'
(With the fix applied, there are zero units reported -- see
comment #1)
Steps:
-
Create a Xenial VM:
$ uvt-simplestreams-libvirt sync release=xenial arch=amd64
$ uvt-kvm create --memory 8192 --cpu 8 --disk 8 vm-xenial release=xenial
arch=amd64
Install the HWE/4.15 kernel and MicroK8s on it:
$ uvt-kvm wait vm-xenial
$ uvt-kvm ssh vm-xenial
$ sudo apt update
$ sudo apt install linux-image-4.15.0-65-generic
$ sudo reboot
$ uvt-kvm wait vm-xenial
$ uvt-kvm ssh vm-xenial
$ sudo snap install microk8s --channel=1.16/stable --classic
$ sudo snap alias microk8s.kubectl kubectl
$ sudo usermod -a -G microk8s $USER
$ exit
Check package versions:
$ uvt-kvm ssh vm-xenial
$ lsb_release -cs
xenial
$ uname -rv
4.15.0-65-generic #74~16.04.1-Ubuntu SMP Wed Sep 18 09:51:44 UTC 2019
$ snap list microk8s
Name Version Rev Tracking Publisher Notes
microk8s v1.16.0 920 1.16 canonical✓ classic
$ dpkg -s systemd | grep ^Version:
Version: 229-4ubuntu21.22
Create a pod with a secret/volume:
$ cat < pod-with-secret.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-with-secret
spec:
containers:
- name: container
image: debian:stretch
args: ["/bin/true"]
volumeMounts:
- name: secret
mountPath: /secret
volumes:
- name: secret
secret:
secretName: secret-for-pod
restartPolicy: Never
EOF
$ kubectl create secret generic secret-for-pod --from-
literal=key=value
Notice it leaves a transient scope unit running even after
complete:
$ systemctl list-units --type=scope | grep 'Kubernetes transient mount
for'
$
$ kubectl create -f pod-with-secret.yaml
$ kubectl
[Group.of.nepali.translators] [Bug 1842437] [NEW] Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev
Public bug reported: The nilfs filesystem has a backup superblock at the end of the device. If the magic number is coincidentally found at the right position and the filesystem is on a partition/not-wholedisk device, the only check left is for checksum verification, which is explicitly ignored in 'udev built-in blkid'. This causes blkid to detect one actually valid filesystem with a superblock at the beginning of the device (e.g., ext4), and then an invalid nilfs2 filesystem due to a coincidental magic number at the end of the device. And this causes blkid to break out of the safeprobe routine (which expects a single filesystem to be detected), and not print the UUIDs, thus not creating /dev/disk/by-uuid/ links which prevent mounting the partition by-uuid at boot time, causing emergency shell/boot failures. This upstream fix resolved the problem by introducing a check for the 'bytes' paramenters in the superblock, which is read from disk, and turns out to have an out-of-range value. - 'liblkid: Add length check in probe_nilfs2 before crc32' https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2 $ git describe --contains ac681a310c32319423297544833932f4d689a7a2 v2.29-rc1~172 Xenial, which is v2.27.1-based, is the only release that needs it. Bionic is v2.31.1, so all post-Xenial supported releases have it. ** Affects: util-linux (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: util-linux (Ubuntu Xenial) Importance: Medium Assignee: Mauricio Faria de Oliveira (mfo) Status: In Progress ** Also affects: util-linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: util-linux (Ubuntu) Status: New => Fix Released ** Changed in: util-linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: util-linux (Ubuntu Xenial) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: util-linux (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1842437 Title: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: In Progress Bug description: The nilfs filesystem has a backup superblock at the end of the device. If the magic number is coincidentally found at the right position and the filesystem is on a partition/not-wholedisk device, the only check left is for checksum verification, which is explicitly ignored in 'udev built-in blkid'. This causes blkid to detect one actually valid filesystem with a superblock at the beginning of the device (e.g., ext4), and then an invalid nilfs2 filesystem due to a coincidental magic number at the end of the device. And this causes blkid to break out of the safeprobe routine (which expects a single filesystem to be detected), and not print the UUIDs, thus not creating /dev/disk/by-uuid/ links which prevent mounting the partition by-uuid at boot time, causing emergency shell/boot failures. This upstream fix resolved the problem by introducing a check for the 'bytes' paramenters in the superblock, which is read from disk, and turns out to have an out-of-range value. - 'liblkid: Add length check in probe_nilfs2 before crc32' https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2 $ git describe --contains ac681a310c32319423297544833932f4d689a7a2 v2.29-rc1~172 Xenial, which is v2.27.1-based, is the only release that needs it. Bionic is v2.31.1, so all post-Xenial supported releases have it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840789] Re: bnx2x: fatal hardware error/reboot/tx timeout with LLDP enabled
This fix is already present in Eoan and Unstable:
~/git/ubuntu-eoan$ git log --oneline origin/master-next --
drivers/net/ethernet/broadcom/bnx2x/ | head | grep cos
1c41d7b7cf60 bnx2x: Disable multi-cos feature.
~/git/ubuntu-eoan$ git describe --contains 1c41d7b7cf60
Ubuntu-5.2.0-12.13~51
~/git/ubuntu-unstable$ git log --oneline origin/master --
drivers/net/ethernet/broadcom/bnx2x/ | head | grep cos
d1f0b5dce8fd bnx2x: Disable multi-cos feature.
~/git/ubuntu-unstable$ git describe --contains d1f0b5dce8fd
Ubuntu-5.3.0-4.5~313^2~91
** Description changed:
- Description/patches to be provided this week.
+ [Impact]
+
+ * The bnx2x driver may cause hardware faults (leading to
+panic/reboot) and other behaviors as transmit timeouts,
+after commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") is
+introduced.
+
+ * This issue has been observed by an user shortly
+after starting docker & kubelet, with adapters:
+- Broadcom NetXtreme II BCM57800 [14e4:168a] from Dell [1028:1f5c]
+- Broadcom NetXtreme II BCM57840 [14e4:16a1] from Dell [1028:1f79]
+
+ * If options to ignore hardware faults are used
+(erst_disable=1 hest_disable=1 ghes.disable=1)
+the system doesn't panic/reboot and continues
+on to timeout on adapter stats, then transmit
+timeouts, spewing some adapter firmware dumps,
+but the network interface is non-functional.
+
+ * The issue only happened when LLDP is enabled
+on the network switches, and crashdump shows
+the bnx2x driver is stuck/waits for firmware
+to complete the stop traffic command in LLDP
+handling. Workaround used is to disable LLDP
+in the network switches/ports.
+
+ * Analysis of the driver and firmware dumps
+didn't help significantly towards finding
+the root cause.
+
+ * Upstream/mainline recently just reverted the
+patch, due to similar problem reports, while
+looking for the root cause/proper fix.
+
+ [Test Case]
+
+ * No reproducible test case found outside
+the user's systems/cluster, where it is
+enough to start docker & kubelet & wait.
+
+ * The user verified test kernels for Xenial
+and Bionic - the problem does not happen.
+
+ [Regression Potential]
+
+ * Users who significantly use/apply the non-default
+traffic class (tc) / class of service (cos) might
+possibly see performance changes (if any at all)
+in such applications, however that's unclear now.
+
+ * This is a recent revert upstream (v5.3-rc'ish),
+so there's chance things might change in this area.
+
+ * Nonetheless, the patch is authored by the driver
+vendor, and made its way into stable kernels
+(e.g., v5.2.8 which made Eoan/19.10 recently).
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Eoan)
Importance: Undecided
Assignee: Mauricio Faria de Oliveira (mfo)
Status: In Progress
** Also affects: linux (Ubuntu Disco)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Eoan)
Status: In Progress => Fix Released
** Changed in: linux (Ubuntu Disco)
Status: New => In Progress
** Changed in: linux (Ubuntu Bionic)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Disco)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Description changed:
[Impact]
- * The bnx2x driver may cause hardware faults (leading to
-panic/reboot) and other behaviors as transmit timeouts,
-after commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") is
-introduced.
+ * The bnx2x driver may cause hardware faults (leading to
+ panic/reboot) and other behaviors as transmit timeouts,
+ after commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") is
+ introduced.
- * This issue has been observed by an user shortly
-after starting docker & kubelet, with adapters:
-- Broadcom NetXtreme II BCM57800 [14e4:168a] from Dell [1028:1f5c]
-- Broadcom NetXtreme II BCM57840 [14e4:16a1] from Dell [1028:1f79]
+ * This issue has been observed by an user shortly
+ after starting docker & kubelet, with adapters:
+ - Broadcom NetXtreme II BCM57800 [14e4:168a] from Dell [1028:1f5c]
+ - Broadcom NetXtreme II BCM57840 [14e4:16a1] from Dell [1028:1f79]
- * If options to ignore hardware faults are used
-(erst_disable=1 hest_disable=1 ghes.disable=1)
-the system doesn't panic/reboot and continues
-on to timeout on adapter stats, then transmit
-timeouts, spewing some adapter firmware dumps,
-but the network
[Group.of.nepali.translators] [Bug 1839521] Re: Xenial: ZFS deadlock in shrinker path with xattrs
** Description changed: [Impact] - * Xenial's ZFS can deadlock in the memory shrinker path -after removing files with extended attributes (xattr). + * Xenial's ZFS can deadlock in the memory shrinker path + after removing files with extended attributes (xattr). - * Extended attributes are enabled by default, but are -_not_ used by default, which reduces the likelyhood. + * Extended attributes are enabled by default, but are + _not_ used by default, which reduces the likelyhood. - * It's very difficult/rare to reproduce this problem, -due to file/xattr/remove/shrinker/lru order/timing -circumstances required. (weeks for a reporter user) -but a synthetic test-case has been found for tests. + * It's very difficult/rare to reproduce this problem, + due to file/xattr/remove/shrinker/lru order/timing + circumstances required. (weeks for a reporter user) + but a synthetic test-case has been found for tests. [Test Case] - * A synthetic reproducer is available for this LP, -with a few steps to touch/setfattr/rm/drop_caches -plus a kernel module to massage the disposal list. + * A synthetic reproducer is available for this LP, + with a few steps to touch/setfattr/rm/drop_caches + plus a kernel module to massage the disposal list. +(comment #8) - * In the original ZFS module: -the xattr dir inode is not purged immediately on -file removal, but possibly purged _two_ shrinker -invocations later. This allows for other thread -started before file remove to call zfs_zget() on -the xattr child inode and iput() it, so it makes -to the same disposal list as the xattr dir inode. + * In the original ZFS module: + the xattr dir inode is not purged immediately on + file removal, but possibly purged _two_ shrinker + invocations later. This allows for other thread + started before file remove to call zfs_zget() on + the xattr child inode and iput() it, so it makes + to the same disposal list as the xattr dir inode. +(comment #3) - * In the modified ZFS module: -the xattr dir inode is purged immediately on file -removal not possibly later on shrinker invocation, -so the problem window above doesn't exist anymore. + * In the modified ZFS module: + the xattr dir inode is purged immediately on file + removal not possibly later on shrinker invocation, + so the problem window above doesn't exist anymore. +(comment #12) [Regression Potential] - * Low. The patches are confined to extended attributes -in ZFS, specifically node removal/purge, and another -change how an xattr child inode tracks its xattr dir -(parent) inode, so that it can be purged immediately -on removal. + * Low. The patches are confined to extended attributes + in ZFS, specifically node removal/purge, and another + change how an xattr child inode tracks its xattr dir + (parent) inode, so that it can be purged immediately + on removal. - * The ZFS test-suite has been run on original/modified -zfs-dkms package/kernel modules, with no regressions. + * The ZFS test-suite has been run on original/modified + zfs-dkms package/kernel modules, with no regressions. +(comment #11) ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Eoan) Status: New => Invalid ** Changed in: linux (Ubuntu Disco) Status: New => Invalid ** Changed in: linux (Ubuntu Bionic) Status: New => Invalid ** Changed in: linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1839521 Title: Xenial: ZFS deadlock in shrinker path with xattrs Status in linux package in Ubuntu: Invalid Status in zfs-linux package in Ubuntu: Invalid Status in linux source package in Xenial: In Progress Status in zfs-linux source package in Xenial: In Progress Status in linux source package in Bionic: Invalid Status in zfs-linux source package in Bionic: Invalid Status in linux source package in Disco: Invalid Status in zfs-linux source package in Disco: Invalid Status in linux source package in Eoan: Invalid Status in zfs-linux source package in Eoan: Invalid Bug description: [Impact] * Xenial's ZFS can deadlock in the memory shrinker path after removing files with extended attributes (xattr). * Extended attributes are enabled by default, but are _not_ used by default, which reduces the likelyhood. * It's very difficult/rare to reproduce this problem, due to file/xattr/remove/shrinker/lru order/timing circumstances required. (weeks for a reporter user) but a synt
[Group.of.nepali.translators] [Bug 1839521] [NEW] Xenial: ZFS deadlock in shrinker path with xattrs
Public bug reported: [Impact] * Xenial's ZFS can deadlock in the memory shrinker path after removing files with extended attributes (xattr). * Extended attributes are enabled by default, but are _not_ used by default, which reduces the likelyhood. * It's very difficult/rare to reproduce this problem, due to file/xattr/remove/shrinker/lru order/timing circumstances required. (weeks for a reporter user) but a synthetic test-case has been found for tests. [Test Case] * A synthetic reproducer is available for this LP, with a few steps to touch/setfattr/rm/drop_caches plus a kernel module to massage the disposal list. * In the original ZFS module: the xattr dir inode is not purged immediately on file removal, but possibly purged _two_ shrinker invocations later. This allows for other thread started before file remove to call zfs_zget() on the xattr child inode and iput() it, so it makes to the same disposal list as the xattr dir inode. * In the modified ZFS module: the xattr dir inode is purged immediately on file removal not possibly later on shrinker invocation, so the problem window above doesn't exist anymore. [Regression Potential] * Low. The patches are confined to extended attributes in ZFS, specifically node removal/purge, and another change how an xattr child inode tracks its xattr dir (parent) inode, so that it can be purged immediately on removal. * The ZFS test-suite has been run on original/modified zfs-dkms package/kernel modules, with no regressions. ** Affects: zfs-linux (Ubuntu) Importance: Undecided Status: Invalid ** Affects: zfs-linux (Ubuntu Xenial) Importance: Undecided Assignee: Mauricio Faria de Oliveira (mfo) Status: In Progress ** Affects: zfs-linux (Ubuntu Bionic) Importance: Undecided Status: Invalid ** Affects: zfs-linux (Ubuntu Disco) Importance: Undecided Status: Invalid ** Affects: zfs-linux (Ubuntu Eoan) Importance: Undecided Status: Invalid ** Also affects: zfs-linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: zfs-linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: zfs-linux (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: zfs-linux (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: zfs-linux (Ubuntu Eoan) Status: New => Invalid ** Changed in: zfs-linux (Ubuntu Disco) Status: New => Invalid ** Changed in: zfs-linux (Ubuntu Bionic) Status: New => Invalid ** Changed in: zfs-linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: zfs-linux (Ubuntu Xenial) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1839521 Title: Xenial: ZFS deadlock in shrinker path with xattrs Status in zfs-linux package in Ubuntu: Invalid Status in zfs-linux source package in Xenial: In Progress Status in zfs-linux source package in Bionic: Invalid Status in zfs-linux source package in Disco: Invalid Status in zfs-linux source package in Eoan: Invalid Bug description: [Impact] * Xenial's ZFS can deadlock in the memory shrinker path after removing files with extended attributes (xattr). * Extended attributes are enabled by default, but are _not_ used by default, which reduces the likelyhood. * It's very difficult/rare to reproduce this problem, due to file/xattr/remove/shrinker/lru order/timing circumstances required. (weeks for a reporter user) but a synthetic test-case has been found for tests. [Test Case] * A synthetic reproducer is available for this LP, with a few steps to touch/setfattr/rm/drop_caches plus a kernel module to massage the disposal list. * In the original ZFS module: the xattr dir inode is not purged immediately on file removal, but possibly purged _two_ shrinker invocations later. This allows for other thread started before file remove to call zfs_zget() on the xattr child inode and iput() it, so it makes to the same disposal list as the xattr dir inode. * In the modified ZFS module: the xattr dir inode is purged immediately on file removal not possibly later on shrinker invocation, so the problem window above doesn't exist anymore. [Regression Potential] * Low. The patches are confined to extended attributes in ZFS, specifically node removal/purge, and another change how an xattr child inode tracks its xattr dir (parent) inode, so that it can be purged immediately on removal. * The ZFS test-suite has been run on original/modified zfs-dkms package/kernel modules, with no regressi
[Group.of.nepali.translators] [Bug 1803385] Re: fetch-url does not use --no-check-certificate on HTTP to HTTPS redirects
Closing this bug as Invalid. The real solution is fix-released in LP#1807023. This bug was a workaround for not having ca-certificates in d-i and use an HTTP mirror that redirected to HTTPS (the resulting certificate validation error couldn't be ignored due to HTTP protocol not using the wget option.) But this is no longer required with the ca-certificates shipped in debian-installer. Sorry, I had lost track of this bug. Mauricio ** Changed in: debian-installer-utils (Ubuntu) Status: In Progress => Invalid ** Changed in: debian-installer-utils (Ubuntu Trusty) Status: In Progress => Invalid ** Changed in: debian-installer-utils (Ubuntu Xenial) Status: In Progress => Invalid ** Changed in: debian-installer-utils (Ubuntu Bionic) Status: In Progress => Invalid ** Changed in: debian-installer-utils (Ubuntu Cosmic) Status: In Progress => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1803385 Title: fetch-url does not use --no-check-certificate on HTTP to HTTPS redirects Status in debian-installer-utils package in Ubuntu: Invalid Status in debian-installer-utils source package in Trusty: Invalid Status in debian-installer-utils source package in Xenial: Invalid Status in debian-installer-utils source package in Bionic: Invalid Status in debian-installer-utils source package in Cosmic: Invalid Status in debian-installer-utils package in Debian: New Bug description: [Impact] * fetch-url fails to download files from URL with HTTP to HTTPS redirect if server has invalid/cannot be verified certificate. * Install fails in case a preseed/other files use an HTTP URL that redirects to an HTTPS URL with an invalid certificate. * Servers/URLs that started using HTTP to HTTPS redirect and have their URLs already spread over scripts/infrastructure start to cause install/deployment failures. * This fix checks for debian-installer/allow_unauthenticated_ssl in the HTTP protocol as well (to enable --no-check-certificate), which is OK as that option must be explicitly enabled by users, indicating awareness of the SSL/HTTPS context and certificates that may not be verified. [Test Case] * Setup web-server with HTTP to HTTPS redirect and an invalid/ self-signed certificate, and put a file (eg, preseed) on it. * Boot with preseed option 'url=http:///preseed' and the install will fail in the 'network-preseed' stage, with syslog errors about invalid/cannot be verified certificates, suggesting the 'wget --no-check-certificate' option. * Other files downloaded by the installer can hit same error, if using HTTP URLs from that server. * In the installer shell, run: ~ # fetch-url http:/// [Regression Potential] * Low risk of regression, this only expands the check from HTTPS-only to HTTPS or HTTP, to *then* check for d-i/allow_unauthenticated_ssl. * The theoretical case is that a HTTP URL with no redirect to HTTPS may use --no-check-certificate, thus without actually needing it, (it should not cause problems at all, the option should be ignored) but anyway, since the user acknowledged that sort of behavior with the d-i/allow_unauthenticated_ssl, that should not be a concern. [Other Info] * Debian Bug #913740. [Problem Description] In fetch-url the --no-check-certificate option is conditioned to HTTPS. In case of HTTP to HTTPS redirect, that option is not enabled, and may cause fetch-url to fail if the certificate cannot be verified. Since that option/functionality must be explicitly requested with the debian-installer/allow_unauthenticated_ssl preseed option (i.e., user is aware of SSL/HTTPS context and agrees w/ non-verified certificates) we can just check for this in the HTTP protocol too, and assume HTTPS may potentially be used, as the user specified this option. An alternative/obvious solution in the _user_ side is to specify HTTPS URLs upfront, but there are cases when an user does not know for sure whether the server uses/supports that, or the server might change its behavior and start HTTP to HTTPS redirect after URLs have spread over (e.g., scripts and infrastructure) - thus a fix in the installer side is a simpler and more complete approach. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer-utils/+bug/1803385/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1821259] Re: Hard lockup in 2 CPUs due to deadlock in cpu_stoppers
[X][PATCH 0/4] LP#1821259 Fix for deadlock in cpu_stopper https://lists.ubuntu.com/archives/kernel-team/2019-March/099427.html [B][PATCH 0/2] Fix for LP#1821259 (pending patches for) Fix for deadlock in cpu_stopper https://lists.ubuntu.com/archives/kernel-team/2019-March/099432.html ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu) ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Xenial) Status: New => Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1821259 Title: Hard lockup in 2 CPUs due to deadlock in cpu_stoppers Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Bug description: [Impact] * This problem hard locks up 2 CPUs in a deadlock, and this soft locks up other CPUs as an effect; the system becomes unusable. * This is relatively rare / difficult to hit because it's a corner case in scheduling/load balancing that needs timing with CPU stopper code. And it needs SMP plus _NUMA_ system. (but it can be hit with synthetic test case attached in LP.) * Since SMP plus NUMA usually equals _servers_ it looks like a good idea to prevent this bug / hard lockups / rebooting. * The fix resolves the potential deadlock by removing one of the calls required to deadlock from under the locked code. [Test Case] * There's a synthetic test case to reproduce this problem (although without the stack traces - just a system hang) attached to this LP bug. * It uses kprobes/mdelay/cpu stopper calls to force the code to execute and force the timing/locking condition to occur. * $ sudo insmod kmod-stopper.ko Some dmesg logging occurs, and systems either hangs or not. See examples in comments. [Regression Potential] * These are patches to the cpu stop_machine.c code, and they change a bit how it works; however, there are no upstream fixes for these patches anymore and they are still the top of the 'git log --oneline -- kernel/stop_machine.c' output. * These patches have been verified with the synthetic test case and 'stress-ng --class scheduler --sequential 0' (no regressions) on guest with 2 CPUs and one physical system with 24 CPUs. [Other Info] * The patches are required on Xenial and later. * There are 4 patches for Xenial, and 2 patches pending for Bionic. * All patches are applied from Cosmic onwards. [Original Description] These 2 hard lockups happened all of a sudden in the logs, and many soft lockups occur after them as a fallout. Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.477086] NMI watchdog: Watchdog detected hard LOCKUP on cpu 10 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.483800] Modules linked in: <...> Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484066] CPU: 10 PID: 58 Comm: migration/10 Not tainted 4.4.0-116-generic #140~14.04.1-Ubuntu Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484068] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 02/17/2017 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484070] task: 883ff2a76200 ti: 883ff211 task.ti: 883ff211 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484071] RIP: 0010:[] [] native_queued_spin_lock_slowpath+0x160/0x170 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484079] RSP: :883ff2113c58 EFLAGS: 0002 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484080] RAX: 0101 RBX: 0086 RCX: 0001 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484081] RDX: 0101 RSI: 0001 RDI: 881fff991ba8 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484083] RBP: 883ff2113c58 R08: 0101 R09: 883ff082e200 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484084] R10: 2e04 R11: 2e04 R12: 881fff997c60 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484085] R13: 881fff991ba8 R14: R15: 881fff997300 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484087] FS: () GS:883fff00() knlGS: Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484088] CS: 0010 DS: ES: CR0: 80050033 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484090] CR2: 7f7caaa23020 CR3: 001f4674 CR4: 00160670 Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484091] Stack: Nov 23 15:48:33 SYSTEM_NAME kernel: [4603802.484092] 883ff2113c68 811870eb 883ff2113c80
[Group.of.nepali.translators] [Bug 1817628] [NEW] Regular D-state processes impacting LXD containers
Public bug reported: [Impact] * Systems running under memory pressure may hit stalls in the order of seconds to minutes in systemd-logind and lxd mount operations (e.g., ZFS backend), which get stuck in D state. * The processes stuck in D state have a common stack trace, (cat /proc/PID/stack) all blocked in register_shrinker(). * The fix checks in shrink_slab() (shrinkers are called under memory pressure) for contention/usage of the semaphore used by register_shrinker() and returns early in that case. This allows the register_shrinker() callers to unblock, and not stall until the shrink operation releases that lock. [Test Case] * In a system under memory pressure, specifically having the memory shrinkers being called often and taking time to run, perform mount operations (or other operations that acquire the shrinker_rwsem semaphore). * The user who reported the problem has verified the fix in systems that exhibted the problem often (sometimes daily), and tells it resolves the problem. [Regression Potential] * Low. The fix just returns early from slab memory shrinker if there's usage/contention for 'shrinker_rwsem'. * In some scenarios, this may cause the slab memory shrinker to require more invocations to actually finish and potentially release memory, but this seems minor since other shrinkers can release memory as well, and compared to the fact that this fix allows other applications to make progress / continue to run, which would otherwise be stalled. [Other Info] * This patch is already applied in Cosmic and later (v4.16+). It is needed only in Xenial and Bionic at this time. ** Affects: linux (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Xenial) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Bionic) Importance: Undecided Status: Confirmed ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Invalid ** Changed in: linux (Ubuntu Xenial) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1817628 Title: Regular D-state processes impacting LXD containers Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Bug description: [Impact] * Systems running under memory pressure may hit stalls in the order of seconds to minutes in systemd-logind and lxd mount operations (e.g., ZFS backend), which get stuck in D state. * The processes stuck in D state have a common stack trace, (cat /proc/PID/stack) all blocked in register_shrinker(). * The fix checks in shrink_slab() (shrinkers are called under memory pressure) for contention/usage of the semaphore used by register_shrinker() and returns early in that case. This allows the register_shrinker() callers to unblock, and not stall until the shrink operation releases that lock. [Test Case] * In a system under memory pressure, specifically having the memory shrinkers being called often and taking time to run, perform mount operations (or other operations that acquire the shrinker_rwsem semaphore). * The user who reported the problem has verified the fix in systems that exhibted the problem often (sometimes daily), and tells it resolves the problem. [Regression Potential] * Low. The fix just returns early from slab memory shrinker if there's usage/contention for 'shrinker_rwsem'. * In some scenarios, this may cause the slab memory shrinker to require more invocations to actually finish and potentially release memory, but this seems minor since other shrinkers can release memory as well, and compared to the fact that this fix allows other applications to make progress / continue to run, which would otherwise be stalled. [Other Info] * This patch is already applied in Cosmic and later (v4.16+). It is needed only in Xenial and Bionic at this time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817628/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1783152] Re: Enable basic support for Solarflare 8000 series NIC
** Also affects: debian-installer (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: linux-lts-xenial (Ubuntu Precise) Importance: Undecided Status: New ** No longer affects: linux-lts-xenial (Ubuntu Precise) ** No longer affects: linux (Ubuntu Precise) ** No longer affects: debian-installer (Ubuntu Precise) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1783152 Title: Enable basic support for Solarflare 8000 series NIC Status in debian-installer package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in linux-lts-xenial package in Ubuntu: Invalid Status in debian-installer source package in Trusty: Fix Released Status in linux source package in Trusty: Invalid Status in linux-lts-xenial source package in Trusty: Fix Released Status in linux source package in Xenial: Fix Released Status in linux-lts-xenial source package in Xenial: Invalid Bug description: SRU Justification: [Impact] * Users cannot use Solarflare 8000 series NICs. * Servers with only this NIC cannot do netboot. * The patchset adds the PCI IDs and a basic fix. [Test Case] * Try to probe/netboot/use a Solarflare 8000 series NIC. * It does not probe on the original kernel, but it does probe/netboot/install/stress (i.e., basic fuctionality works) on the patched kernel. [Regression Potential] * Users with Solarflare 8000 series NIC might hit problems on device probe or due to a new network interface coming up, now that the NIC comes up. * More specific features of the NIC or advanced tuning/setup might not work as expected or run into issues. [Other Info] * There are known error messages on device probe. * These are benign/non-fatal and will be addressed on another SRU cycle. --- The Trusty HWE kernel from Xenial lacks the PCI ID for the Solarflare 8000 series NIC. This prevents network installs on servers which only have that NIC. In order to get NIC detected, link up, and successful network install, only 2 commits are required: dd248f1bc65b sfc: Add PCI ID for Solarflare 8000 series 10/40G NIC 93171b14a545 sfc: make TSO version a per-queue parameter This patchset is undergoing testing, and I will post the patches to the kernel-team mailing list. --- There are some kernel messages produced possibly due to additional commits missing, but are benign/non-fatal and allows the NIC probing and basic functionality to work. [2.803941] sfc :37:00.0 (unnamed net_device) (uninitialized): Solarflare NIC detected [2.806336] sfc :37:00.0 (unnamed net_device) (uninitialized): Part Number : SFN8042 [2.807366] sfc :37:00.0 (unnamed net_device) (uninitialized): MC command 0x4a inlen 8 failed rc=-2 (raw=2) arg=0 [2.808052] sfc :37:00.0 (unnamed net_device) (uninitialized): no PTP support [2.808488] sfc :37:00.0 (unnamed net_device) (uninitialized): MC command 0x8f inlen 0 failed rc=-1 (raw=1) arg=0 [2.808605] sfc :37:00.0 (unnamed net_device) (uninitialized): failed to allocate PIO buffers (-1) ... [4.037694] sfc :37:00.0 p2p1: link up at 4Mbps full-duplex (MTU 1500) The PTP (precision time protocol / ieee 1588) support is a feature to synchronize clocks over a computer network with high precision, and is not required for basic functionality nor for this particular user. The failure to allocate PIO buffers is non-fatal, see sfc/ef10.c/efx_ef10_dimension_resources() comments. The additional patches to resolve the error messages will be worked on another SRU cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1783152/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1795658] Re: xenial systemd reports 'inactive' instead of 'failed' for service units that repeatedly failed to restart / failed permanently
** Changed in: systemd (Ubuntu) Status: In Progress => Invalid ** Changed in: systemd (Ubuntu) Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1795658 Title: xenial systemd reports 'inactive' instead of 'failed' for service units that repeatedly failed to restart / failed permanently Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: Triaged Bug description: [Impact] * In case a service unit has repeatedly failed to restart, it should be reported as 'failed' permanently, but currently it's instead reported as 'inactive'. * System monitoring tools that evaluate the status of systemd service units and act upon it (for example: restart service, report permanent failure) are currently misled by information in 'systemctl status .service'. * System management tools based on such information may take wrong and/or sub-optimal actions in the managed systems regarding such service units. * This systemd patch [1] directly addresses this issue (see systemd github PR #3166 [2]), and its code is still effectice in upstream systemd today, without further fixes/changes (the only changes were in doc text and the busname files that were removed, but still without further fixes to this). [Test Case] * This is copied from systemd PR #3166 [2]. * This has been tested by a customer as well, and with its system monitoring and management solution, for interoperability verification. $ cat <https://github.com/systemd/systemd/commit/072993504e3e4206ae1019f5461a0372f7d82ddf [2] https://github.com/systemd/systemd/issues/3166 [3] https://launchpad.net/~mfo/+archive/ubuntu/sf199312 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795658/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1783152] Re: Enable basic support for Solarflare 8000 series NIC
This is the patch for trusty debian-installer to pick up this new xenial hwe kernel. It's been tested by the customer with the SF 8000 series NICs on amd64 bare metal (back when using test packages from their private PPA), so the netboot install works on that NIC model. I built it on PPA for the supported architectures on trusty (amd64/i386, arm64/armhf, ppc64el/powerpc) [1], and used the built netboot images for testing. I tested for no regressions / without that NIC adapter, in the following platforms, plain and LVM partitioning, per discussion with folks from our server iso automated testing and server/arm teams. - amd64 bare-metal & kvm guest - arm64 qemu guest (see [2]) - ppc64el qemu guest (see [3]) On testing, the installer boots with the new kernel, installs it to the system, and the installed system boots correctly with it. [1] https://launchpad.net/~mfo/+archive/ubuntu/sf188840di/ [2] https://wiki.ubuntu.com/ARM64/QEMU [3] https://buggy.link/2018/01/31/ppc64le-on-x86_64-qemu-full-system-emulation.html ** Also affects: debian-installer (Ubuntu) Importance: Undecided Status: New ** No longer affects: debian-installer (Ubuntu Xenial) ** Patch added: "d-i_trusty_sf188840.debdiff" https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1783152/+attachment/5182677/+files/d-i_trusty_sf188840.debdiff ** Changed in: debian-installer (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1783152 Title: Enable basic support for Solarflare 8000 series NIC Status in debian-installer package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in linux-lts-xenial package in Ubuntu: New Status in debian-installer source package in Trusty: New Status in linux source package in Trusty: Invalid Status in linux-lts-xenial source package in Trusty: Fix Released Status in linux source package in Xenial: Fix Released Status in linux-lts-xenial source package in Xenial: Invalid Bug description: SRU Justification: [Impact] * Users cannot use Solarflare 8000 series NICs. * Servers with only this NIC cannot do netboot. * The patchset adds the PCI IDs and a basic fix. [Test Case] * Try to probe/netboot/use a Solarflare 8000 series NIC. * It does not probe on the original kernel, but it does probe/netboot/install/stress (i.e., basic fuctionality works) on the patched kernel. [Regression Potential] * Users with Solarflare 8000 series NIC might hit problems on device probe or due to a new network interface coming up, now that the NIC comes up. * More specific features of the NIC or advanced tuning/setup might not work as expected or run into issues. [Other Info] * There are known error messages on device probe. * These are benign/non-fatal and will be addressed on another SRU cycle. --- The Trusty HWE kernel from Xenial lacks the PCI ID for the Solarflare 8000 series NIC. This prevents network installs on servers which only have that NIC. In order to get NIC detected, link up, and successful network install, only 2 commits are required: dd248f1bc65b sfc: Add PCI ID for Solarflare 8000 series 10/40G NIC 93171b14a545 sfc: make TSO version a per-queue parameter This patchset is undergoing testing, and I will post the patches to the kernel-team mailing list. --- There are some kernel messages produced possibly due to additional commits missing, but are benign/non-fatal and allows the NIC probing and basic functionality to work. [2.803941] sfc :37:00.0 (unnamed net_device) (uninitialized): Solarflare NIC detected [2.806336] sfc :37:00.0 (unnamed net_device) (uninitialized): Part Number : SFN8042 [2.807366] sfc :37:00.0 (unnamed net_device) (uninitialized): MC command 0x4a inlen 8 failed rc=-2 (raw=2) arg=0 [2.808052] sfc :37:00.0 (unnamed net_device) (uninitialized): no PTP support [2.808488] sfc :37:00.0 (unnamed net_device) (uninitialized): MC command 0x8f inlen 0 failed rc=-1 (raw=1) arg=0 [2.808605] sfc :37:00.0 (unnamed net_device) (uninitialized): failed to allocate PIO buffers (-1) ... [4.037694] sfc :37:00.0 p2p1: link up at 4Mbps full-duplex (MTU 1500) The PTP (precision time protocol / ieee 1588) support is a feature to synchronize clocks over a computer network with high precision, and is not required for basic functionality nor for this particular user. The failure to allocate PIO buffers is non-fatal, see sfc/ef10.c/efx_ef10_dimension_resources() comments. The additional patches to resolve the error messages will be worked on another SRU cycle. To manage notifications about this bug go to:
