kernel November 2020

kernel@lists.fedoraproject.org

28 participants
124 discussions

[OS-BUILD PATCH] [redhat] New configs in crypto/Kconfig
by GitLab Bridge on behalf of jeremycline 14 Apr '21

14 Apr '21

From: Fedora Kernel Team <kernel-team(a)fedoraproject.org> Hi, As part of the ongoing rebase effort, the following configuration options need to be reviewed. As a reminder, the ARK configuration flow involves moving unreviewed configuration options from the pending directory to the ark directory. In the diff below, options are removed from the pending directory and added to the ark hierarchy. The final options that need to be ACKed are the files that are being added to the ark hierarchy. If the value for a file that is added should be changed, please reply with a better option. CONFIG_CRYPTO_SM2: Generic implementation of the SM2 public key algorithm. It was published by State Encryption Management Bureau, China. as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012. References: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 http://www.oscca.gov.cn/sca/xxgk/2010-12/17/content_1002386.shtml http://www.gmbz.org.cn/main/bzlb.html Symbol: CRYPTO_SM2 [=n] Type : tristate Defined at crypto/Kconfig:263 Prompt: SM2 algorithm Depends on: CRYPTO [=y] Location: -> Cryptographic API (CRYPTO [=y]) Selects: CRYPTO_SM3 [=n] && CRYPTO_AKCIPHER [=y] && CRYPTO_MANAGER [=y] && MPILIB [=y] && ASN1 [=y] --- CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE: Allow obsolete cryptographic algorithms to be selected that have already been phased out from internal use by the kernel, and are only useful for userspace clients that still rely on them. Symbol: CRYPTO_USER_API_ENABLE_OBSOLETE [=y] Type : bool Defined at crypto/Kconfig:1915 Prompt: Enable obsolete cryptographic algorithms for userspace Depends on: CRYPTO [=y] && CRYPTO_USER_API [=y] Location: -> Cryptographic API (CRYPTO [=y]) --- CONFIG_CRYPTO_USER_API_RNG_CAVP: This option enables extra API for CAVP testing via the user-space interface: resetting of DRBG entropy, and providing Additional Data. This should only be enabled for CAVP testing. You should say no unless you know what this is. Symbol: CRYPTO_USER_API_RNG_CAVP [=n] Type : bool Defined at crypto/Kconfig:1895 Prompt: Enable CAVP testing of DRBG Depends on: CRYPTO [=y] && CRYPTO_USER_API_RNG [=y] && CRYPTO_DRBG [=y] Location: -> Cryptographic API (CRYPTO [=y]) -> User-space interface for random number generator algorithms (CRYPTO_USER_API_RNG [=y]) --- Cc: Herbert Xu <herbert.xu(a)redhat.com> Cc: "David S. Miller" <davem(a)redhat.com> Cc: Ondrej Mosnacek <omosnace(a)redhat.com> Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org> --- .../configs/common/generic/CONFIG_CRYPTO_SM2 | 1 + .../CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE | 1 + .../generic/CONFIG_CRYPTO_USER_API_RNG_CAVP | 1 + .../pending-common/generic/CONFIG_CRYPTO_SM2 | 23 ------------------- .../CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE | 17 -------------- .../generic/CONFIG_CRYPTO_USER_API_RNG_CAVP | 19 --------------- 6 files changed, 3 insertions(+), 59 deletions(-) create mode 100644 redhat/configs/common/generic/CONFIG_CRYPTO_SM2 create mode 100644 redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE create mode 100644 redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP delete mode 100644 redhat/configs/pending-common/generic/CONFIG_CRYPTO_SM2 delete mode 100644 redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE delete mode 100644 redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP diff --git a/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 b/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 new file mode 100644 index 000000000000..0d8c1b551abf --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 @@ -0,0 +1 @@ +# CONFIG_CRYPTO_SM2 is not set diff --git a/redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE b/redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE new file mode 100644 index 000000000000..21d316c28741 --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE @@ -0,0 +1 @@ +CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE=y diff --git a/redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP b/redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP new file mode 100644 index 000000000000..7826178972a9 --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP @@ -0,0 +1 @@ +# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set diff --git a/redhat/configs/pending-common/generic/CONFIG_CRYPTO_SM2 b/redhat/configs/pending-common/generic/CONFIG_CRYPTO_SM2 deleted file mode 100644 index b577bb249279..000000000000 --- a/redhat/configs/pending-common/generic/CONFIG_CRYPTO_SM2 +++ /dev/null @@ -1,23 +0,0 @@ -# CONFIG_CRYPTO_SM2: -# -# Generic implementation of the SM2 public key algorithm. It was -# published by State Encryption Management Bureau, China. -# as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012. -# -# References: -# https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 -# http://www.oscca.gov.cn/sca/xxgk/2010-12/17/content_1002386.shtml -# http://www.gmbz.org.cn/main/bzlb.html -# -# Symbol: CRYPTO_SM2 [=n] -# Type : tristate -# Defined at crypto/Kconfig:263 -# Prompt: SM2 algorithm -# Depends on: CRYPTO [=y] -# Location: -# -> Cryptographic API (CRYPTO [=y]) -# Selects: CRYPTO_SM3 [=n] && CRYPTO_AKCIPHER [=y] && CRYPTO_MANAGER [=y] && MPILIB [=y] && ASN1 [=y] -# -# -# -# CONFIG_CRYPTO_SM2 is not set diff --git a/redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE b/redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE deleted file mode 100644 index b8bda73dbf55..000000000000 --- a/redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE +++ /dev/null @@ -1,17 +0,0 @@ -# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE: -# -# Allow obsolete cryptographic algorithms to be selected that have -# already been phased out from internal use by the kernel, and are -# only useful for userspace clients that still rely on them. -# -# Symbol: CRYPTO_USER_API_ENABLE_OBSOLETE [=y] -# Type : bool -# Defined at crypto/Kconfig:1915 -# Prompt: Enable obsolete cryptographic algorithms for userspace -# Depends on: CRYPTO [=y] && CRYPTO_USER_API [=y] -# Location: -# -> Cryptographic API (CRYPTO [=y]) -# -# -# -CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE=y diff --git a/redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP b/redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP deleted file mode 100644 index 7e0c667a45ce..000000000000 --- a/redhat/configs/pending-common/generic/CONFIG_CRYPTO_USER_API_RNG_CAVP +++ /dev/null @@ -1,19 +0,0 @@ -# CONFIG_CRYPTO_USER_API_RNG_CAVP: -# -# This option enables extra API for CAVP testing via the user-space -# interface: resetting of DRBG entropy, and providing Additional Data. -# This should only be enabled for CAVP testing. You should say -# no unless you know what this is. -# -# Symbol: CRYPTO_USER_API_RNG_CAVP [=n] -# Type : bool -# Defined at crypto/Kconfig:1895 -# Prompt: Enable CAVP testing of DRBG -# Depends on: CRYPTO [=y] && CRYPTO_USER_API_RNG [=y] && CRYPTO_DRBG [=y] -# Location: -# -> Cryptographic API (CRYPTO [=y]) -# -> User-space interface for random number generator algorithms (CRYPTO_USER_API_RNG [=y]) -# -# -# -# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set -- GitLab

13 21

[OS-BUILD PATCH] [redhat] New configs in drivers/net/can
by GitLab Bridge on behalf of jeremycline 14 Apr '21

14 Apr '21

4 5

[OS-BUILD PATCH] [redhat] New configs in fs/fuse
by GitLab Bridge on behalf of jeremycline 14 Apr '21

14 Apr '21

4 4

[OS-BUILD PATCH] [redhat] New configs in drivers/thunderbolt
by GitLab Bridge on behalf of jeremycline 12 Apr '21

12 Apr '21

2 1

[OS-BUILD PATCH] redhat/Makefile.common: Fix 'fatal: Not a valid object name master' error
by GitLab Bridge on behalf of prarit 06 Apr '21

06 Apr '21

From: Prarit Bhargava <prarit(a)redhat.com> Hey everyone, I spent 5-10 mins looking at the 'fatal: Not a valid object name master' error this morning. It comes from the redhat/Makefile.common:45 MERGE_BASE:=$(shell git merge-base HEAD master) There is no master branch so 'git merge-base HEAD master' returns an error with message 'fatal: Not a valid object name master'. If I add a Makefile target to dump the MERGE_BASE, TAG, and SNAPSHOT variables I get MERGE_BASE= TAG=v5.8-rc7-1028-g305981a20220 SNAPSHOT=1 I thought about changing the MERGE_BASE value to MERGE_BASE:=$(shell git merge-base HEAD master >& /dev/null && git merge-base HEAD master || git merge-base HEAD upstream/master) but that seems really clunky. Anyone have a better idea? Maybe it should only be MERGE_BASE:$(git merge-base HEAD upstream/master) ? In any case, after changing the MERGE_BASE line in Makefile.common, and dumping the values the 'fatal' error no longer occurs and MERGE_BASE is set correctly: MERGE_BASE=d3590ebf6f91350192737dd1d1b219c05277f067 TAG=v5.8-rc7-39-gd3590ebf6f91 SNAPSHOT=1 P. ---8<---- Executing some redhat/Makefile targets results in a 'fatal: Not a valid object name master' error. This occurs because MERGE_BASE is calculated against the master branch which may not exist. Check to see if master branch exists and if it doesn't use upstream/master instead. Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> --- redhat/Makefile.common | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/redhat/Makefile.common b/redhat/Makefile.common index 6d048415ba6d..e67f2c9dec50 100644 --- a/redhat/Makefile.common +++ b/redhat/Makefile.common @@ -41,8 +41,7 @@ else VERSION_ON_UPSTREAM:=0 endif ifeq ($(VERSION_ON_UPSTREAM),1) - # master is expected to track mainline. - MERGE_BASE:=$(shell git merge-base HEAD master) + MERGE_BASE:=$(shell git merge-base HEAD master >& /dev/null && git merge-base HEAD master || git merge-base HEAD upstream/master) TAG:=$(shell git describe $(MERGE_BASE)) # a snapshot off of a tagged git is of the form [tag]-[cnt]-g[hash] SNAPSHOT:=$(shell echo $(TAG) | grep -c '\-g') -- GitLab

3 4

[OS-BUILD PATCH] docs: Update docs to reflect newer workflow.
by GitLab Bridge on behalf of dzickusrh 02 Apr '21

02 Apr '21

From: Don Zickus <dzickus(a)redhat.com> The workflow has recently changed such that all development is done on the 'os-build' branch. Update the docs to show how easy it is to make a change, commit it, generate the srpm and upload it to koji. Also add it a build dep for making a srpm: patchutils (for filterdiff). Cc: Bastien Nocera <bnocera(a)redhat.com> Cc: Prarit Bhargava <prarit(a)redhat.com> Cc: Justin Forbes <jforbes(a)redhat.com> Signed-off-by: Don Zickus <dzickus(a)redhat.com> --- redhat/docs/index.rst | 16 +++++----------- redhat/docs/repository-layout.rst | 7 ------- redhat/docs/submitting-contributions.rst | 4 ++-- 3 files changed, 7 insertions(+), 20 deletions(-) diff --git a/redhat/docs/index.rst b/redhat/docs/index.rst index 951845cc7be3..b451b9ba49ca 100644 --- a/redhat/docs/index.rst +++ b/redhat/docs/index.rst @@ -36,8 +36,8 @@ Once GitLab finishes forking the repository (this can take a while): git remote add -f upstream git@gitlab.com:cki-project/kernel-ark.git # Install build dependencies - sudo dnf install -y make gcc flex bison bzip2 rpm-build - git checkout upstream/ark-latest + sudo dnf install -y make gcc flex bison bzip2 rpm-build patchutils + git checkout upstream/os-build # If you're on Fedora, you need to run: # ln -s /usr/bin/python3 /usr/libexec/platform-python make dist-srpm @@ -48,18 +48,11 @@ Building an SRPM ---------------- The configuration and build scripts are in the ``os-build`` branch and -are regularly updated to work with Linus's master branch. To build an -SRPM, start by checking out the source tree you'd like to build. In this -example, we'll assume that is Linus's master branch, but it could just -as easily be Fedora's ``ark-patches`` branch (Linus's tree + Fedora -patches) , a sub-system maintainer's tree, or your own creation. +are regularly updated to work with Linus's master branch. :: - git checkout linus/master - git merge -m "Merge branch 'os-build'" os-build - # Fedora carries a patch to alter this setting, so we need to change the configuration to build a vanilla tree. - # If you're targeting RHEL and have brew/rhpkg installed, use "make DIST=.elrdy dist-srpm" instead + git checkout upstream/os-build make dist-srpm You can now build the SRPM however you like: @@ -70,6 +63,7 @@ You can now build the SRPM however you like: mock redhat/rpm/SRPMS/kernel*src.rpm # Build the SRPM in Fedora's Koji koji build --scratch rawhide redhat/rpm/SRPMS/kernel*src.rpm + koji build --scratch eln redhat/rpm/SRPMS/kernel*src.rpm Want to add a patch? Just git-cherry-pick it or apply it with git-am and re-run ``make dist-srpm``. Change configurations in ``redhat/configs/`` diff --git a/redhat/docs/repository-layout.rst b/redhat/docs/repository-layout.rst index 5f6dcb08a1bd..851a2c5d715b 100644 --- a/redhat/docs/repository-layout.rst +++ b/redhat/docs/repository-layout.rst @@ -63,13 +63,6 @@ along with the configuration and build scripts. They can be checked out and built into RPMs. The ``master`` branch points to the latest version of these branches. -rhpatches -~~~~~~~~~ - -This branch is no longer used. Previously, it held the Red Hat patches -for the kernel as a quilt series and remains for historical reasons. -Patch history up to v5.4 is available in this branch. - Tags ---- diff --git a/redhat/docs/submitting-contributions.rst b/redhat/docs/submitting-contributions.rst index 07b25852ec66..65895a9ce49b 100644 --- a/redhat/docs/submitting-contributions.rst +++ b/redhat/docs/submitting-contributions.rst @@ -39,8 +39,8 @@ Patches Quick start: 1. ``git fetch upstream`` -2. ``git checkout upstream/os-build && git checkout -b my-build-change`` -3. Make a change to a file or files in ``redhat/``. +2. ``git checkout -b my-build-change upstream/os-build`` +3. Make a change to a file. 4. Add your changes with ``git add -A``. 5. Commit your changes and write a nice commit message that explains the change: ``git commit -s``. -- GitLab

7 17

[OS-BUILD PATCH] [redhat] New configs in drivers/gpio
by GitLab Bridge on behalf of jeremycline 31 Mar '21

31 Mar '21

4 5

[OS-BUILD PATCH] [redhat] New configs in fs/Kconfig
by GitLab Bridge on behalf of jeremycline 29 Mar '21

29 Mar '21

4 3

[OS-BUILD PATCH] [redhat] New configs in arch/arm64
by GitLab Bridge on behalf of jeremycline 29 Mar '21

29 Mar '21

From: "CKI@GitLab" <cki-project(a)redhat.com> Hi, As part of the ongoing rebase effort, the following configuration options need to be reviewed. As a reminder, the ARK configuration flow involves moving unreviewed configuration options from the pending directory to the ark directory. In the diff below, options are removed from the pending directory and added to the ark hierarchy. The final options that need to be ACKed are the files that are being added to the ark hierarchy. If the value for a file that is added should be changed, please reply with a better option. CONFIG_ARM64_BTI: Branch Target Identification (part of the ARMv8.5 Extensions) provides a mechanism to limit the set of locations to which computed branch instructions such as BR or BLR can jump. To make use of BTI on CPUs that support it, say Y. BTI is intended to provide complementary protection to other control flow integrity protection mechanisms, such as the Pointer authentication mechanism provided as part of the ARMv8.3 Extensions. For this reason, it does not make sense to enable this option without also enabling support for pointer authentication. Thus, when enabling this option you should also select ARM64_PTR_AUTH=y. Userspace binaries must also be specifically compiled to make use of this mechanism. If you say N here or the hardware does not support BTI, such binaries can still run, but you get no additional enforcement of branch destinations. Symbol: ARM64_BTI [=y] Type : bool Defined at arch/arm64/Kconfig:1594 Prompt: Branch Target Identification support Location: -> Kernel Features -> ARMv8.5 architectural features --- Cc: Mark Salter <msalter(a)redhat.com> Signed-off-by: CKI@GitLab <cki-project(a)redhat.com> --- .../configs/common/generic/CONFIG_ARM64_BTI | 1 + .../pending-common/generic/CONFIG_ARM64_BTI | 31 ------------------- 2 files changed, 1 insertion(+), 31 deletions(-) create mode 100644 redhat/configs/common/generic/CONFIG_ARM64_BTI delete mode 100644 redhat/configs/pending-common/generic/CONFIG_ARM64_BTI diff --git a/redhat/configs/common/generic/CONFIG_ARM64_BTI b/redhat/configs/common/generic/CONFIG_ARM64_BTI new file mode 100644 index 000000000000..fb0274de0d49 --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_ARM64_BTI @@ -0,0 +1 @@ +CONFIG_ARM64_BTI=y diff --git a/redhat/configs/pending-common/generic/CONFIG_ARM64_BTI b/redhat/configs/pending-common/generic/CONFIG_ARM64_BTI deleted file mode 100644 index 5af4d535b648..000000000000 --- a/redhat/configs/pending-common/generic/CONFIG_ARM64_BTI +++ /dev/null @@ -1,31 +0,0 @@ -# CONFIG_ARM64_BTI: -# -# Branch Target Identification (part of the ARMv8.5 Extensions) -# provides a mechanism to limit the set of locations to which computed -# branch instructions such as BR or BLR can jump. -# -# To make use of BTI on CPUs that support it, say Y. -# -# BTI is intended to provide complementary protection to other control -# flow integrity protection mechanisms, such as the Pointer -# authentication mechanism provided as part of the ARMv8.3 Extensions. -# For this reason, it does not make sense to enable this option without -# also enabling support for pointer authentication. Thus, when -# enabling this option you should also select ARM64_PTR_AUTH=y. -# -# Userspace binaries must also be specifically compiled to make use of -# this mechanism. If you say N here or the hardware does not support -# BTI, such binaries can still run, but you get no additional -# enforcement of branch destinations. -# -# Symbol: ARM64_BTI [=y] -# Type : bool -# Defined at arch/arm64/Kconfig:1594 -# Prompt: Branch Target Identification support -# Location: -# -> Kernel Features -# -> ARMv8.5 architectural features -# -# -# -CONFIG_ARM64_BTI=y -- 2.26.2

4 3

[OS-BUILD PATCH] [redhat] New configs in drivers/watchdog
by GitLab Bridge on behalf of jeremycline 29 Mar '21

29 Mar '21

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel November 2020