From: Justin M. Forbes jforbes@fedoraproject.org
Change CRYPTO_CHACHA_S390 from m to y
Upstream commit 349d03ffd5f6 changed CRYPTO_CHACHA_S390 to select CRYPTO_LIB_CHACHA_GENERIC which we already have as built-in. To avoid mismatches, we need to move CRYPTO_CHACHA_S390 from module to built-in.
Signed-off-by: Justin M. Forbes jforbes@fedoraproject.org
diff --git a/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA_S390 b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA_S390 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA_S390 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_CHACHA_S390=y diff --git a/redhat/configs/common/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 b/redhat/configs/common/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 index blahblah..blahblah 100644 --- a/redhat/configs/common/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 +++ b/redhat/configs/common/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 @@ -1 +1 @@ -CONFIG_CRYPTO_CHACHA_S390=m +CONFIG_CRYPTO_CHACHA_S390=y diff --git a/redhat/configs/fedora/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 b/redhat/configs/fedora/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/fedora/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_CHACHA_S390=y diff --git a/redhat/configs/pending-ark/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 b/redhat/configs/pending-ark/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/pending-ark/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_CHACHA_S390=y
-- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9635173...
hi, Justin @jmflinuxtx ! thanks for this MR! i was waiting for the 349d03ffd5f6 to get to ARK to submit config changes and you were first. the MR is mostly fine, but i would add a couple of required changes:
``` redhat/configs/common/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA_S390 =y # we miss this now redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA20 DELETE # as we have the same in common/generic ```
i will be happy to approve and celebrate this MR with the above add-ons.
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9635517...
The pipelines were failing today due to something different (KASAN config for ppc). I already cleaned all of this up in pending yesterday to make pipelines work, and I have added the pending entry for KASAN ppc to make things work now. With this MR as is, there is only one entry for redhat/configs/common/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 `redhat/configs/common/generic/s390x/CONFIG_CRYPTO_CHACHA_S390 =y` and there is no need for a separate zfcpdump because it is already set to y. As for the CHACHA20 entry, it appears the a few CHACHA entries are duplicated in common and ARK, but for zfcpdump in particular, we do not even build that config in Fedora, so I am not too picky as to weather it ends in ark or common. I will take a look at cleaning those up next business day.
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9635636...
my apologies, i beg to differ:
1) !1832's failed pipeline (https://gitlab.com/redhat/red-hat-ci- tools/kernel/cki-public-pipelines/-/pipelines/550256134) states:
``` 00:10:20 Found CONFIG_CRYPTO_LIB_CHACHA=m after generation, had CONFIG_CRYPTO_LIB_CHACHA=y in Source tree 00:10:20 Found CONFIG_CRYPTO_LIB_CHACHA20POLY1305=m after generation, had CONFIG_CRYPTO_LIB_CHACHA20POLY1305=y in Source tree 00:10:20 Error: Mismatches found in configuration files for s390 rhel ```
so i believe this is an effect of the 349d03ffd5f6 merged.
2) AFAIU, we've always tried to have s390x/zfcpdump/ configs to be defined explicitly. in case for any reason s390x/ config is changed, we want s390x/zfcpdump/ to remain as it was. so i would insist for `common/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA_S390` to be present and set to `=y`.
3) yes, we do not build the config you've mentioned in Fedora. but ARK is not only Fedora, RHEL inherits its configs, and we need them there in ARK for later RHELs. so i would like to keep redhat/configs as clear and non- duplicated as possible.
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9635722...
1. Right, the pipelines fail, I have to manually fix this stuff up every time a new one appears. When it is fixed, there is no automated process to go and re-run failed pipelines. I do not usually rerun the pipelines, typically Patrick does, and not on weekends/holidays. As you can see, I have rerun !1832 pipeline for you and it passes now. It would have done the same yesterday.
2. I was not aware of that, it seems that new entries of zfcpdump are only added when they differ from s390x as there are about twice as many config entries for s390x compared to s390x/zfcpdump. If anyone wanted to change s390x back to =m for any reason, the config would fail and the MR would never get through without adding back an entry for zfcpdump, but as the entire flavor is a RHEL specific thing, I am happy to do whatever RHEL likes.
3. I do not disagree, it should be cleaned up. My point was ark is a fine location, as Fedora does not build those configs. Common is for things which are identical between Fedora and RHEL/ARK. The ark directory is for things that are only set that way in RHEL/ARK. There are probably a large number of configs that need to be cleaned up in a similar manner because for the first year+ of this workflow, all new RHEL entries were created in common instead of ark. That only changed a few months ago.
On weekends and holidays, I only check on things enough to make sure that they are not failing the merge or failing the configs so that people can continue to work if they wish to do so. A RHEL mismatch cleanup means I have to create an MR after I fix it in pending so it does not get lost or forgotten.
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9644461...
thanks, Justin @jmflinuxtx for a detailed explanation! 1) got it, thanks, i see the pipeline is green now. 2) thanks, it would be awesome. 3) indeed, the "ark is a fine location, as Fedora does not build those configs" point makes sense, thank you. err... i guess, this means we should leave the ARK config in place but remove a common one...? could you please do as you see fit?
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9663488...
2) ok, i was wrong here, we do not need `common/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA_S390` indeed, since we already have `common/generic/s390x/CONFIG_CRYPTO_CHACHA_S390`. please disregard my request.
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9663601...
3. indeed, the "ark is a fine location, as Fedora does not build those configs" point makes sense, thank you. i guess, this means we should leave the `ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA20` config in place but remove `common/generic/s390x/zfcpdump/CONFIG_CRYPTO_CHACHA20`? could you please do as you see fit?
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9710706...
As we get further in this release cycle, possibly around the rc6 time frame, I plan to do a rather large config cleanup provided I have the cycles to do so. We have a couple of years worth of RHEL entries generated in common with no regard to what the Fedora config might be, so I plan to move the ones which are not actually common into ark, and plan to move the zfcpdump configs at the same time.
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1834#note_9710840...
thanks, Justin. after reviewing configs re: this MR, i've found out that s390x/zfcpdump is sort of a mess indeed. i plan to suggest a separate (smaller) MR soon to brush up s390x/zfcpdump. probably, this could help you later in your bigger clean up. meanwhile, approving this one.
kernel@lists.fedoraproject.org