August 2021 - openSUSE Kernel - openSUSE Mailing Lists

kernel packages sysctl values
by Ludwig Nussel 24 Aug '21

24 Aug '21

Hi, Following up on a discussion in bug 1184804 I took a look at the sysctl values each kernel ships in a separate file. vm.dirty_ratio is set to 20 on pae and x86_64 default kernels. AFAICS this is the builtin default of the kernel so can be dropped. kernel.hung_task_timeout_secs is set to zero. There's also a DEFAULT_HUNG_TASK_TIMEOUT kconfig setting. So I think this would be better set as kconfig option. That leaves some IPC settings that were set in 2006 due to bug 146656: | Name | where | setting | default | |---------------+-------+--------------------+--------------------+ | kernel.msgmax | all | 65536 | 8192 | | kernel.msgmnb | all | 65536 | 16384 | | kernel.shmmax | 32bit | 0xffffffff | 0xfeffffff | | kernel.shmall | 32bit | 0xffffffff | 0xfeffffff | | kernel.shmmax | 64bit | 0x0fffffffffffff00 | 0xfffffffffeffffff | | kernel.shmall | 64bit | 0x0fffffffffffff00 | 0xfffffffffeffffff | All of them were supposed to be higher than the default. The shmmax and shmall on 64bit systems are actually lower though if I calculate correctly (upstream default is ULONG_MAX - (1UL << 24)). So I guess those two can be dropped on 64bit systems? Is the 32bit limit relevant? If not, shm* wouldn't need to be set at all via sysctl. Then we'd only have msgmax and msgmnb left. In the bug the upstream defaults were called "totally useless". Maybe makes sense to take the change upstream then? :-) In any case the setting is not kernel version or flavor dependent. So even if not for upstream, we could set msgmax and msgmnb in aaa_base instead. It already ships distro defaults: https://github.com/openSUSE/aaa_base/blob/master/files/usr/lib/sysctl.d/50-… Thoughts? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

1 0

Looking for the patch file for the fix described in Support document #000019780
by Derek P 10 Aug '21

10 Aug '21

https://www.suse.com/support/kb/doc/?id=000019780 I found this report from last year that seems to match a problem encountered on one of our non-opensuse servers. I dropped by irc://libera.chat/opensuse to see if I could find the bug and patch to check the source of our CIFS module to see if it was missing. They told me to ask the kernel list. Can you help? Thanks.

1 1

Re: kernel head coops since config: re-modularize CRYPTO_{CTS,ECB,HMAC,SHA512,XTS} (bsc#1189034).
by Jeff Mahoney 09 Aug '21

09 Aug '21

On 8/9/21 4:35 AM, Cristian Rodríguez wrote: > I believe this change caudses the following oops on my system: > > * Tue Aug 03 2021 jeffm(a)jeffm.io > - config: re-modularize CRYPTO_{CTS,ECB,HMAC,SHA512,XTS} (bsc#1189034). > Now that FS_ENCRYPTION_ALGS is modular, the crypto modules it utilizes > can be modular as well. CRYPTO_AES and CRYPTO_CBC are used by > ENCRYPTED_KEYS and must remain built-in. > - commit 5f8b914 I've updated the bug report for this. TL;DR there was a regression introduced in 5.14-rc1. The root cause is that DRBG now tests sha512 on startup and does so before the initramfs is loaded. The commit that made that change didn't add it to the Kconfig option to select it as a built-in. BTW, not an oops, just a warning -- but it would've been a full panic if the system was booted in FIPS mode. I would've CC'd you to the bug but our Bugzilla doesn't do searching for users anymore (yay GDPR) and it's not the same as your email here. Thanks for the report, -Jeff > 0.238360] wait_for_initramfs() called before rootfs_initcalls > [ 0.250353] DRBG: could not allocate digest TFM handle: hmac(sha512) > [ 0.250353] alg: drbg: Failed to reset rng > [ 0.250353] alg: drbg: Test 0 failed for drbg_nopr_hmac_sha512 > [ 0.250353] ------------[ cut here ]------------ > [ 0.250353] alg: self-tests for drbg_nopr_hmac_sha512 (stdrng) > failed (rc=-22) > [ 0.250353] WARNING: CPU: 0 PID: 130 at crypto/testmgr.c:5652 > alg_test+0x357/0x540 > [ 0.250353] Modules linked in: > [ 0.250353] CPU: 0 PID: 130 Comm: cryptomgr_test Not tainted > 5.14.0-rc5-1.g1838496-default #1 openSUSE Tumbleweed (unreleased) > 31a1ab2de085eb8c788832590628680dfc173760 > [ 0.250353] Hardware name: Microsoft Corporation Virtual > Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 11/01/2019 > [ 0.250353] RIP: 0010:alg_test+0x357/0x540 > [ 0.250353] Code: 01 00 00 80 3d 22 4a fe 01 00 0f 85 c9 01 00 00 > 44 89 c1 4c 89 ea 48 89 ee 48 c7 c7 18 1d b9 84 44 89 44 24 08 e8 0a > f4 55 00 <0f> 0b 44 8b 44 24 08 48 8b 84 24 a0 00 00 00 65 48 2b 04 25 > 28 00 > [ 0.250353] RSP: 0000:ffffaf2a0089be28 EFLAGS: 00010282 > [ 0.250353] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000ffffbfff > [ 0.250353] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 0000000000000001 > [ 0.250353] RBP: ffff94dd40b3e600 R08: ffff94de47f5a068 R09: 00000000ffffbfff > [ 0.250353] R10: ffff94de3faa0000 R11: ffff94de3faa0000 R12: 000000000000000c > [ 0.250353] R13: ffff94dd40b3e680 R14: 0000000000000053 R15: 00000000000014c0 > [ 0.250353] FS: 0000000000000000(0000) GS:ffff94de3fc00000(0000) > knlGS:0000000000000000 > [ 0.250353] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.250353] CR2: 0000000000000000 CR3: 00000001eb210001 CR4: 00000000003706f0 > [ 0.250353] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 0.250353] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 0.250353] Call Trace: > [ 0.250353] ? __schedule+0x32d/0x1530 > [ 0.250353] ? ttwu_do_wakeup+0x17/0x150 > [ 0.250353] ? _raw_spin_unlock_irqrestore+0xa/0x20 > [ 0.250353] ? try_to_wake_up+0x1d1/0x4f0 > [ 0.250353] ? __cond_resched+0x16/0x40 > [ 0.250353] ? crypto_acomp_scomp_free_ctx+0x30/0x30 > [ 0.250353] cryptomgr_test+0x27/0x50 > [ 0.250353] kthread+0x124/0x150 > [ 0.250353] ? set_kthread_struct+0x40/0x40 > [ 0.250353] ret_from_fork+0x1f/0x30 > [ 0.250353] ---[ end trace c2ebd3efee6d0c0e ]--- > > > Just FYI..thanks. > -- Jeff Mahoney Director, SUSE Labs Data & Performance

1 0