January 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1181018] floppy broken in 5.3.18-lp152.57.1 under KVM
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1181018 https://bugzilla.suse.com/show_bug.cgi?id=1181018#c20 Jiri Kosina <jkosina(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(sbrabec(a)suse.com) | --- Comment #20 from Jiri Kosina <jkosina(a)suse.com> --- So, the gist of the issue is, that my fix above was later reverted instead of being fixed up. I've just revived the upstream thread: https://lore.kernel.org/linux-block/nycvar.YFH.7.76.2101191649190.5622@cbob… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180917] kernel BUG at mm/huge_memory.c:2144!
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180917 https://bugzilla.suse.com/show_bug.cgi?id=1180917#c13 Sarah Julia Kriesch <sarah.kriesch(a)ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ihno(a)suse.com) | --- Comment #13 from Sarah Julia Kriesch <sarah.kriesch(a)ibm.com> --- Thank you for the information, R�diger. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180917] kernel BUG at mm/huge_memory.c:2144!
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180917 https://bugzilla.suse.com/show_bug.cgi?id=1180917#c12 Ruediger Oertel <ro(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ro(a)suse.com --- Comment #12 from Ruediger Oertel <ro(a)suse.com> --- all buildservice workers are LPARs running KVM to run the individual worker instances. the LPARS are (in case of OBS) usually running a current Tumbleweed kernel and the KVM VMs on top usually run the kernel of the target distribution of the package the worker is building for. the bug displayed above is happening on the worker level so as a KVM VM running in an LPAR. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1181104] Unplugging TeVII DVB-S2 USB adapter crashes kernel
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1181104 https://bugzilla.suse.com/show_bug.cgi?id=1181104#c8 --- Comment #8 from Takashi Iwai <tiwai(a)suse.com> --- Good to hear. I'm going to submit the fix then. Shall I put you to Reported-and-tested-by tag? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180917] kernel BUG at mm/huge_memory.c:2144!
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180917 https://bugzilla.suse.com/show_bug.cgi?id=1180917#c11 Sarah Julia Kriesch <sarah.kriesch(a)ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ihno(a)suse.com) --- Comment #11 from Sarah Julia Kriesch <sarah.kriesch(a)ibm.com> --- @Ihno Can you tell Gerald something about the setup of our OBS workers, please? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1181018] floppy broken in 5.3.18-lp152.57.1 under KVM
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1181018 https://bugzilla.suse.com/show_bug.cgi?id=1181018#c19 --- Comment #19 from Michal Suchanek <msuchanek(a)suse.com> --- The reason for O_NONBLOCK is a regression since SLE11 causing the CD tray to close without user action by random software (typically udev) trying to probe the CD state. In the case of CD the O_NONBLOCK means something like: give me a fd, and if there is no disk or if it's not probed read will fail. Without O_NONBLOCK the drive tries to close tray, spin up the disk, and detect what kind of disk is inserted. The drive normally does the detection when the user closes the tray anyway so if the disk was interted in advance O_NONBLOCK gives usable fd. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1181018] floppy broken in 5.3.18-lp152.57.1 under KVM
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1181018 https://bugzilla.suse.com/show_bug.cgi?id=1181018#c18 Jiri Kosina <jkosina(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrabec(a)suse.com Flags|needinfo?(jkosina(a)suse.com) |needinfo?(sbrabec(a)suse.com) --- Comment #18 from Jiri Kosina <jkosina(a)suse.com> --- opening floppy device node with O_NONBLOCK is asking for all kinds of trouble. We had the issue with O_NDELAY in the past too, please see e.g. the changelog of this patch for reference: https://git.kernel.org/linus/09954bad448791ef01202351d437abdd9497a804 If the behavior of blkid can't be changed for $reasons, maybe it's time to really return EWOULDBLOCK from open(/dev/fd0, O_NONBLOCK), but I'd first like to better understand why all of a sudden O_NONBLOCK is being used for floppy node? Thanks. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180917] kernel BUG at mm/huge_memory.c:2144!
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180917 https://bugzilla.suse.com/show_bug.cgi?id=1180917#c10 --- Comment #10 from LTC BugProxy <bugproxy(a)us.ibm.com> --- ------- Comment From geraldsc(a)de.ibm.com 2021-01-19 09:51 EDT------- BTW, you seem to have a really good testcase for THP, at least you are able to trigger all kind of THP issues (at least on s390 :-)). What exactly is your system setup? Is it a KVM or z/VM guest, or did it maybe crash in a KVM host or LPAR? The workload you are using is some "SUSE build sevice", right? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180917] kernel BUG at mm/huge_memory.c:2144!
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180917 https://bugzilla.suse.com/show_bug.cgi?id=1180917#c9 --- Comment #9 from LTC BugProxy <bugproxy(a)us.ibm.com> --- ------- Comment From geraldsc(a)de.ibm.com 2021-01-19 09:45 EDT------- (In reply to comment #13) [...] > > Is there any other means of kernel source access for openSUSE Tumbleweed, > > ideally a git repo like for SLES? Seems hard to believe that "open"SUSE > > kernel source is harder to find / access than SLES code... > > It is not hard to find at all. All you need to know is, that the different > flavors of kernels all depend on a central package called kernel-source, > which has an own mechanics to integrate patches depending on a variety of > conditions. The source can be found in the package > http://download.opensuse.org/ports/zsystems/tumbleweed/repo/oss/noarch/ > kernel-source-5.10.5-1.1.noarch.rpm Hmm, almost right, you also need to know that the kernel-source.noarch.rpm does not contain the full source, and that you need the kernel-devel.noarch.rpm on top (e.g. for arch code). This is the same for SLES, so fortunately I knew it, but of course for SLES it is much less annoying because you also have a proper public git for both kernel source tree and also kernel-source src.rpm content, so you don't really need to bother about knowing which rpms contain what... Anyway, back to the bug, from the kernel source for 5.10.5-1-default I see that it happens on the BUG_ON(!pte_none(*pte)) in __split_huge_pmd_locked(). This is very strange / interesting, because those are the ptes from the pre-allocated and deposited pagetable, which was withdrawn just shortly before that BUG_ON, with pgtable_trans_huge_withdraw(). The pre-allocated pagetables are initialized with empty (invalid) ptes before deposit, so they should of course all (still) be pte_none() after withdrawal. If a pte is !pte_none, then this means that either the pre-allocated pagetable got corrupted while it was deposited, or maybe that pgtable_trans_huge_withdraw() returns something that is not really a pagetable at all. E.g. in theory it could return NULL, if there were more withdrawals than deposits, IIUC the list handling code there correctly. Of course, such a thing should never happen (i.e. it would be a bug), but I am a bit confused why the common code does not also check this with a BUG_ON check. Having a system dump could help to see more of what was going on. Any chance that kdump generated a dump after the BUG_ON? From the backtrace and register output, and a kernel disassembly, one can at least see that in %r1 we have the pte value that did not pass the !pte_none check: 00000000b2b40215. This actually looks like a valid pte, with present / young / read / write-protect set, so one could assume that this is not the "NULL returnend" case, but rather really a pre-allocated pagetable, which somehow got corrupted by someone having it in active access and filling it with valid ptes. Of course, such a thing should also never happen, the pre-allocated and deposited pagetables can not be used until they are withdrawn, very strange. We do actually have an own implementation of the deposit/withdraw functions, because we cannot use the generic versions. On s390, we have 2K pagetables, and two of them within one 4K page, so we cannot use the generic logic that operates on struct pages for (4K) pagetable pages. The pgtable_t is therefore also not a struct page on s390, but rather a direct pointer to the pagetable. For maintainig the list of pre-allocatced pagetables, we put a list_head directly into the pageteables, at the beginning, instead of using page->lru of the struct page associated with the pagetable like it is donr in the generic case. Then, on withdraw, and after list_del, the first two ptes will be cleared so that the list_head gets overwritten and the whole pagetable should be empty again. That is at least suspicious, and it could could explain why you only see this on s390 (do you really?). However, I do not really see how our implementation would change anything that allows the deposited pagetables to change before withdrawing them. It is really the same logic as in generic code, only that we put the list_head somewhere else. I still suspect some race in common code, e.g. some concurrent withdrawals w/o proper locking, but I could not yet find anything suspicious in the code... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180928] New: Drop CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE from kernel 5.10+
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180928 Bug ID: 1180928 Summary: Drop CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE from kernel 5.10+ Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: afaerber(a)suse.com, dmueller(a)suse.com Found By: --- Blocker: --- With kernel 5.10, there is a new option CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE which should be disabled to drop support of outdated cipher pieces. The only known user would have been iwd/ell which are new enough already to not require it anymore thanks to the following commits: * https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=1db8a85a… * https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2 * https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b -- You are receiving this mail because: You are the assignee for the bug.

1 1