kernel January 2024

kernel@lists.fedoraproject.org

5 participants
83 discussions

Kernel 6.7 Test Week Invitation
by Sumantro Mukherjee 15 Jan '24

15 Jan '24

Hey All, I would like to invite all of you to participate in the Kernel 6.7 Test week is happening from 2024-01-21 to 2024-01-28. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the Fedora QA team will hangout at #fedora-test-day(a)libera.chat for questions and discussion. Happy New Year :) [0] http://fedoraproject.org/wiki/Test_Day:2024-01-21_Kernel_6.7_Test_Week [1] https://testdays.fedoraproject.org/events/173 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

2 1

[OS-BUILD PATCH] net: bump CONFIG_MAX_SKB_FRAGS to 45
by Marcelo Ricardo Leitner (via Email Bridge) 12 Jan '24

12 Jan '24

From: Marcelo Ricardo Leitner <mleitner(a)redhat.com> net: bump CONFIG_MAX_SKB_FRAGS to 45 As requested via https://issues.redhat.com/browse/RHEL-467 With the reasoning from: https://lore.kernel.org/netdev/20220203015140.3022854-10-eric.dumazet@gmail… Signed-off-by: Marcelo Ricardo Leitner <mleitner(a)redhat.com> diff --git a/redhat/configs/common/generic/CONFIG_MAX_SKB_FRAGS b/redhat/configs/fedora/generic/CONFIG_MAX_SKB_FRAGS rename from redhat/configs/common/generic/CONFIG_MAX_SKB_FRAGS rename to redhat/configs/fedora/generic/CONFIG_MAX_SKB_FRAGS index blahblah..blahblah 100644 --- a/redhat/configs/common/generic/CONFIG_MAX_SKB_FRAGS +++ b/redhat/configs/fedora/generic/CONFIG_MAX_SKB_FRAGS diff --git a/redhat/configs/rhel/generic/CONFIG_MAX_SKB_FRAGS b/redhat/configs/rhel/generic/CONFIG_MAX_SKB_FRAGS new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/rhel/generic/CONFIG_MAX_SKB_FRAGS @@ -0,0 +1 @@ +CONFIG_MAX_SKB_FRAGS=45 -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2873

2 2

[OS-BUILD PATCH] Add python3-pyyaml to buildreqs for kernel-docs
by Justin M. Forbes (via Email Bridge) 12 Jan '24

12 Jan '24

From: Justin M. Forbes <jforbes(a)fedoraproject.org> Add python3-pyyaml to buildreqs for kernel-docs Upstream commit f061c9f7d058f added a script to parse the Netlink YAML specs and generate RST files. As a result, we need python3-pyyaml for "make htmldocs" to succeed. Signed-off-by: Justin M. Forbes <jforbes(a)fedoraproject.org> diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template index blahblah..blahblah 100644 --- a/redhat/kernel.spec.template +++ b/redhat/kernel.spec.template @@ -673,7 +673,7 @@ BuildRequires: bpftool BuildRequires: rsync %endif %if %{with_doc} -BuildRequires: xmlto, asciidoc, python3-sphinx, python3-sphinx_rtd_theme +BuildRequires: xmlto, asciidoc, python3-sphinx, python3-sphinx_rtd_theme, python3-pyyaml %endif %if %{with_sparse} BuildRequires: sparse -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2872

1 0

✅ PASS: Test report for 6.6.11-200.fc39 (kernel-fedora)
by cki-project＠redhat.com 11 Jan '24

11 Jan '24

Hi, we tested your kernel and here are the results: Overall result: PASSED Merge: OK Compile: OK Test: OK Tested-by: CKI Project <cki-project(a)redhat.com> Kernel information: Brew / Koji Task ID: 111581372 You can find all the details about the test run at https://datawarehouse.cki-project.org/kcidb/checkouts/122228 One or more kernel tests failed: We also see the following known issues which are not related to your changes: Issue: NFS Connectathon: SELinux prevents rpcbind URL: https://bugzilla.redhat.com/1758147 Affected tests: ppc64le - Filesystem - NFS Connectathon x86_64 - Filesystem - NFS Connectathon If you find a failure unrelated to your changes, please ask the test maintainer to review it. This will prevent the failures from being incorrectly reported in the future. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________

1 0

[OS-BUILD PATCHv6 0/3] redhat: introduce RH_KABI_EXCLUDE_WITH_SIZE and enable size checks
by Sabrina Dubroca (via Email Bridge) 10 Jan '24

10 Jan '24

From: Sabrina Dubroca on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1619 This MR introduces a new kABI macro, RH_KABI_EXCLUDE_WITH_SIZE. The implementation is identical to RH_KABI_EXTEND_WITH_SIZE, but the meaning is more in line with RH_KABI_EXCLUDE. The size check and reserved space allows us to exclude an element embedded inside a kABI-protected structure while reserving space for it to grow in the future. The size checks that are part of multiple kABI macros are currently not enabled because the config option to turn them on is missing. Those size checks only make sense on regular builds, so they're disabled on debug kernels. Signed-off-by: Sabrina Dubroca <sdubroca(a)redhat.com> --- include/linux/rh_kabi.h | 30 +++++++++- redhat/configs/rhel/debug/CONFIG_RH_KABI_SIZE_ALIGN_CHECKS | 1 + redhat/configs/rhel/generic/s390x/zfcpdump/CONFIG_RH_KABI_SIZE_ALIGN_CHECKS | 1 + redhat/configs/rhel/generic/CONFIG_RH_KABI_SIZE_ALIGN_CHECKS | 1 + redhat/configs/rhel/rt/generic/CONFIG_RH_KABI_SIZE_ALIGN_CHECKS | 1 + Kconfig.redhat | 9 +++ 6 files changed, 41 insertions(+), 2 deletions(-)

1 3

[OS-BUILD PATCHv5 0/3] redhat: introduce RH_KABI_EXCLUDE_WITH_SIZE and enable size checks
by Sabrina Dubroca (via Email Bridge) 10 Jan '24

10 Jan '24

1 3

[OS-BUILD PATCH] Fix up "random: Add hook to override device reads and getrandom(2)"
by Andreas Gruenbacher (via Email Bridge) 10 Jan '24

10 Jan '24

From: Andreas Gruenbacher <agruenba(a)redhat.com> Fix up "random: Add hook to override device reads and getrandom(2)" RHEL-only commit 7c0b728ae37e7 ("random: Add hook to override device reads and getrandom(2)") adds a call to import_single_range(), but that function has been replaced by import_ubuf() and removed upstream: 6ac805d138709 ("iov_iter: remove unused 'iov' argument from import_single_range()") 9fd7874c0e5c8 ("iov_iter: replace import_single_range() with import_ubuf()") Fix up commit 7c0b728ae37e7 to use import_ubuf() instead. Fixes: 7c0b728ae37e7 ("random: Add hook to override device reads and getrandom(2)") Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> diff --git a/drivers/char/random.c b/drivers/char/random.c index blahblah..blahblah 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1406,7 +1406,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, ubuf, size_t, len, unsigned int, flags rcu_read_unlock(); if (rng) { - ret = import_single_range(ITER_DEST, ubuf, len, &iov, &iter); + ret = import_ubuf(ITER_DEST, ubuf, len, &iter); if (unlikely(ret)) return ret; ret = rng->extrng_read_iter(&iter, !!(flags & GRND_RANDOM)); -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2857

2 3

[OS-BUILD PATCH] random: replace import_single_range() with import_ubuf()
by Justin M. Forbes (via Email Bridge) 09 Jan '24

09 Jan '24

From: Justin M. Forbes <jforbes(a)fedoraproject.org> random: replace import_single_range() with import_ubuf() Upstream commit 6ac805d138709 dropped the iov arg from import_single_range() and upstream commit 9fd7874c0e5c8 replaced import_single_range() with import_ubuff(). As our patch 7c0b728ae37e7 still called import_single_range() in drivers/char/random, this needs to be brought up to date to continue working. Reported-by: Scott Weaver <scweaver(a)redhat.com> Signed-off-by: Justin M. Forbes <jforbes(a)fedoraproject.org> diff --git a/drivers/char/random.c b/drivers/char/random.c index blahblah..blahblah 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1406,7 +1406,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, ubuf, size_t, len, unsigned int, flags rcu_read_unlock(); if (rng) { - ret = import_single_range(ITER_DEST, ubuf, len, &iov, &iter); + ret = import_ubuf(ITER_DEST, ubuf, len, &iter); if (unlikely(ret)) return ret; ret = rng->extrng_read_iter(&iter, !!(flags & GRND_RANDOM)); -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2856

1 0

[OS-BUILD PATCH 0/0] A few updates to the module filtering files for this merge window after experiences with -next
by Thorsten Leemhuis (via Email Bridge) 09 Jan '24

09 Jan '24

From: Thorsten Leemhuis on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2853 NOTE: Truncated patchset since committer email 'fedora(a)leemhuis.info' does not match the submitter's GitLab public email address 'linux(a)leemhuis.info'. In the past few weeks while building linux-next for my kernel vanilla repositories I noticed a few upstream changes that require changes to files like mod-internal.list or filter-modules.sh.fedora for kernel-ark builds to succeed. Changes like these will most likely be needed in kernel-ark/os-build soon, as the those upstream changes are heading towards mainline currently. I'm providing these changes here in advance in case they might helpful for @jmflinuxtx or somebody else (either for cherry-picking for for merging as a whole). Signed-off-by: Thorsten Leemhuis <fedora(a)leemhuis.info> --- redhat/fedora_files/filter-aarch64.sh.fedora | 2 ++ redhat/fedora_files/filter-modules.sh.fedora | 2 +- redhat/fedora_files/filter-ppc64le.sh.fedora | 2 +- redhat/scripts/mod/mod-internal.list | 1 + 4 files changed, 5 insertions(+), 2 deletions(-)

1 0

The kernel-ark os-build branch has been rebased
by Justin Forbes 08 Jan '24

08 Jan '24

Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.8 releases, and again with 6.9... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2024