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

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: 8b298d3a0bd5 - Linux 5.0.7 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK 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: 8b298d3a0bd5 - Linux 5.0.7 We then merged the patchset with `git am`: drm-i915-gvt-do-not-let-pin-count-of-shadow-mm-go-ne.patch kbuild-pkg-use-f-srctree-makefile-to-recurse-to-top-.patch netfilter-nft_compat-use-.release_ops-and-remove-lis.patch netfilter-nf_tables-use-after-free-in-dynamic-operat.patch netfilter-nf_tables-add-missing-release_ops-in-error.patch hv_netvsc-fix-unwanted-wakeup-after-tx_disable.patch ibmvnic-fix-completion-structure-initialization.patch ip6_tunnel-match-to-arphrd_tunnel6-for-dev-type.patch ipv6-fix-dangling-pointer-when-ipv6-fragment.patch ipv6-sit-reset-ip-header-pointer-in-ipip6_rcv.patch kcm-switch-order-of-device-registration-to-fix-a-cra.patch net-ethtool-not-call-vzalloc-for-zero-sized-memory-r.patch net-gro-fix-gro-flush-when-receiving-a-gso-packet.patch net-mlx5-decrease-default-mr-cache-size.patch netns-provide-pure-entropy-for-net_hash_mix.patch net-rds-force-to-destroy-connection-if-t_sock-is-nul.patch net-sched-act_sample-fix-divide-by-zero-in-the-traff.patch net-sched-fix-get-helper-of-the-matchall-cls.patch openvswitch-fix-flow-actions-reallocation.patch qmi_wwan-add-olicard-600.patch r8169-disable-aspm-again.patch sctp-initialize-_pad-of-sockaddr_in-before-copying-t.patch tcp-ensure-dctcp-reacts-to-losses.patch tcp-fix-a-potential-null-pointer-dereference-in-tcp_.patch vrf-check-accept_source_route-on-the-original-netdev.patch net-mlx5e-fix-error-handling-when-refreshing-tirs.patch net-mlx5e-add-a-lock-on-tir-list.patch nfp-validate-the-return-code-from-dev_queue_xmit.patch nfp-disable-netpoll-on-representors.patch bnxt_en-improve-rx-consumer-index-validity-check.patch bnxt_en-reset-device-on-rx-buffer-errors.patch net-ip_gre-fix-possible-use-after-free-in-erspan_rcv.patch net-ip6_gre-fix-possible-use-after-free-in-ip6erspan.patch net-bridge-always-clear-mcast-matching-struct-on-rep.patch net-thunderx-fix-null-pointer-dereference-in-nicvf_o.patch net-vrf-fix-ping-failed-when-vrf-mtu-is-set-to-0.patch net-core-netif_receive_skb_list-unlist-skb-before-pa.patch r8169-disable-default-rx-interrupt-coalescing-on-rtl.patch net-mlx5-add-a-missing-check-on-idr_find-free-buf.patch net-mlx5e-update-xoff-formula.patch net-mlx5e-update-xon-formula.patch kbuild-clang-choose-gcc_toolchain_dir-not-on-ld.patch lib-string.c-implement-a-basic-bcmp.patch revert-clk-meson-clean-up-clock-registration.patch Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/kernel-stable_queue-aarch6… kernel build: https://artifacts.cki-project.org/builds/aarch64/kernel-stable_queue-aarch6… ppc64le: make options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable_queue-ppc64l… kernel build: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable_queue-ppc64l… x86_64: make options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/kernel-stable_queue-x86_64-… kernel build: https://artifacts.cki-project.org/builds/x86_64/kernel-stable_queue-x86_64-… Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: ✅ Boot test [0] ✅ LTP lite [1] ✅ AMTU (Abstract Machine Test Utility) [2] 🚧 ✅ audit: audit testsuite test [3] ✅ httpd: mod_ssl smoke sanity [4] ✅ httpd: php sanity [5] ✅ iotop: sanity [6] ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport ✅ tuned: tune-processes-through-perf [7] 🚧 ✅ stress: stress-ng [8] ppc64le: ✅ Boot test [0] ✅ LTP lite [1] ✅ AMTU (Abstract Machine Test Utility) [2] 🚧 ✅ audit: audit testsuite test [3] ✅ httpd: mod_ssl smoke sanity [4] ✅ httpd: php sanity [5] ✅ iotop: sanity [6] ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport 🚧 ✅ selinux-policy: serge-testsuite [9] ✅ tuned: tune-processes-through-perf [7] 🚧 ✅ stress: stress-ng [8] x86_64: ✅ Boot test [0] ✅ LTP lite [1] ✅ AMTU (Abstract Machine Test Utility) [2] 🚧 ✅ audit: audit testsuite test [3] ✅ httpd: mod_ssl smoke sanity [4] ✅ httpd: php sanity [5] ✅ iotop: sanity [6] ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport 🚧 ✅ selinux-policy: serge-testsuite [9] ✅ tuned: tune-processes-through-perf [7] 🚧 ✅ stress: stress-ng [8] 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#misc/amtu [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#stress/stres… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/packages/se… 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, 6 months

1
0
0 0

[PATCH 0/1] FSCTL write support

by Ronnie Sahlberg

Steve, This patch adds code to allow us to do fsctl passthrough for fsctl types that need to pass data to the server. This not only needs to pass the blob to the server but also need to decode the access-type part of the fsctl code and change the arguments to the CREATE accordingly. The values for the access are from wireshark traces of win16 -> win16. For now I only implement the special handling we need for FILE_READ_WRITE_ACCESS. We can add the others as needed and as we we discover them while adding new functions to smbinfo.

6 years, 6 months

4
4
0 0

[PATCH stable 5.0] Revert "clk: meson: clean-up clock registration"

by Neil Armstrong

This reverts commit 9b0f430450cf230e736bc40f95bf34fbdb99cead. This patch was not initially a fix and is dependent on other changes which are not fixes eithers. With this change, multiple Amlogic based boards fails to boot, as reported by kernelci. Cc: stable(a)vger.kernel.org # 5.0.7 Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- drivers/clk/meson/meson-aoclk.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/clk/meson/meson-aoclk.c b/drivers/clk/meson/meson-aoclk.c index 258c8d259ea1..f965845917e3 100644 --- a/drivers/clk/meson/meson-aoclk.c +++ b/drivers/clk/meson/meson-aoclk.c @@ -65,20 +65,15 @@ int meson_aoclkc_probe(struct platform_device *pdev) return ret; } - /* Populate regmap */ - for (clkid = 0; clkid < data->num_clks; clkid++) + /* + * Populate regmap and register all clks + */ + for (clkid = 0; clkid < data->num_clks; clkid++) { data->clks[clkid]->map = regmap; - /* Register all clks */ - for (clkid = 0; clkid < data->hw_data->num; clkid++) { - if (!data->hw_data->hws[clkid]) - continue; - ret = devm_clk_hw_register(dev, data->hw_data->hws[clkid]); - if (ret) { - dev_err(dev, "Clock registration failed\n"); + if (ret) return ret; - } } return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, -- 2.21.0

6 years, 6 months

3
2
0 0

[PATCH] perf/x86/intel/uncore: Handle invalid event coding for free-running counter

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> Counting with invalid event coding for free-running counter may cause OOPs, e.g. uncore_iio_free_running_0/event=1/. Current code only validate the event with free-running event format, event=0xff,umask=0xXY. Non-free-running event format never be checked for the PMU with free-running counters. Add generic hw_config() to check and reject the invalid event coding for free-running PMU. Fixes: 0f519f0352e3 ("perf/x86/intel/uncore: Support IIO free-running counters on SKX") Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/uncore.h | 10 ++++++++++ arch/x86/events/intel/uncore_snbep.c | 1 + 2 files changed, 11 insertions(+) diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h index 79eb2e2..28499e3 100644 --- a/arch/x86/events/intel/uncore.h +++ b/arch/x86/events/intel/uncore.h @@ -419,6 +419,16 @@ static inline bool is_freerunning_event(struct perf_event *event) (((cfg >> 8) & 0xff) >= UNCORE_FREERUNNING_UMASK_START); } +/* Check and reject invalid config */ +static inline int uncore_freerunning_hw_config(struct intel_uncore_box *box, + struct perf_event *event) +{ + if (is_freerunning_event(event)) + return 0; + + return -EINVAL; +} + static inline void uncore_disable_box(struct intel_uncore_box *box) { if (box->pmu->type->ops->disable_box) diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index b10e043..8e4e8e4 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -3585,6 +3585,7 @@ static struct uncore_event_desc skx_uncore_iio_freerunning_events[] = { static struct intel_uncore_ops skx_uncore_iio_freerunning_ops = { .read_counter = uncore_msr_read_counter, + .hw_config = uncore_freerunning_hw_config, }; static struct attribute *skx_uncore_iio_freerunning_formats_attr[] = { -- 2.7.4

6 years, 6 months

1
0
0 0

[PATCH 4.9 0/3] fanotify: Fix notification subsystem hang

by Matthew Ruffell

BugLink: https://bugs.launchpad.net/bugs/1775165 [Note to upstream] I understand that this patch is a little long for -stable, but this patch series fixes a real issue, seen by real users, is testable, and is made up from upstream commits. Please consider it. [Impact] When userspace tasks which are processing fanotify permission events act incorrectly, the fsnotify_mark_srcu SRCU is held indefinitely which causes the whole notification subsystem to hang. This has been seen in production, and it can also be seen when running the Linux Test Project testsuite, specifically fanotify07. [Fix] Instead of holding the SRCU lock while waiting for userspace to respond, which may never happen, or not in the order we are expecting, we drop the fsnotify_mark_srcu SRCU lock before waiting for userspace response, and then reacquire the lock again when userspace responds. The fixes are from a series of upstream commits: 05f0e38724e8449184acd8fbf0473ee5a07adc6c (cherry-pick) 9385a84d7e1f658bb2d96ab798393e4b16268aaa (backport) abc77577a669f424c5d0c185b9994f2621c52aa4 (backport) [Testcase] You can reproduce the problem pretty quickly with the Linux Test Project: Steps (with root): 1. sudo apt-get install git xfsprogs -y 2. git clone --depth=1 https://github.com/linux-test-project/ltp.git 3. cd ltp 4. make autotools 5. ./configure 6. make; make install 7. cd /opt/ltp 8. echo -e "fanotify07 fanotify07 \nfanotify08 fanotify08" > /tmp/jobs 9. ./runltp -f /tmp/jobs On a stock 4.9.168 kernel, the system will hang, and the testcase will look like: <<<test_start>>> tag=fanotify07 stime=1554326200 cmdline="fanotify07 " contacts="" analysis=exit <<<test_output>>> tst_test.c:1096: INFO: Timeout per run is 0h 05m 00s Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Cannot kill test processes! Congratulation, likely test hit a kernel bug. Exitting uncleanly... <<<execution_status>>> initiation_status="ok" duration=350 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Looking at dmesg, we see the following call stack [ 41.648244] LTP: starting fanotify07 (fanotify07 ) [ 242.729211] INFO: task fanotify07:1511 blocked for more than 120 seconds. [ 242.729257] Not tainted 4.9.168vanilla #1 [ 242.729281] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 242.729320] fanotify07 D 0 1511 1510 0x00000000 [ 242.729325] ffff92faf98a64c0 ffff92faf50f8000 ffff92faf19f2d00 ffff92faf989ad00 [ 242.729329] ffff92faffc19900 ffffb2f5c0cbbc70 ffffffffae8cf2c2 ffffb2f5c0cbbd60 [ 242.729333] 00e590a200000010 ffff92faffc19900 0000000000000046 7fffffffffffffff [ 242.729336] Call Trace: [ 242.729345] [<ffffffffae8cf2c2>] ? __schedule+0x242/0x700 [ 242.729348] [<ffffffffae8cf7ac>] schedule+0x2c/0x80 [ 242.729351] [<ffffffffae8d2e0b>] schedule_timeout+0x1fb/0x370 [ 242.729355] [<ffffffffae0fcaae>] ? add_timer+0x11e/0x290 [ 242.729358] [<ffffffffae8d021a>] wait_for_completion+0xba/0x140 [ 242.729361] [<ffffffffae0b4ac0>] ? wake_up_q+0x80/0x80 [ 242.729364] [<ffffffffae0f1a44>] __synchronize_srcu+0xf4/0x140 [ 242.729367] [<ffffffffae0f08a0>] ? trace_raw_output_rcu_utilization+0x60/0x60 [ 242.729370] [<ffffffffae0f1ab3>] synchronize_srcu+0x23/0x40 [ 242.729374] [<ffffffffae283bab>] fsnotify_mark_destroy_list+0x7b/0xe0 [ 242.729377] [<ffffffffae282d7f>] fsnotify_destroy_group+0x1f/0x50 [ 242.729380] [<ffffffffae285e66>] fanotify_release+0xd6/0x140 [ 242.729384] [<ffffffffae23e70a>] __fput+0xea/0x230 [ 242.729386] [<ffffffffae23e88e>] ____fput+0xe/0x10 [ 242.729390] [<ffffffffae0a6f2c>] task_work_run+0x7c/0xa0 [ 242.729394] [<ffffffffae003753>] exit_to_usermode_loop+0x93/0xa0 [ 242.729397] [<ffffffffae003bc7>] do_syscall_64+0xc7/0xe0 [ 242.729400] [<ffffffffae8d448e>] entry_SYSCALL_64_after_swapgs+0x58/0xc6 Note this call stack is the same as the one for 4.4, but some function names have changed due to the two commits already included in 4.9. On a patched kernel, the test will pass successfully, and there will be no messages in dmesg. [Regression Potential] This makes modifications to how locking is performed in fsnotify / fanotify and there may be some cause for regression. Running all fanotify Linux Test Project tests shows that there are no extra failures caused by the patches, and instead fewer failures are seen due to the bugfix. Running the entire Linux Test Project testsuite actually works and runs to completion, something which doesn't happen in a unpatched kernel since it will hang on the fanotify07 test. The patches are taken from upstream, and all necessary commits have been taken into account, so I am happy with the potential risks and that testing has been completed. Jan Kara (3): fsnotify: Provide framework for dropping SRCU lock in ->handle_event fsnotify: Pass fsnotify_iter_info into handle_event handler fanotify: Release SRCU lock when waiting for userspace response fs/notify/dnotify/dnotify.c | 3 +- fs/notify/fanotify/fanotify.c | 20 ++++++- fs/notify/fsnotify.c | 19 +++++-- fs/notify/fsnotify.h | 6 ++ fs/notify/group.c | 1 + fs/notify/inotify/inotify.h | 3 +- fs/notify/inotify/inotify_fsnotify.c | 3 +- fs/notify/inotify/inotify_user.c | 2 +- fs/notify/mark.c | 83 +++++++++++++++++++++++++++- include/linux/fsnotify_backend.h | 8 ++- kernel/audit_fsnotify.c | 3 +- kernel/audit_tree.c | 3 +- kernel/audit_watch.c | 3 +- 13 files changed, 139 insertions(+), 18 deletions(-) -- 2.19.1

6 years, 6 months

2
4
0 0

request for 4.14-stable: 293edc27f8bc ("stating: ccree: revert "staging: ccree: fix leak of import() after init()"")

by Sudip Mukherjee

Hi Greg, This was missing in 4.14-stable. Please apply to your queue. -- Regards Sudip

6 years, 6 months

3
4
0 0

Re: syncconfig changes in 4.19.34 break builds

by Sasha Levin

On Tue, Apr 09, 2019 at 02:50:04PM +0900, Masahiro Yamada wrote: >Greg, Sasha, > > >Sorry, the commit ID was wrong. > > >The following commit for 4.19.x: > >commit 02826a6ba301b72461c3706e1cc66d5571cd327e >Author: Masahiro Yamada <yamada.masahiro(a)socionext.com> >Date: Mon Nov 5 16:52:34 2018 +0900 > > kbuild: deb-pkg: fix bindeb-pkg breakage when O= is used This commit claims it's fixing 80463f1b7bf9, which is not in 4.19. Was that a mistake in the commit message? -- Thanks, Sasha

6 years, 6 months

2
2
0 0

[PATCH stable 4.19] Revert "clk: meson: clean-up clock registration"

by Neil Armstrong

This reverts commit c8e4f8406842332fb55cd792016e5dac266f6354. This patch was not initially a fix and is dependent on other changes which are not fixes eithers. With this change, multiple Amlogic based boards fails to boot, as reported by kernelci. Cc: stable(a)vger.kernel.org # 4.19.34 Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- drivers/clk/meson/meson-aoclk.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/clk/meson/meson-aoclk.c b/drivers/clk/meson/meson-aoclk.c index 258c8d259ea1..f965845917e3 100644 --- a/drivers/clk/meson/meson-aoclk.c +++ b/drivers/clk/meson/meson-aoclk.c @@ -65,20 +65,15 @@ int meson_aoclkc_probe(struct platform_device *pdev) return ret; } - /* Populate regmap */ - for (clkid = 0; clkid < data->num_clks; clkid++) + /* + * Populate regmap and register all clks + */ + for (clkid = 0; clkid < data->num_clks; clkid++) { data->clks[clkid]->map = regmap; - /* Register all clks */ - for (clkid = 0; clkid < data->hw_data->num; clkid++) { - if (!data->hw_data->hws[clkid]) - continue; - ret = devm_clk_hw_register(dev, data->hw_data->hws[clkid]); - if (ret) { - dev_err(dev, "Clock registration failed\n"); + if (ret) return ret; - } } return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, -- 2.21.0

6 years, 6 months

1
0
0 0

[PATCH 4.4 0/5] fanotify: Fix notification subsystem hang

by Matthew Ruffell

BugLink: https://bugs.launchpad.net/bugs/1775165 [Note to upstream] I understand that this patch is a little long for -stable, but this patch series fixes a real issue, seen by real users, is testable, and is made up from upstream commits. Please consider it. [Impact] When userspace tasks which are processing fanotify permission events act incorrectly, the fsnotify_mark_srcu SRCU is held indefinitely which causes the whole notification subsystem to hang. This has been seen in production, and it can also be seen when running the Linux Test Project testsuite, specifically fanotify07. [Fix] Instead of holding the SRCU lock while waiting for userspace to respond, which may never happen, or not in the order we are expecting, we drop the fsnotify_mark_srcu SRCU lock before waiting for userspace response, and then reacquire the lock again when userspace responds. The fixes are from a series of upstream commits: 05f0e38724e8449184acd8fbf0473ee5a07adc6c (cherry-pick) 9385a84d7e1f658bb2d96ab798393e4b16268aaa (backport) abc77577a669f424c5d0c185b9994f2621c52aa4 (backport) The following are upstream commits necessary for the fixes to function: 35e481761cdc688dbee0ef552a13f49af8eba6cc (backport) 0918f1c309b86301605650c836ddd2021d311ae2 (cherry-pick) [Testcase] You can reproduce the problem pretty quickly with the Linux Test Project: Steps (with root): 1. sudo apt-get install git xfsprogs -y 2. git clone --depth=1 https://github.com/linux-test-project/ltp.git 3. cd ltp 4. make autotools 5. ./configure 6. make; make install 7. cd /opt/ltp 8. echo -e "fanotify07 fanotify07 \nfanotify08 fanotify08" > /tmp/jobs 9. ./runltp -f /tmp/jobs On a stock Xenial kernel, the system will hang, and the testcase will look like: <<<test_start>>> tag=fanotify07 stime=1554326200 cmdline="fanotify07 " contacts="" analysis=exit <<<test_output>>> tst_test.c:1096: INFO: Timeout per run is 0h 05m 00s Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Cannot kill test processes! Congratulation, likely test hit a kernel bug. Exitting uncleanly... <<<execution_status>>> initiation_status="ok" duration=350 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Looking at dmesg, we see the following call stack [ 790.772792] LTP: starting fanotify07 (fanotify07 ) [ 960.140455] INFO: task fsnotify_mark:36 blocked for more than 120 seconds. [ 960.140867] Not tainted 4.4.0-142-generic #168-Ubuntu [ 960.141185] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 960.141498] fsnotify_mark D ffff8800b6703c98 0 36 2 0x00000000 [ 960.141516] ffff8800b6703c98 ffff88013a558a00 ffff8800b7797000 ffff8800b66f8000 [ 960.141524] ffff8800b6704000 7fffffffffffffff ffff8800b6703de0 ffff8800b66f8000 [ 960.141528] 0000000000000000 ffff8800b6703cb0 ffffffff8185cb45 ffff8800b6703de8 [ 960.141532] Call Trace: [ 960.141580] [<ffffffff8185cb45>] schedule+0x35/0x80 [ 960.141588] [<ffffffff818600f4>] schedule_timeout+0x1b4/0x270 [ 960.141617] [<ffffffff810f57ac>] ? mod_timer+0x10c/0x240 [ 960.141621] [<ffffffff8185c60d>] ? __schedule+0x30d/0x810 [ 960.141625] [<ffffffff8185d652>] wait_for_completion+0xb2/0x190 [ 960.141636] [<ffffffff810b1f10>] ? wake_up_q+0x70/0x70 [ 960.141641] [<ffffffff810eb140>] __synchronize_srcu+0x100/0x1a0 [ 960.141645] [<ffffffff810ea400>] ? trace_raw_output_rcu_utilization+0x60/0x60 [ 960.141664] [<ffffffff81260870>] ? fsnotify_put_mark+0x40/0x40 [ 960.141669] [<ffffffff810eb204>] synchronize_srcu+0x24/0x30 [ 960.141672] [<ffffffff812608f4>] fsnotify_mark_destroy+0x84/0x130 [ 960.141680] [<ffffffff810ca000>] ? wake_atomic_t_function+0x60/0x60 [ 960.141691] [<ffffffff810a6227>] kthread+0xe7/0x100 [ 960.141694] [<ffffffff8185c601>] ? __schedule+0x301/0x810 [ 960.141699] [<ffffffff810a6140>] ? kthread_create_on_node+0x1e0/0x1e0 [ 960.141703] [<ffffffff818618e5>] ret_from_fork+0x55/0x80 [ 960.141706] [<ffffffff810a6140>] ? kthread_create_on_node+0x1e0/0x1e0 The vanilla 4.4 kernel also shows the same call stack. On a patched kernel, the test will pass successfully, and there will be no messages in dmesg. [Regression Potential] This makes modifications to how locking is performed in fsnotify / fanotify and there may be some cause for regression. Running all fanotify Linux Test Project tests shows that there are no extra failures caused by the patches, and instead fewer failures are seen due to the bugfix. Running the entire Linux Test Project testsuite actually works and runs to completion, something which doesn't happen in a unpatched kernel since it will hang on the fanotify07 test. The patches are taken from upstream, and all necessary commits have been taken into account, so I am happy with the potential risks and that testing has been completed. Jan Kara (4): fsnotify: avoid spurious EMFILE errors from inotify_init() fsnotify: Provide framework for dropping SRCU lock in ->handle_event fsnotify: Pass fsnotify_iter_info into handle_event handler fanotify: Release SRCU lock when waiting for userspace response Jeff Layton (1): fsnotify: turn fsnotify reaper thread into a workqueue job fs/notify/dnotify/dnotify.c | 3 +- fs/notify/fanotify/fanotify.c | 20 ++- fs/notify/fsnotify.c | 19 ++- fs/notify/fsnotify.h | 13 ++ fs/notify/group.c | 18 ++- fs/notify/inotify/inotify.h | 3 +- fs/notify/inotify/inotify_fsnotify.c | 3 +- fs/notify/inotify/inotify_user.c | 2 +- fs/notify/mark.c | 194 +++++++++++++++++++++------ include/linux/fsnotify_backend.h | 10 +- kernel/audit_fsnotify.c | 3 +- kernel/audit_tree.c | 3 +- kernel/audit_watch.c | 3 +- 13 files changed, 230 insertions(+), 64 deletions(-) -- 2.19.1

6 years, 6 months

2
7
0 0

Re: [PATCH] mmc: dw_mmc: Disable SDIO interrupts while suspended to fix suspend/resume

by Doug Anderson

Hi, On Wed, Apr 10, 2019 at 4:20 PM Sasha Levin <sashal(a)kernel.org> wrote: > > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v5.0.7, v4.19.34, v4.14.111, v4.9.168, v4.4.178, v3.18.138. > > v5.0.7: Build OK! > v4.19.34: Build OK! > v4.14.111: Build OK! > v4.9.168: Failed to apply! Possible dependencies: > 0f21c58c63ad ("mmc: dw_mmc: Remove the public dw_mmc header file") > 1f5c51d76e8f ("mmc: dw_mmc: disable biu clk if possible") > 32dba73772f8 ("mmc: dw_mmc: Convert to use MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs") > 58870241a674 ("mmc: dw_mmc: remove the loop about finding slots") > a4cc7eb4416f ("mmc: dw_mmc: use the cookie's enum values for post/pre_req()") > ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs are enabled") > d30a8f7bdf64 ("mmc: dw_mmc: deprecated the "num-slots" property") > df9bcc2bc0a1 ("mmc: dw_mmc: add missing codes for runtime resume") > e9748e0364fe ("mmc: dw_mmc: force setup bus if active slots exist") > e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback") > ed24e1ff5ae3 ("mmc: dw_mmc: remove system PM callback") > f90142683f04 ("mmc: dw_mmc-rockchip: add runtime PM support") > > v4.4.178: Failed to apply! Possible dependencies: > 01a999e48995 ("mmc: dw_mmc: remove the unused quirks") > 267b62a96951 ("clk: tegra: pll: Update PLLM handling") > 287980e49ffc ("remove lots of IS_ERR_VALUE abuses") > 32dba73772f8 ("mmc: dw_mmc: Convert to use MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs") > 3706b43629f5 ("clk: tegra: pll: Don't unconditionally set LOCK flags") > 407254da291c ("clk: tegra: pll: Add logic for out-of-table rates for T210") > 58870241a674 ("mmc: dw_mmc: remove the loop about finding slots") > 6583a6309e83 ("clk: tegra: pll: Add tegra_pll_wait_for_lock to clk header") > 6929715cf6b9 ("clk: tegra: pll: Add support for PLLMB for Tegra210") > 6b301a059eb2 ("clk: tegra: Add support for Tegra210 clocks") > 7db864c9deb2 ("clk: tegra: pll: Simplify clk_enable_path") > 86c679a52294 ("clk: tegra: pll: Fix _pll_ramp_calc_pll logic and _calc_dynamic_ramp_rate") > 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities") > 8d99704fde54 ("clk: tegra: Format tables consistently") > c4947e364b50 ("clk: tegra: Fix 26 MHz oscillator frequency") > ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs are enabled") > d907f4b4a178 ("clk: tegra: pll: Add logic for handling SDM data") > dd322f047d22 ("clk: tegra: pll: Add specialized logic for Tegra210") > e52d7c04bb39 ("clk: tegra: Miscellaneous coding style cleanups") > e8cc37b8fc3a ("mmc: dw_mmc: remove DW_MCI_QUIRK_BROKEN_CARD_DETECTION quirk") > f8d31489629c ("ACPICA: Debugger: Convert some mechanisms to OSPM specific") > > v3.18.138: Failed to apply! Possible dependencies: > 1a25b1b4199c ("mmc: dw_mmc: fix the max_blk_count in IDMAC") > 2b708df2b3ed ("mmc: dw_mmc: remove the unused blk_setting") > 32dba73772f8 ("mmc: dw_mmc: Convert to use MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs") > 575c319dfe87 ("mmc: dw_mmc: fix pio mode when internal dmac is enabled") > 58870241a674 ("mmc: dw_mmc: remove the loop about finding slots") > 5959b32e3636 ("mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used") > 6130e7a9c34d ("mmc: dw_mmc: Remove old card detect infrastructure") > 6687c42fa71a ("mmc: dw_mmc: change idmac descriptor files to __le32") > 69d99fdcfd78 ("mmc: dw_mmc: Add IDMAC 64-bit address mode support") > 767562348b72 ("mmc: dw_mmc: add support for the other bit of sdio interrupt") > b24c8b260189 ("mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts") > ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs are enabled") > ed2540effa70 ("mmc: dw_mmc: Don't crash if we get an interrupt before slot has initted") > f8c58c113634 ("mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock") > fa0c328343c6 ("mmc: dw_mmc: Only enable CD after setup and only if needed") > > > How should we proceed with this patch? This is discussed "after the cut" in my commit message. The low-hanging fruit is to just pick it to 5.0 and 4.19. If folks are interested I can spin a 4.14 build back up again and test the patch there, but likely if it applies / builds then it'll just work. For older that 4.14 I'd say to just drop this but an interested party could try if they really wanted. Given (for me) ~1/3 of my suspend/resumes were failing presumably anyone on an old kernel has already come up with some sort of solution themselves. Hrm, I guess I could have just added a versioning tag to my "Cc". I'll do that next time. I guess first we should see if MMC maintainers think the patch looks OK. -Doug

6 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror