kernel September 2017

kernel@lists.fedoraproject.org

13 participants
14 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

Locally compiled 4.14.0-0.rc2.git0.1 kernel has a few issues
by stan 25 Oct '17

25 Oct '17

I have compiled the 4.14.0-0.rc2.git0.1 kernel here with a custom configuration. I've had two issues. First, when I boot into multiuser, instead of white text on black background, the virtual terms come up with gray text on white background, a killer for the eyes. If I then start X, the virtual terminals revert to white on black text. This was not an issue in the 13, or before, series of kernels. Second, I had a system lockup. It has been multiple kernel series since I have had one. The only configuration option that I changed between 13 and 14 was to use the hardened slab freelist. I'll see if a lockup happens again, or was a fluke. Just a heads up that there might be some rough edges in the 14 series.

1 2

x86 Architecture SIG
by Jeff Backus 04 Oct '17

04 Oct '17

(Apologies - resending because I wasn't subscribed earlier) Hi list, I'm contacting you on behalf of the x86 SIG. Today FESCo approved our request to continue to support Fedora on x86 hardware, provided that we do our part to keep things running. I encourage you to reach out to us when things do come up. You can find us at x86(a)lists.fedoraproject.org or on #fedora-x86. We will likewise try to be proactive in tracking down and triaging x86-related issues as well as helping test and debug things. One caveat that FESCo attached to our request is that if you, the kernel team are cleared to treat i686 as any other secondary arch when you run into build issues. That is, you are allowed to ExcludeArch i686 until these issues are resolved. We ask that you block FE-ExcludeArch-x86 so that we can track these issues. Additionally, FESCo would like us to establish a minimum level of hardware supported. We are working on this list and will follow up with you once we have it completed. In the interim, we did want to address a couple of concerns that were passed along by Stephen Smoogen: * We have decided to drop support for PAE, so please feel free to disable it on the next build * We have decided to continue to support pre-SSE2 hardware for the time being Please don't hesitate to contact us with any questions/comments/concerns. Thanks! jeff -- Jeff Backus jeff.backus(a)gmail.com http://github.com/jsbackus http://gitlab.com/jsbackus

6 8

[PATCH] Move CONFIG_USB_CHIPIDEA for all armv7
by Nicolas Chauvet 28 Sep '17

28 Sep '17

Since kernel 4.14-rc1, this allows USB Device Controller (UDC) on jetson-tk1 Move this config to all armv7 so lpae also has it. Tested on jetson-tk1 and paz00 Signed-off-by: Nicolas Chauvet <kwizart(a)gmail.com> --- baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA | 0 baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA_HOST | 0 baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA_UDC | 0 baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA_ULPI | 0 kernel-armv7hl-lpae-debug.config | 6 ++++-- kernel-armv7hl-lpae.config | 6 ++++-- 6 files changed, 8 insertions(+), 4 deletions(-) rename baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA (100%) rename baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA_HOST (100%) rename baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA_UDC (100%) rename baseconfig/arm/armv7/{armv7 => }/CONFIG_USB_CHIPIDEA_ULPI (100%) diff --git a/baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA b/baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA similarity index 100% rename from baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA rename to baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA diff --git a/baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA_HOST b/baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA_HOST similarity index 100% rename from baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA_HOST rename to baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA_HOST diff --git a/baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA_UDC b/baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA_UDC similarity index 100% rename from baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA_UDC rename to baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA_UDC diff --git a/baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA_ULPI b/baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA_ULPI similarity index 100% rename from baseconfig/arm/armv7/armv7/CONFIG_USB_CHIPIDEA_ULPI rename to baseconfig/arm/armv7/CONFIG_USB_CHIPIDEA_ULPI diff --git a/kernel-armv7hl-lpae-debug.config b/kernel-armv7hl-lpae-debug.config index bb0c4f2c..13c9e973 100644 --- a/kernel-armv7hl-lpae-debug.config +++ b/kernel-armv7hl-lpae-debug.config @@ -5955,8 +5955,10 @@ CONFIG_USB_BELKIN=y CONFIG_USB_CATC=m CONFIG_USB_CDC_PHONET=m CONFIG_USB_CHAOSKEY=m -# CONFIG_USB_CHIPIDEA is not set -# CONFIG_USB_CHIPIDEA_ULPI is not set +CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_USB_CHIPIDEA=m +CONFIG_USB_CHIPIDEA_UDC=y +CONFIG_USB_CHIPIDEA_ULPI=y CONFIG_USB_CONFIGFS_ACM=y CONFIG_USB_CONFIGFS_ECM_SUBSET=y CONFIG_USB_CONFIGFS_ECM=y diff --git a/kernel-armv7hl-lpae.config b/kernel-armv7hl-lpae.config index 6fc6fa22..ee9850d9 100644 --- a/kernel-armv7hl-lpae.config +++ b/kernel-armv7hl-lpae.config @@ -5932,8 +5932,10 @@ CONFIG_USB_BELKIN=y CONFIG_USB_CATC=m CONFIG_USB_CDC_PHONET=m CONFIG_USB_CHAOSKEY=m -# CONFIG_USB_CHIPIDEA is not set -# CONFIG_USB_CHIPIDEA_ULPI is not set +CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_USB_CHIPIDEA=m +CONFIG_USB_CHIPIDEA_UDC=y +CONFIG_USB_CHIPIDEA_ULPI=y CONFIG_USB_CONFIGFS_ACM=y CONFIG_USB_CONFIGFS_ECM_SUBSET=y CONFIG_USB_CONFIGFS_ECM=y -- 2.13.5

2 1

Fwd: Patch for trimslices on 4.13+
by Nicolas Chauvet 25 Sep '17

25 Sep '17

Hi, This patch fixes pcie on tegra20. This affects trimslice ethernet usage (there is no network) on kernel 4.13+ https://marc.info/?l=linux-pci&m=150614748008380&w=2 While speaking about trimslice. I would like to consider dropping ARM-tegra-usb-no-reset.patch because this patch is unneeded anymore with any kernel/bootloader. It also prevent other tegra-ehci devices to enter suspend. I can submit patches if needed for both... (However I don't know if it's won't be better for the patches to be submitted on the kernel tree with source+fedora-patches (1) or the distgit version ?). (1) https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/ Thx -- - Nicolas (kwizart)

2 1

kernel-next package
by Chuck Ebbert 23 Sep '17

23 Sep '17

Can we have a kernel package for the next- series on Rawhide? I tried hacking it into the existing specfile but that just didn't work. I'm thinking it needs to be its own package, providing kernel=999-next-<date> or something like that. Obviously, anyone installing this gets to deal with version conflicts and updates etc.

2 1

Kernel 4.13 rebase plans
by Laura Abbott 12 Sep '17

12 Sep '17

Hi, Kernel 4.13 was released this past weekend. This kernel has been built for rawhide and is building for F27 as well. We will be following the same upgrade procedure as in the past. F25 and F26 will get rebased to 4.13 after a few stable releases, typically 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream does not give release dates for stable release but given past timings, this will probably happen towards the end of September. As always, if you have any questions please let me know. Thanks, Laura

1 1

Fwd: [PATCHv2 00/14] arm64: VMAP_STACK support
by Jon Masters 12 Sep '17

12 Sep '17

Can you enable CONFIG_VMAP_STACK for aarch64 kernels once this lands in 4.14? I'd like to see any problems flagged early and often on this... Jon. -------- Forwarded Message -------- Subject: [PATCHv2 00/14] arm64: VMAP_STACK support Date: Tue, 15 Aug 2017 13:50:35 +0100 From: Mark Rutland <mark.rutland(a)arm.com> To: linux-arm-kernel(a)lists.infradead.org CC: ard.biesheuvel(a)linaro.org, catalin.marinas(a)arm.com, james.morse(a)arm.com, labbott(a)redhat.com, linux-kernel(a)vger.kernel.org, luto(a)amacapital.net, mark.rutland(a)arm.com, matt(a)codeblueprint.co.uk, will.deacon(a)arm.com, kernel-hardening(a)lists.openwall.com, keescook(a)chromium.org Hi, Ard and I have worked together to implement vmap stack support for arm64. This supersedes our earlier vmap stack RFCs [0,1]. The git author stats are a little misleading, as I've teased parts out into smaller patches for review. The series is based on our stack dump rework [2,3], which can be found in the arm64/exception-stack branch [4] of my kernel.org repo. This series can be found in the arm64/vmap-stack branch [5] of the same repo. Since v1 [6]: * Fix typos * Update comments in entry assembly * Dump exception context (and stacks) before regs * Define safe adr_this_cpu for modules On arm64, there is no double-fault exception, as software saves exception context to the stack. An erroneous memory access taken during exception handling results in a data abort, as with any other erroneous memory access. To avoid taking these recursively, we must detect overflow by checking the SP before we attempt to store any context to the stack. Doing this efficiently requires a couple of tricks. For a naturally aligned stack, bits THREAD_SHIFT-1:0 of a valid SP may contain any arbitrary value: 0bXX .. 11111111111111 0bXX .. 11011001011100 0bXX .. 00000000000000 By aligning stacks to double their natural alignment, we know that the THREAD_SHIFT bit of any valid SP must be zero: 0bXX .. 0 11111111111111 0bXX .. 0 11011001011100 0bXX .. 0 00000000000000 ... while an overflow will result in this bit flipping, along with (some) other high-order bits: 0bXX .. 0 00000000000000 < SP -= 1 > 0bXX .. 1 11111111111111 ... and thus, we can detect overflows of up to THREAD_SIZE by testing the THREAD_SHIFT bit of the SP value. Provided we can get the SP into a general purpose register, we can perform this test with a single TBNZ instruction. We don't have scratch space to store a GPR, but we can (partially) swap the SP with a GPR using arithmetic to perform the test: add sp, sp, x0 // sp' = sp + x0 sub x0, sp, x0 // x0' = sp' - x0 = (sp + x0) - x0 = sp tbnz x0, #THREAD_SHIFT, overflow_handler sub x0, sp, x0 // sp' - x0' = (sp + x0) - sp = x0 sub sp, sp, x0 // sp' - x0 = (sp + x0) - x0 = sp This series implements this approach, along with the other requisite changes required to make this work. The SP test is performed for all exceptions, after compensating for the size of the exception registers, allowing the original exception context to be preserved in entirety. The tests themselves are folded into the exception vectors, minimizing their impact. To ensure that IRQ stack overflows are detected and handled, IRQ stacks are now dynamically allocated, with guard pages. I've given the series some light testing with LKDTM, Syzkaller, Vince Weaver's perf fuzzer, and a few combinations of debug options. I haven't compared performance of the entire series to a baseline kernel, but from testing so far the cost of the SP test falls in the noise for a kernel build workload on Cortex-A57. Many thanks to Ard for putting up with my meddling, and also to Laura, James, Catalin, and Will for comments and testing. Thanks, Mark. [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518368.html [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518434.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/520705.html [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/521435.html [4] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/exception-stack [5] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/vmap-stack [6] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/524179.ht… Ard Biesheuvel (2): arm64: kernel: remove {THREAD,IRQ_STACK}_START_SP arm64: assembler: allow adr_this_cpu to use the stack pointer Mark Rutland (12): arm64: remove __die()'s stack dump fork: allow arch-override of VMAP stack alignment arm64: factor out PAGE_* and CONT_* definitions arm64: clean up THREAD_* definitions arm64: clean up irq stack definitions arm64: move SEGMENT_ALIGN to <asm/memory.h> efi/arm64: add EFI_KIMG_ALIGN arm64: factor out entry stack manipulation arm64: use an irq stack pointer arm64: add basic VMAP_STACK support arm64: add on_accessible_stack() arm64: add VMAP_STACK overflow detection arch/arm64/Kconfig | 1 + arch/arm64/include/asm/assembler.h | 8 +- arch/arm64/include/asm/efi.h | 8 ++ arch/arm64/include/asm/irq.h | 25 ------ arch/arm64/include/asm/memory.h | 53 +++++++++++++ arch/arm64/include/asm/page-def.h | 34 +++++++++ arch/arm64/include/asm/page.h | 12 +-- arch/arm64/include/asm/processor.h | 2 +- arch/arm64/include/asm/stacktrace.h | 60 ++++++++++++++- arch/arm64/include/asm/thread_info.h | 10 +-- arch/arm64/kernel/entry.S | 121 ++++++++++++++++++++++++------ arch/arm64/kernel/irq.c | 40 +++++++++- arch/arm64/kernel/ptrace.c | 1 + arch/arm64/kernel/smp.c | 2 +- arch/arm64/kernel/stacktrace.c | 7 +- arch/arm64/kernel/traps.c | 44 ++++++++++- arch/arm64/kernel/vmlinux.lds.S | 18 +---- drivers/firmware/efi/libstub/arm64-stub.c | 6 +- kernel/fork.c | 5 +- 19 files changed, 353 insertions(+), 104 deletions(-) create mode 100644 arch/arm64/include/asm/page-def.h -- 1.9.1

3 3

Assistance to built a kernel with patches
by Luya Tshimbalanga 08 Sep '17

08 Sep '17

Hello team, I attemptedt o build a patched kernel from the Fedora repo using the tutorial[1] and hit a roadblock as seen from COPR repository: https://copr.fedorainfracloud.org/coprs/luya/kernel-acpi-ec/builds/ You can check the details of the bug on https://bugzilla.kernel.org/show_bug.cgi?id=196847 along the needed patches for testing https://patchwork.kernel.org/patch/9931477/ https://patchwork.kernel.org/patch/9931481/ https://patchwork.kernel.org/patch/9931473/ Could someone provide a guide for addressing the issue? Thank you, Luya Reference ------------- [1] https://fedoramagazine.org/building-fedora-kernel/

2 3

Re: Kernel 4.13 rebase plans
by Josh Boyer 05 Sep '17

05 Sep '17

On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth <james.hogarth(a)gmail.com> wrote: > > > On 5 September 2017 at 22:40, Chris Murphy <lists(a)colorremedies.com> wrote: >> >> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy <lists(a)colorremedies.com> >> wrote: >> >> > FWIW, you can just download the F27 kernel, kernel-core, >> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in >> > that same download directory and it will install it without complaint. >> > I routinely run Fedora built n+1 (typically rawhide) kernels on >> > current release OS. >> >> Small gotcha is that you can't upgrade perf, dnf will complain. But >> usually rudimentary use of current perf will work with a newer kernel. >> >> >> > > Right ... with kernel-tools and perf I'd rather have something built against > the F26 userspace ... but I have run the rawhidenodebug kernels in the past > for testing ... it's just nicer and more representative for testing what > will end up in the F26 repos to have the kernel built against F26 in the > stabilization COPR I've suggested in the past that we ship the userspace tools in a completely separate package, leaving ONLY kernel bits in the kernel SRPM and subpackages. Partly for this reason, and also because there is no NEED to build e.g. perf daily. I'm willing to put my money where my mouth is and do the maintenance on the userspace side if people want to pursue this. josh

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel September 2017