- Linux-stable-mirror - lists.linaro.org

Stable patches that don't apply to older kernels and how to get them

by David Sterba

Hi, would it be possible to have a git repository with all patches that are submitted to stable@ but don't apply directly? I get notified by mail, that's fine though it's not that convenient to see all the pending patches for backport to a given version. My proposal: - create a separate stable-unapplied git repository - if a patch does not apply to a given version, it's stored as-is to a directory of the base version (like 4.4) - once a fixed version is applied to stable-queue.git/released-4.4, the patch in the other repo is deleted I believe this can be highly automated and once implemented would not too much additional work to the stable workflow. I could possibly write a scraper of the mail archives to pick the patches and manage the repository but I think that a central repository could help other maintainers too or to spread the load to all interested developers. If something like that already exists, please let me know. Thanks.

6 years, 7 months

2
4
0 0

[PATCH v3] spi-nor: intel-spi: Avoid crossing 4K address boundary on read/write

by Sverdlin, Alexander (Nokia - DE/Ulm)

It was observed that reads crossing 4K address boundary are failing. This limitation is mentioned in Intel documents: Intel(R) 9 Series Chipset Family Platform Controller Hub (PCH) Datasheet: "5.26.3 Flash Access Program Register Access: * Program Register Accesses are not allowed to cross a 4 KB boundary..." Enhanced Serial Peripheral Interface (eSPI) Interface Base Specification (for Client and Server Platforms): "5.1.4 Address For other memory transactions, the address may start or end at any byte boundary. However, the address and payload length combination must not cross the naturally aligned address boundary of the corresponding Maximum Payload Size. It must not cross a 4 KB address boundary." Avoid this by splitting an operation crossing the boundary into two operations. Cc: stable(a)vger.kernel.org Reported-by: Romain Porte <romain.porte(a)nokia.com> Tested-by: Pascal Fabreges <pascal.fabreges(a)nokia.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> --- Changelog: v2: More macros! As suggested by Mika. v3: Actually compiled. Sorry Mika, the lines are really long now. drivers/mtd/spi-nor/intel-spi.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c index af0a220..d60cbf2 100644 --- a/drivers/mtd/spi-nor/intel-spi.c +++ b/drivers/mtd/spi-nor/intel-spi.c @@ -632,6 +632,10 @@ static ssize_t intel_spi_read(struct spi_nor *nor, loff_t from, size_t len, while (len > 0) { block_size = min_t(size_t, len, INTEL_SPI_FIFO_SZ); + /* Read cannot cross 4K boundary */ + block_size = min_t(loff_t, from + block_size, + round_up(from + 1, SZ_4K)) - from; + writel(from, ispi->base + FADDR); val = readl(ispi->base + HSFSTS_CTL); @@ -685,6 +689,10 @@ static ssize_t intel_spi_write(struct spi_nor *nor, loff_t to, size_t len, while (len > 0) { block_size = min_t(size_t, len, INTEL_SPI_FIFO_SZ); + /* Write cannot cross 4K boundary */ + block_size = min_t(loff_t, to + block_size, + round_up(to + 1, SZ_4K)) - to; + writel(to, ispi->base + FADDR); val = readl(ispi->base + HSFSTS_CTL); -- 2.4.6

6 years, 7 months

3
8
0 0

FAILED: patch "[PATCH] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1d1f898df6586c5ea9aeaf349f13089c6fa37903 Mon Sep 17 00:00:00 2001 From: "Zhang, Jun" <jun.zhang(a)intel.com> Date: Tue, 18 Dec 2018 06:55:01 -0800 Subject: [PATCH] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt The rcu_gp_kthread_wake() function is invoked when it might be necessary to wake the RCU grace-period kthread. Because self-wakeups are normally a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from this kthread, it naturally refuses to do the wakeup. Unfortunately, natural though it might be, this heuristic fails when rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler that interrupted the grace-period kthread just after the final check of the wait-event condition but just before the schedule() call. In this case, a wakeup is required, even though the call to rcu_gp_kthread_wake() is within the RCU grace-period kthread's context. Failing to provide this wakeup can result in grace periods failing to start, which in turn results in out-of-memory conditions. This race window is quite narrow, but it actually did happen during real testing. It would of course need to be fixed even if it was strictly theoretical in nature. This patch does not Cc stable because it does not apply cleanly to earlier kernel versions. Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread") Reported-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "Zhang, Jun" <jun.zhang(a)intel.com> Co-developed-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "xiao, jin" <jin.xiao(a)intel.com> Co-developed-by: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off: "Zhang, Jun" <jun.zhang(a)intel.com> Signed-off: "He, Bo" <bo.he(a)intel.com> Signed-off: "xiao, jin" <jin.xiao(a)intel.com> Signed-off: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off-by: "Zhang, Jun" <jun.zhang(a)intel.com> [ paulmck: Switch from !in_softirq() to "!in_interrupt() && !in_serving_softirq() to avoid redundant wakeups and to also handle the interrupt-handler scenario as well as the softirq-handler scenario that actually occurred in testing. ] Signed-off-by: Paul E. McKenney <paulmck(a)linux.ibm.com> Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX10… diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 9ceb93f848cd..21775eebb8f0 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1593,15 +1593,23 @@ static bool rcu_future_gp_cleanup(struct rcu_node *rnp) } /* - * Awaken the grace-period kthread. Don't do a self-awaken, and don't - * bother awakening when there is nothing for the grace-period kthread - * to do (as in several CPUs raced to awaken, and we lost), and finally - * don't try to awaken a kthread that has not yet been created. If - * all those checks are passed, track some debug information and awaken. + * Awaken the grace-period kthread. Don't do a self-awaken (unless in + * an interrupt or softirq handler), and don't bother awakening when there + * is nothing for the grace-period kthread to do (as in several CPUs raced + * to awaken, and we lost), and finally don't try to awaken a kthread that + * has not yet been created. If all those checks are passed, track some + * debug information and awaken. + * + * So why do the self-wakeup when in an interrupt or softirq handler + * in the grace-period kthread's context? Because the kthread might have + * been interrupted just as it was going to sleep, and just after the final + * pre-sleep check of the awaken condition. In this case, a wakeup really + * is required, and is therefore supplied. */ static void rcu_gp_kthread_wake(void) { - if (current == rcu_state.gp_kthread || + if ((current == rcu_state.gp_kthread && + !in_interrupt() && !in_serving_softirq()) || !READ_ONCE(rcu_state.gp_flags) || !rcu_state.gp_kthread) return;

6 years, 7 months

2
2
0 0

[PATCH] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt" failed to apply to 4.4 to 4.19

by He, Bo

The rcu_gp_kthread_wake() function is invoked when it might be necessary to wake the RCU grace-period kthread. Because self-wakeups are normally a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from this kthread, it naturally refuses to do the wakeup. Unfortunately, natural though it might be, this heuristic fails when rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler that interrupted the grace-period kthread just after the final check of the wait-event condition but just before the schedule() call. In this case, a wakeup is required, even though the call to rcu_gp_kthread_wake() is within the RCU grace-period kthread's context. Failing to provide this wakeup can result in grace periods failing to start, which in turn results in out-of-memory conditions. This race window is quite narrow, but it actually did happen during real testing. It would of course need to be fixed even if it was strictly theoretical in nature. [ backport for 4.4 to 4.19 commit 1d1f898df6586c5ea9aeaf349f13089c6fa37903 upstream. ] Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread") Reported-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "Zhang, Jun" <jun.zhang(a)intel.com> Co-developed-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "xiao, jin" <jin.xiao(a)intel.com> Co-developed-by: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off: "Zhang, Jun" <jun.zhang(a)intel.com> Signed-off: "He, Bo" <bo.he(a)intel.com> Signed-off: "xiao, jin" <jin.xiao(a)intel.com> Signed-off: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off-by: "Zhang, Jun" <jun.zhang(a)intel.com> [ paulmck: Switch from !in_softirq() to "!in_interrupt() && !in_serving_softirq() to avoid redundant wakeups and to also handle the interrupt-handler scenario as well as the softirq-handler scenario that actually occurred in testing. ] [ backport for 4.19 commit 1d1f898df6586c5ea9aeaf349f13089c6fa37903 upstream. ] Signed-off-by: Paul E. McKenney <paulmck(a)linux.ibm.com> Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX10… --- kernel/rcu/tree.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 15301ed19da6..f7e89c989df7 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1689,15 +1689,23 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) } /* - * Awaken the grace-period kthread for the specified flavor of RCU. - * Don't do a self-awaken, and don't bother awakening when there is - * nothing for the grace-period kthread to do (as in several CPUs - * raced to awaken, and we lost), and finally don't try to awaken - * a kthread that has not yet been created. + * Awaken the grace-period kthread. Don't do a self-awaken (unless in + * an interrupt or softirq handler), and don't bother awakening when there + * is nothing for the grace-period kthread to do (as in several CPUs raced + * to awaken, and we lost), and finally don't try to awaken a kthread that + * has not yet been created. If all those checks are passed, track some + * debug information and awaken. + * + * So why do the self-wakeup when in an interrupt or softirq handler + * in the grace-period kthread's context? Because the kthread might have + * been interrupted just as it was going to sleep, and just after the final + * pre-sleep check of the awaken condition. In this case, a wakeup really + * is required, and is therefore supplied. */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { - if (current == rsp->gp_kthread || + if ((current == rsp->gp_kthread && + !in_interrupt() && !in_serving_softirq()) || !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; -- 2.20.1 -----Original Message----- From: gregkh(a)linuxfoundation.org <gregkh(a)linuxfoundation.org> Sent: Thursday, March 21, 2019 1:43 AM To: Zhang, Jun <jun.zhang(a)intel.com>; He, Bo <bo.he(a)intel.com>; Bai, Jie A <jie.a.bai(a)intel.com>; Xiao, Jin <jin.xiao(a)intel.com>; paulmck(a)linux.ibm.com Cc: stable(a)vger.kernel.org Subject: FAILED: patch "[PATCH] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt" failed to apply to 4.14-stable tree The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1d1f898df6586c5ea9aeaf349f13089c6fa37903 Mon Sep 17 00:00:00 2001 From: "Zhang, Jun" <jun.zhang(a)intel.com> Date: Tue, 18 Dec 2018 06:55:01 -0800 Subject: [PATCH] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt The rcu_gp_kthread_wake() function is invoked when it might be necessary to wake the RCU grace-period kthread. Because self-wakeups are normally a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from this kthread, it naturally refuses to do the wakeup. Unfortunately, natural though it might be, this heuristic fails when rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler that interrupted the grace-period kthread just after the final check of the wait-event condition but just before the schedule() call. In this case, a wakeup is required, even though the call to rcu_gp_kthread_wake() is within the RCU grace-period kthread's context. Failing to provide this wakeup can result in grace periods failing to start, which in turn results in out-of-memory conditions. This race window is quite narrow, but it actually did happen during real testing. It would of course need to be fixed even if it was strictly theoretical in nature. This patch does not Cc stable because it does not apply cleanly to earlier kernel versions. Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread") Reported-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "Zhang, Jun" <jun.zhang(a)intel.com> Co-developed-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "xiao, jin" <jin.xiao(a)intel.com> Co-developed-by: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off: "Zhang, Jun" <jun.zhang(a)intel.com> Signed-off: "He, Bo" <bo.he(a)intel.com> Signed-off: "xiao, jin" <jin.xiao(a)intel.com> Signed-off: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off-by: "Zhang, Jun" <jun.zhang(a)intel.com> [ paulmck: Switch from !in_softirq() to "!in_interrupt() && !in_serving_softirq() to avoid redundant wakeups and to also handle the interrupt-handler scenario as well as the softirq-handler scenario that actually occurred in testing. ] Signed-off-by: Paul E. McKenney <paulmck(a)linux.ibm.com> Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX10… diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 9ceb93f848cd..21775eebb8f0 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1593,15 +1593,23 @@ static bool rcu_future_gp_cleanup(struct rcu_node *rnp) } /* - * Awaken the grace-period kthread. Don't do a self-awaken, and don't - * bother awakening when there is nothing for the grace-period kthread - * to do (as in several CPUs raced to awaken, and we lost), and finally - * don't try to awaken a kthread that has not yet been created. If - * all those checks are passed, track some debug information and awaken. + * Awaken the grace-period kthread. Don't do a self-awaken (unless in + * an interrupt or softirq handler), and don't bother awakening when + there + * is nothing for the grace-period kthread to do (as in several CPUs + raced + * to awaken, and we lost), and finally don't try to awaken a kthread + that + * has not yet been created. If all those checks are passed, track + some + * debug information and awaken. + * + * So why do the self-wakeup when in an interrupt or softirq handler + * in the grace-period kthread's context? Because the kthread might + have + * been interrupted just as it was going to sleep, and just after the + final + * pre-sleep check of the awaken condition. In this case, a wakeup + really + * is required, and is therefore supplied. */ static void rcu_gp_kthread_wake(void) { - if (current == rcu_state.gp_kthread || + if ((current == rcu_state.gp_kthread && + !in_interrupt() && !in_serving_softirq()) || !READ_ONCE(rcu_state.gp_flags) || !rcu_state.gp_kthread) return;

6 years, 7 months

1
0
0 0

✅ PASS: Stable queue: queue-5.0

by CKI Project

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 449959917f0c - Linux 5.0.3 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. 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 `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 449959917f0c - Linux 5.0.3 We then merged the patchset with `git am`: 9p-use-inode-i_lock-to-protect-i_size_write-under-32-bit.patch 9p-net-fix-memory-leak-in-p9_client_create.patch asoc-fsl_esai-fix-register-setting-issue-in-right_j-mode.patch asoc-codecs-pcm186x-fix-wrong-usage-of-declare_tlv_db_scale.patch asoc-codecs-pcm186x-fix-energysense-sleep-bit.patch iio-adc-exynos-adc-fix-null-pointer-exception-on-unbind.patch iio-adc-exynos-adc-use-proper-number-of-channels-for-exynos4x12.patch mei-hbm-clean-the-feature-flags-on-link-reset.patch mei-bus-move-hw-module-get-put-to-probe-release.patch stm-class-prevent-division-by-zero.patch stm-class-fix-an-endless-loop-in-channel-allocation.patch crypto-caam-fix-hash-context-dma-unmap-size.patch crypto-ccree-fix-missing-break-in-switch-statement.patch crypto-caam-fixed-handling-of-sg-list.patch crypto-caam-fix-dma-mapping-of-stack-memory.patch crypto-ccree-fix-free-of-unallocated-mlli-buffer.patch crypto-ccree-unmap-buffer-before-copying-iv.patch crypto-ccree-don-t-copy-zero-size-ciphertext.patch crypto-cfb-add-missing-chunksize-property.patch crypto-cfb-remove-bogus-memcpy-with-src-dest.patch crypto-ofb-fix-handling-partial-blocks-and-make-thread-safe.patch crypto-ahash-fix-another-early-termination-in-hash-walk.patch crypto-rockchip-fix-scatterlist-nents-error.patch crypto-rockchip-update-new-iv-to-device-in-multiple-operations.patch dax-flush-partial-pmds-correctly.patch nfit-fix-nfit_intel_shutdown_status-command-submission.patch nfit-acpi_nfit_ctl-check-out_obj-type-in-the-right-place.patch acpi-nfit-fix-bus-command-validation.patch nfit-ars-attempt-a-short-ars-whenever-the-ars-state-is-idle-at-boot.patch nfit-ars-attempt-short-ars-even-in-the-no_init_ars-case.patch libnvdimm-label-clear-updating-flag-after-label-set-update.patch libnvdimm-pfn-fix-over-trim-in-trim_pfn_device.patch libnvdimm-pmem-honor-force_raw-for-legacy-pmem-regions.patch libnvdimm-fix-altmap-reservation-size-calculation.patch fix-cgroup_do_mount-handling-of-failure-exits.patch crypto-aead-set-crypto_tfm_need_key-if-setkey-fails.patch crypto-aegis-fix-handling-chunked-inputs.patch crypto-arm-crct10dif-revert-to-c-code-for-short-inputs.patch crypto-arm64-aes-neonbs-fix-returning-final-keystream-block.patch crypto-arm64-crct10dif-revert-to-c-code-for-short-inputs.patch crypto-hash-set-crypto_tfm_need_key-if-setkey-fails.patch crypto-morus-fix-handling-chunked-inputs.patch crypto-pcbc-remove-bogus-memcpy-s-with-src-dest.patch crypto-skcipher-set-crypto_tfm_need_key-if-setkey-fails.patch crypto-testmgr-skip-crc32c-context-test-for-ahash-algorithms.patch crypto-x86-aegis-fix-handling-chunked-inputs-and-may_sleep.patch crypto-x86-aesni-gcm-fix-crash-on-empty-plaintext.patch crypto-x86-morus-fix-handling-chunked-inputs-and-may_sleep.patch crypto-arm64-aes-ccm-fix-logical-bug-in-aad-mac-handling.patch crypto-arm64-aes-ccm-fix-bugs-in-non-neon-fallback-routine.patch cifs-fix-leaking-locked-vfs-cache-pages-in-writeback-retry.patch cifs-do-not-reset-lease-state-to-none-on-lease-break.patch cifs-do-not-skip-smb2-message-ids-on-send-failures.patch cifs-fix-read-after-write-for-files-with-read-caching.patch smb3-make-default-i-o-size-for-smb3-mounts-larger.patch tracing-use-strncpy-instead-of-memcpy-for-string-keys-in-hist-triggers.patch tracing-do-not-free-iter-trace-in-fail-path-of-tracing_open_pipe.patch tracing-perf-use-strndup_user-instead-of-buggy-open-coded-version.patch vmw_balloon-release-lock-on-error-in-vmballoon_reset.patch xen-fix-dom0-boot-on-huge-systems.patch acpi-device_sysfs-avoid-of-modalias-creation-for-removed-device.patch Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/19c5a0a4edae6793e2734d5073… ppc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/6dec1d61dd2cf1ec182a2dd390… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/f653b25aafef611a27bded2432e… Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: ✅ Boot test [0] ✅ LTP lite - release 20190115 [1] ✅ Loopdev Sanity [2] ✅ xfstests: xfs [3] ✅ AMTU (Abstract Machine Test Utility) [4] 🚧 ✅ audit: audit testsuite test [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ httpd: php sanity [7] 🚧 ✅ iotop: sanity [8] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport 🚧 ✅ tuned: tune-processes-through-perf [9] ✅ Usex - version 1.9-29 [10] ppc64le: ✅ Boot test [0] ✅ LTP lite - release 20190115 [1] ✅ Loopdev Sanity [2] ✅ xfstests: xfs [3] ✅ AMTU (Abstract Machine Test Utility) [4] 🚧 ✅ audit: audit testsuite test [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ httpd: php sanity [7] 🚧 ✅ iotop: sanity [8] 🚧 ✅ tuned: tune-processes-through-perf [9] ✅ Usex - version 1.9-29 [10] x86_64: ✅ Boot test [0] ✅ LTP lite - release 20190115 [1] ✅ Loopdev Sanity [2] ✅ xfstests: xfs [3] ✅ AMTU (Abstract Machine Test Utility) [4] 🚧 ✅ audit: audit testsuite test [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ httpd: php sanity [7] 🚧 ✅ iotop: sanity [8] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport 🚧 ✅ tuned: tune-processes-through-perf [9] ✅ Usex - version 1.9-29 [10] Test source: [0]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [1]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [2]: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [10]: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… Waived tests (marked with 🚧) ----------------------------- This test run included waived tests. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed.

6 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt" failed to apply to 5.0-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.0-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1d1f898df6586c5ea9aeaf349f13089c6fa37903 Mon Sep 17 00:00:00 2001 From: "Zhang, Jun" <jun.zhang(a)intel.com> Date: Tue, 18 Dec 2018 06:55:01 -0800 Subject: [PATCH] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt The rcu_gp_kthread_wake() function is invoked when it might be necessary to wake the RCU grace-period kthread. Because self-wakeups are normally a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from this kthread, it naturally refuses to do the wakeup. Unfortunately, natural though it might be, this heuristic fails when rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler that interrupted the grace-period kthread just after the final check of the wait-event condition but just before the schedule() call. In this case, a wakeup is required, even though the call to rcu_gp_kthread_wake() is within the RCU grace-period kthread's context. Failing to provide this wakeup can result in grace periods failing to start, which in turn results in out-of-memory conditions. This race window is quite narrow, but it actually did happen during real testing. It would of course need to be fixed even if it was strictly theoretical in nature. This patch does not Cc stable because it does not apply cleanly to earlier kernel versions. Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread") Reported-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "Zhang, Jun" <jun.zhang(a)intel.com> Co-developed-by: "He, Bo" <bo.he(a)intel.com> Co-developed-by: "xiao, jin" <jin.xiao(a)intel.com> Co-developed-by: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off: "Zhang, Jun" <jun.zhang(a)intel.com> Signed-off: "He, Bo" <bo.he(a)intel.com> Signed-off: "xiao, jin" <jin.xiao(a)intel.com> Signed-off: Bai, Jie A <jie.a.bai(a)intel.com> Signed-off-by: "Zhang, Jun" <jun.zhang(a)intel.com> [ paulmck: Switch from !in_softirq() to "!in_interrupt() && !in_serving_softirq() to avoid redundant wakeups and to also handle the interrupt-handler scenario as well as the softirq-handler scenario that actually occurred in testing. ] Signed-off-by: Paul E. McKenney <paulmck(a)linux.ibm.com> Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX10… diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 9ceb93f848cd..21775eebb8f0 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1593,15 +1593,23 @@ static bool rcu_future_gp_cleanup(struct rcu_node *rnp) } /* - * Awaken the grace-period kthread. Don't do a self-awaken, and don't - * bother awakening when there is nothing for the grace-period kthread - * to do (as in several CPUs raced to awaken, and we lost), and finally - * don't try to awaken a kthread that has not yet been created. If - * all those checks are passed, track some debug information and awaken. + * Awaken the grace-period kthread. Don't do a self-awaken (unless in + * an interrupt or softirq handler), and don't bother awakening when there + * is nothing for the grace-period kthread to do (as in several CPUs raced + * to awaken, and we lost), and finally don't try to awaken a kthread that + * has not yet been created. If all those checks are passed, track some + * debug information and awaken. + * + * So why do the self-wakeup when in an interrupt or softirq handler + * in the grace-period kthread's context? Because the kthread might have + * been interrupted just as it was going to sleep, and just after the final + * pre-sleep check of the awaken condition. In this case, a wakeup really + * is required, and is therefore supplied. */ static void rcu_gp_kthread_wake(void) { - if (current == rcu_state.gp_kthread || + if ((current == rcu_state.gp_kthread && + !in_interrupt() && !in_serving_softirq()) || !READ_ONCE(rcu_state.gp_flags) || !rcu_state.gp_kthread) return;

6 years, 7 months

4
5
0 0

WTF: patch "[PATCH] tpm: Fix some name collisions with drivers/char/tpm.h" was seriously submitted to be applied to the 5.0-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 5.0-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8ab547a2dcfac6ec184a5e036e1093eb3f7a215c Mon Sep 17 00:00:00 2001 From: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Date: Tue, 5 Feb 2019 11:14:00 +0200 Subject: [PATCH] tpm: Fix some name collisions with drivers/char/tpm.h * Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to ST33ZP24_BUFSIZE. * Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to TPM_I2C_INFINEON_BUFSIZE. * Rename TPM_RETRY in tpm_i2c_nuvoton to TPM_I2C_RETRIES. * Remove TPM_HEADER_SIZE from tpm_i2c_nuvoton. Cc: stable(a)vger.kernel.org Fixes: bf38b8710892 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)") Fixes: aad628c1d91a ("char/tpm: Add new driver for Infineon I2C TIS TPM") Fixes: 32d33b29ba07 ("TPM: Retry SaveState command in suspend path") Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> diff --git a/drivers/char/tpm/st33zp24/i2c.c b/drivers/char/tpm/st33zp24/i2c.c index be5d1abd3e8e..8390c5b54c3b 100644 --- a/drivers/char/tpm/st33zp24/i2c.c +++ b/drivers/char/tpm/st33zp24/i2c.c @@ -33,7 +33,7 @@ struct st33zp24_i2c_phy { struct i2c_client *client; - u8 buf[TPM_BUFSIZE + 1]; + u8 buf[ST33ZP24_BUFSIZE + 1]; int io_lpcpd; }; diff --git a/drivers/char/tpm/st33zp24/spi.c b/drivers/char/tpm/st33zp24/spi.c index d7909ab287a8..ff019a1e3c68 100644 --- a/drivers/char/tpm/st33zp24/spi.c +++ b/drivers/char/tpm/st33zp24/spi.c @@ -63,7 +63,7 @@ * some latency byte before the answer is available (max 15). * We have 2048 + 1024 + 15. */ -#define ST33ZP24_SPI_BUFFER_SIZE (TPM_BUFSIZE + (TPM_BUFSIZE / 2) +\ +#define ST33ZP24_SPI_BUFFER_SIZE (ST33ZP24_BUFSIZE + (ST33ZP24_BUFSIZE / 2) +\ MAX_SPI_LATENCY) diff --git a/drivers/char/tpm/st33zp24/st33zp24.h b/drivers/char/tpm/st33zp24/st33zp24.h index 6f4a4198af6a..20da0a84988d 100644 --- a/drivers/char/tpm/st33zp24/st33zp24.h +++ b/drivers/char/tpm/st33zp24/st33zp24.h @@ -18,8 +18,8 @@ #ifndef __LOCAL_ST33ZP24_H__ #define __LOCAL_ST33ZP24_H__ -#define TPM_WRITE_DIRECTION 0x80 -#define TPM_BUFSIZE 2048 +#define TPM_WRITE_DIRECTION 0x80 +#define ST33ZP24_BUFSIZE 2048 struct st33zp24_dev { struct tpm_chip *chip; diff --git a/drivers/char/tpm/tpm_i2c_infineon.c b/drivers/char/tpm/tpm_i2c_infineon.c index 9086edc9066b..3b490d9d90e7 100644 --- a/drivers/char/tpm/tpm_i2c_infineon.c +++ b/drivers/char/tpm/tpm_i2c_infineon.c @@ -26,8 +26,7 @@ #include <linux/wait.h> #include "tpm.h" -/* max. buffer size supported by our TPM */ -#define TPM_BUFSIZE 1260 +#define TPM_I2C_INFINEON_BUFSIZE 1260 /* max. number of iterations after I2C NAK */ #define MAX_COUNT 3 @@ -63,11 +62,13 @@ enum i2c_chip_type { UNKNOWN, }; -/* Structure to store I2C TPM specific stuff */ struct tpm_inf_dev { struct i2c_client *client; int locality; - u8 buf[TPM_BUFSIZE + sizeof(u8)]; /* max. buffer size + addr */ + /* In addition to the data itself, the buffer must fit the 7-bit I2C + * address and the direction bit. + */ + u8 buf[TPM_I2C_INFINEON_BUFSIZE + 1]; struct tpm_chip *chip; enum i2c_chip_type chip_type; unsigned int adapterlimit; @@ -219,7 +220,7 @@ static int iic_tpm_write_generic(u8 addr, u8 *buffer, size_t len, .buf = tpm_dev.buf }; - if (len > TPM_BUFSIZE) + if (len > TPM_I2C_INFINEON_BUFSIZE) return -EINVAL; if (!tpm_dev.client->adapter->algo->master_xfer) @@ -527,8 +528,8 @@ static int tpm_tis_i2c_send(struct tpm_chip *chip, u8 *buf, size_t len) u8 retries = 0; u8 sts = TPM_STS_GO; - if (len > TPM_BUFSIZE) - return -E2BIG; /* command is too long for our tpm, sorry */ + if (len > TPM_I2C_INFINEON_BUFSIZE) + return -E2BIG; if (request_locality(chip, 0) < 0) return -EBUSY; diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c b/drivers/char/tpm/tpm_i2c_nuvoton.c index 217f7f1cbde8..5700cc2ddee1 100644 --- a/drivers/char/tpm/tpm_i2c_nuvoton.c +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c @@ -35,14 +35,12 @@ #include "tpm.h" /* I2C interface offsets */ -#define TPM_STS 0x00 -#define TPM_BURST_COUNT 0x01 -#define TPM_DATA_FIFO_W 0x20 -#define TPM_DATA_FIFO_R 0x40 -#define TPM_VID_DID_RID 0x60 -/* TPM command header size */ -#define TPM_HEADER_SIZE 10 -#define TPM_RETRY 5 +#define TPM_STS 0x00 +#define TPM_BURST_COUNT 0x01 +#define TPM_DATA_FIFO_W 0x20 +#define TPM_DATA_FIFO_R 0x40 +#define TPM_VID_DID_RID 0x60 +#define TPM_I2C_RETRIES 5 /* * I2C bus device maximum buffer size w/o counting I2C address or command * i.e. max size required for I2C write is 34 = addr, command, 32 bytes data @@ -292,7 +290,7 @@ static int i2c_nuvoton_recv(struct tpm_chip *chip, u8 *buf, size_t count) dev_err(dev, "%s() count < header size\n", __func__); return -EIO; } - for (retries = 0; retries < TPM_RETRY; retries++) { + for (retries = 0; retries < TPM_I2C_RETRIES; retries++) { if (retries > 0) { /* if this is not the first trial, set responseRetry */ i2c_nuvoton_write_status(client,

6 years, 7 months

2
1
0 0

Build error in 4.14 stable-queue

by Eric Biggers

queue-4.14/clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.patch causes a build error: CC drivers/clocksource/arm_arch_timer.o drivers/clocksource/arm_arch_timer.c:433:4: error: 'const struct arch_timer_erratum_workaround' has no member named 'read_cntpct_el0'; did you mean 'read_cntvct_el0'? .read_cntpct_el0 = sun50i_a64_read_cntpct_el0, ^~~~~~~~~~~~~~~ read_cntvct_el0 make[1]: *** [scripts/Makefile.build:327: drivers/clocksource/arm_arch_timer.o] Error 1 make: *** [Makefile:1686: drivers/clocksource/arm_arch_timer.o] Error 2

6 years, 7 months

4
4
0 0

FAILED: patch "[PATCH] NFS: Fix I/O request leakages" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f57dcf4c72113c745d83f1c65f7291299f65c14f Mon Sep 17 00:00:00 2001 From: Trond Myklebust <trond.myklebust(a)hammerspace.com> Date: Wed, 13 Feb 2019 09:21:38 -0500 Subject: [PATCH] NFS: Fix I/O request leakages When we fail to add the request to the I/O queue, we currently leave it to the caller to free the failed request. However since some of the requests that fail are actually created by nfs_pageio_add_request() itself, and are not passed back the caller, this leads to a leakage issue, which can again cause page locks to leak. This commit addresses the leakage by freeing the created requests on error, using desc->pg_completion_ops->error_cleanup() Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com> Fixes: a7d42ddb30997 ("nfs: add mirroring support to pgio layer") Cc: stable(a)vger.kernel.org # v4.0: c18b96a1b862: nfs: clean up rest of reqs Cc: stable(a)vger.kernel.org # v4.0: d600ad1f2bdb: NFS41: pop some layoutget Cc: stable(a)vger.kernel.org # v4.0+ diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c index e54d899c1848..301880a3ad8e 100644 --- a/fs/nfs/pagelist.c +++ b/fs/nfs/pagelist.c @@ -988,6 +988,17 @@ static void nfs_pageio_doio(struct nfs_pageio_descriptor *desc) } } +static void +nfs_pageio_cleanup_request(struct nfs_pageio_descriptor *desc, + struct nfs_page *req) +{ + LIST_HEAD(head); + + nfs_list_remove_request(req); + nfs_list_add_request(req, &head); + desc->pg_completion_ops->error_cleanup(&head); +} + /** * nfs_pageio_add_request - Attempt to coalesce a request into a page list. * @desc: destination io descriptor @@ -1025,10 +1036,8 @@ static int __nfs_pageio_add_request(struct nfs_pageio_descriptor *desc, nfs_page_group_unlock(req); desc->pg_moreio = 1; nfs_pageio_doio(desc); - if (desc->pg_error < 0) - return 0; - if (mirror->pg_recoalesce) - return 0; + if (desc->pg_error < 0 || mirror->pg_recoalesce) + goto out_cleanup_subreq; /* retry add_request for this subreq */ nfs_page_group_lock(req); continue; @@ -1061,6 +1070,10 @@ static int __nfs_pageio_add_request(struct nfs_pageio_descriptor *desc, desc->pg_error = PTR_ERR(subreq); nfs_page_group_unlock(req); return 0; +out_cleanup_subreq: + if (req != subreq) + nfs_pageio_cleanup_request(desc, subreq); + return 0; } static int nfs_do_recoalesce(struct nfs_pageio_descriptor *desc) @@ -1168,11 +1181,14 @@ int nfs_pageio_add_request(struct nfs_pageio_descriptor *desc, if (nfs_pgio_has_mirroring(desc)) desc->pg_mirror_idx = midx; if (!nfs_pageio_add_request_mirror(desc, dupreq)) - goto out_failed; + goto out_cleanup_subreq; } return 1; +out_cleanup_subreq: + if (req != dupreq) + nfs_pageio_cleanup_request(desc, dupreq); out_failed: nfs_pageio_error_cleanup(desc); return 0;

6 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] nfs: clean up rest of reqs when failing to add one" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From c18b96a1b8629db8cf5ac9f8974ccb4abcc209ab Mon Sep 17 00:00:00 2001 From: Peng Tao <tao.peng(a)primarydata.com> Date: Sat, 5 Dec 2015 01:59:56 +0800 Subject: [PATCH] nfs: clean up rest of reqs when failing to add one If we fail to set up things before sending anything over wire, we need to clean up the reqs that are still attached to the IO descriptor. Signed-off-by: Peng Tao <tao.peng(a)primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c index 728f65884cea..13faa303eb3b 100644 --- a/fs/nfs/pagelist.c +++ b/fs/nfs/pagelist.c @@ -1126,6 +1126,7 @@ static int nfs_do_recoalesce(struct nfs_pageio_descriptor *desc) static int nfs_pageio_add_request_mirror(struct nfs_pageio_descriptor *desc, struct nfs_page *req) { + struct nfs_pgio_mirror *mirror = nfs_pgio_current_mirror(desc); int ret; do { @@ -1153,7 +1154,7 @@ int nfs_pageio_add_request(struct nfs_pageio_descriptor *desc, nfs_pageio_setup_mirroring(desc, req); if (desc->pg_error < 0) - return 0; + goto out_failed; for (midx = 0; midx < desc->pg_mirror_count; midx++) { if (midx) { @@ -1170,7 +1171,8 @@ int nfs_pageio_add_request(struct nfs_pageio_descriptor *desc, if (IS_ERR(dupreq)) { nfs_page_group_unlock(req); - return 0; + desc->pg_error = PTR_ERR(dupreq); + goto out_failed; } nfs_lock_request(dupreq); @@ -1183,10 +1185,19 @@ int nfs_pageio_add_request(struct nfs_pageio_descriptor *desc, if (nfs_pgio_has_mirroring(desc)) desc->pg_mirror_idx = midx; if (!nfs_pageio_add_request_mirror(desc, dupreq)) - return 0; + goto out_failed; } return 1; + +out_failed: + /* + * We might have failed before sending any reqs over wire. + * clean up rest of the reqs in mirror pg_list + */ + if (desc->pg_error) + desc->pg_completion_ops->error_cleanup(&mirror->pg_list); + return 0; } /*

6 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror