kernel August 2017

kernel@lists.fedoraproject.org

9 participants
5 discussions

debuginfo sub-packages for the kernel
by Laura Abbott 22 Nov '17

22 Nov '17

Hi, I started playing around with having RPM automatically generate the debuginfo subpackages per https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo Because the kernel is a continual source of exceptions, the existing code doesn't handle the case where the debuginfo and file may have different names. The kernel modules are compressed at the install stage so foo.ko becomes foo.ko.xz. The debuginfo is generated as foo.ko.debug. The existing code to split debugfiles.list can't detect this so those files end up as unpackaged. A similar problem happens with the vmlinux for the main kernel. Is this an issue that can reasonably be fixed or worked around to support the debuginfo subpackages for the kernel? I want to make sure I'm not digging myself into a hole before I spend more time on this. Thanks, Laura

2 3

Topics for kernel discussion at Flock
by Laura Abbott 24 Aug '17

24 Aug '17

Hi, Flock is next week and there is a session about kernel process (https://flock2017.sched.com/event/Bm9W/fedora-kernel-process-review) Obviously not everyone can attend flock but if there are topics you would like to see discussed, please let me know. Thanks, Laura

3 5

Different behavior for kernel entropy in 4.13 kernel
by stan 20 Aug '17

20 Aug '17

Hi, I compile a custom kernel locally from the Fedora src.rpm. I notice that the most recent 4.13 kernel I compiled, 4.13.0-0.rc4.git3.1, has different behavior for the kernel entropy pool than it used to have. The way it used to work was that when the kernel entropy pool was kept full, or fuller, it would bleed entropy across to the pseudo-random generator in order to reseed it. This makes the output sequence of the PRNG indeterminate, and thus more random, and harder to attack. It is no longer a pseudo random number generator, except in intervals. I notice now that there is no bleed happening. When the kernel entropy pool gets full, if there are no calls to /dev/random, it stays full. I don't have a hardware RNG, but I harvest entropy from a sound device, and from an rtl2832 receiver (atmospheric). They still work, if I do cat /dev/random | rngtest -b 10 they get fired up and run full out. But if I do cat /dev/urandom | rngtest -b 20000 the entropy pool just sits there, and they don't run. The entropy pool can be looked at, as root, with cat /proc/sys/kernel/random/entropy_avail I reset the write_wakeup_threshold there to 3840 from its default 1792, and lower the urandom_min_reseed_secs to 5 (I think the default is 60). Can you explain why this was changed, or point me to a discussion of the rationale for the change? It seems like it has implications for system security, and on the surface seems to decrease security of the PRNG. Thanks.

2 11

[PATCH] disable SWIOTLB on Power (#1480380)
by Dan Horák 11 Aug '17

11 Aug '17

All supported platforms have IOMMU, thus disable. --- baseconfig/powerpc/CONFIG_SWIOTLB | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/baseconfig/powerpc/CONFIG_SWIOTLB b/baseconfig/powerpc/CONFIG_SWIOTLB index 5405b65..ac62bf3 100644 --- a/baseconfig/powerpc/CONFIG_SWIOTLB +++ b/baseconfig/powerpc/CONFIG_SWIOTLB @@ -1 +1 @@ -CONFIG_SWIOTLB=y +# CONFIG_SWIOTLB is not set -- 2.7.5

2 1

Adding vboxguest and vboxsf drivers to Fedora kernel pkg
by Hans de Goede 09 Aug '17

09 Aug '17

Hi, I've been working on cleaning up the vboxguest drivers so that they can be added to the mainline kernel for: https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration The vboxvideo driver is already upstream, atm it is in staging because it still needs to be ported to the new atomic-kms APIs but otherwise it is in very good state and not really of staging quality (I've already done a lot of cleanup reducing it from 52681 in its original form to 7275 lines in staging). Some people have expressed concerns about my plans to _temporarily_ carry patches for the vboxguest integration in the Fedora kernel pkg. I can understand that you are reluctant to carry patches which need to be maintained for ever and ever, but that is not the case here. I've been working my ass of to get these drivers cleaned up in time for F27, so that the _cleaned up_ version can be added to the Fedora kernels for a kernel release or 2, see: https://github.com/jwrdegoede/vboxguest/commits/master for all the work I've been oing on the vboxguest driver. As mentioned on the fedora-devel list I did not contact the kernel team before because I first wanted to have something to show and something better then just dropping the vbox out-of-tree drivers into the kernel as is. The other 2 drivers needed for vboxguest integration are the vboxguest and vboxsf drivers. I now have the vboxguest driver ready for upstream submission, reducing it from 100587 lines of code in /usr/src/vboxguest-5.1.24/vboxguest to just 6324 lines for the patch I'm going to submit upstream: https://github.com/jwrdegoede/linux-sunxi/commit/fdfa2fe410c04b11512ce3b63e… I plan to also have the vboxsf driver ready coming Friday and to submit both upstream then. As you can see from the above link the vboxguest driver is not big and is completely self contained, without needing changes anywhere else in the kernel. The vboxsf driver is the same. As such carrying these 2 drivers as patches should cause very little work and I will maintain them both while they are patched in and afterwards. So I'm hereby asking the Fedora kernel-team for permission to add these 2 drivers as patches to the Fedora kernel for a kernel-release or 2 while I finish pushing them upstream. Regards, Hans

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel August 2017