February 2019 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] enable Yama LSM
by Detlef Eppers 01 Mar '19

01 Mar '19

Please add Yama LSM support to openSUSE Tumbleweed kernels. From all major distributions, only SUSE ships kernels with Yama disabled at compile time. Debian and CentOS do support it but pref it off, Ubuntu enables it by default already since 10.10 Maverick Meerkat. I understand and appreciate the conservative approach taken by SUSE in the early years, but please note that Yama landed in mainline almost a decade ago. From an administrators perspective, this is looking increasingly battle tested. In case Yama is still deemed not fit for SUSE kernels, would you mind sharing your reservations with us? Thanks and best regards Ed -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 2

[opensuse-kernel] New Leap 15.1 kernel submitted
by Petr Tesarik 28 Feb '19

28 Feb '19

Hello, I have just submitted a new kernel for Leap 15.1. HEAD == 25279f0cfaf6fe4969e9688092635b431b57156e SR#680183 Top of changes: ------------------------------------------------------------------- Thu Feb 28 16:34:33 CET 2019 - ptesarik(a)suse.cz - Update config files: Change to CONFIG_PREEMPT_VOLUNTARY (bsc#1125004). - commit 47ba65a ------------------------------------------------------------------- Thu Feb 28 12:47:44 CET 2019 - tbogendoerfer(a)suse.de - net: phy: marvell10g: Fix Multi-G advertisement to only advertise 10G (bsc#1119113 FATE#326472). - bnxt_en: Wait longer for the firmware message response to complete (bsc#1086282 FATE#324873). - bnxt_en: Fix typo in firmware message timeout logic (bsc#1086282 FATE#324873). - ixgbe: don't do any AF_XDP zero-copy transmit if netif is not OK (bsc#1113994 FATE#326315 FATE#326317). - i40e: fix XDP_REDIRECT/XDP xmit ring cleanup race (bsc#1111981 FATE#326312 FATE#326313). - ixgbe: fix potential RX buffer starvation for AF_XDP (bsc#1113994 FATE#326315 FATE#326317). - i40e: fix potential RX buffer starvation for AF_XDP (bsc#1111981 FATE#326312 FATE#326313). - commit 52a7bcd Petr T

1 0

[opensuse-kernel] kernel-default-4.20.10-2.1.g4c06520 obsoletes drm-kmp-default (kinda) - why?
by Manfred Hollstein 22 Feb '19

22 Feb '19

Hi there, as per $SUBJECT, the most recent kernel from Kernel:stable obsoletes drm-kmp-default <= 4.12 which results in removal of drm-kmp-default-4.9.33_k4.4.126_48-13.3 on an openSUSE_Leap_42.3 system. I checked kernel-default.spec in OBS and it has this indeed: # SLE12-SP3 / Leap 42.3 %obsolete_kmp drm 4.12 I am still running several systems with Leap 42.3 and always want to be able to also test newer stable kernels, however this change would render most of my systems as useless as they need the drm-kmp-default package for dealing with the Intel HW and graphics adapter (see one example below) and when running the distro kernel. May I ask why it has been introduced? Former versions (4.20.8 only obsoleted the package older than 3.7_3.1) did not appear to have an issue with it being installed. To be honest, does it play a role at all for any kernels from Kernel:stable? I always thought that drm-kmp brings a backport of some newer modules which are otherwise too old for the elder kernels. I would find it unfortunate, if I cannot run the newer kernels anymore on my 42.3 systems... Info about one of my systems: $ inxi -Gxx -C CPU: Quad core Intel Core i7-7700 (-HT-MCP-) cache: 8192 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 28800 clock speeds: min/max: 800/4200 MHz 1: 800 MHz 2: 800 MHz 3: 800 MHz 4: 800 MHz 5: 800 MHz 6: 800 MHz 7: 800 MHz 8: 800 MHz Graphics: Card: Intel HD Graphics 630 bus-ID: 00:02.0 chip-ID: 8086:5912 Display Server: X.Org 1.18.3 drivers: modesetting (unloaded: fbdev,vesa,intel) Resolution: 1920x1200(a)59.95hz GLX Renderer: Mesa DRI Intel Kabylake GT2 GLX Version: 3.0 Mesa 17.0.5 Direct Rendering: Yes TIA, cheers. l8er manfred

4 9

[opensuse-kernel] Proposal - CONFIG_PREEMPT_VOLUNTARY for TW Kernel
by Richard Brown 21 Feb '19

21 Feb '19

Hi all, I was talking to Takashi lately about the saga that is bug 1112824 http://bugzilla.opensuse.org/show_bug.cgi?id=1112824 In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them However, as a heavy GNOME user, in my own testing, I have found the following results CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824 CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME I can understand the reluctance to change a kernel config option just because of a bug, and I do understand the argument than this bug could/should be fixed by GNOME doing less stupid stuff in userspace. That said, I also think it's important that we should aim for defaults somewhat defensively - if _PREEMPT can cause such disruption due to badly written userspace behaviour, but _VOLUNTARY does not, then I think VOLUNTARY is a better option. Therefore after this testing I'm convinced that CONFIG_PREEMPT_VOLUNTARY is a better default for the Tumbleweed kernel-default than the current CONFIG_PREEMPT What do you all think? Regards, Richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

9 15

[opensuse-kernel] Correct way of building a new kernel pkg with an altered config
by Richard Brown 06 Feb '19

06 Feb '19

Hi, I wish to build a few different variants of stable:kernel-default with different config options But trying to do it by patching things the way I thought would be right end up with builds failing: https://build.opensuse.org/package/live_build_log/home:RBrownSUSE:branches:… What is the right process for someone to take kernel:stable, branch the package, tweak the config, and get it building in their home project? Regards, Richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 4