- 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 months

1
0
0 0

[PATCH] block: do not leak memory in bio_copy_user_iov()

by jglisse＠redhat.com

From: Jérôme Glisse <jglisse(a)redhat.com> When bio_add_pc_page() fails in bio_copy_user_iov() we should free the page we just allocated otherwise we are leaking it. Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: linux-block(a)vger.kernel.org Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org --- block/bio.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/block/bio.c b/block/bio.c index b64cedc7f87c..716510ecd7ff 100644 --- a/block/bio.c +++ b/block/bio.c @@ -1298,8 +1298,11 @@ struct bio *bio_copy_user_iov(struct request_queue *q, } } - if (bio_add_pc_page(q, bio, page, bytes, offset) < bytes) + if (bio_add_pc_page(q, bio, page, bytes, offset) < bytes) { + if (!map_data) + __free_page(page); break; + } len -= bytes; offset = 0; -- 2.20.1

6 years, 5 months

3
2
0 0

[PATCH v2 3/7] crypto: arm/aes-neonbs - don't access already-freed walk.iv

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> If the user-provided IV needs to be aligned to the algorithm's alignmask, then skcipher_walk_virt() copies the IV into a new aligned buffer walk.iv. But skcipher_walk_virt() can fail afterwards, and then if the caller unconditionally accesses walk.iv, it's a use-after-free. arm32 xts-aes-neonbs doesn't set an alignmask, so currently it isn't affected by this despite unconditionally accessing walk.iv. However this is more subtle than desired, and it was actually broken prior to the alignmask being removed by commit cc477bf64573 ("crypto: arm/aes - replace bit-sliced OpenSSL NEON code"). Thus, update xts-aes-neonbs to start checking the return value of skcipher_walk_virt(). Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions") Cc: <stable(a)vger.kernel.org> # v3.13+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- arch/arm/crypto/aes-neonbs-glue.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/crypto/aes-neonbs-glue.c b/arch/arm/crypto/aes-neonbs-glue.c index 07e31941dc674..617c2c99ebfb3 100644 --- a/arch/arm/crypto/aes-neonbs-glue.c +++ b/arch/arm/crypto/aes-neonbs-glue.c @@ -278,6 +278,8 @@ static int __xts_crypt(struct skcipher_request *req, int err; err = skcipher_walk_virt(&walk, req, true); + if (err) + return err; crypto_cipher_encrypt_one(ctx->tweak_tfm, walk.iv, walk.iv); -- 2.21.0

6 years, 5 months

2
1
0 0

[PATCH v2 5/7] crypto: gcm - fix incompatibility between "gcm" and "gcm_base"

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> GCM instances can be created by either the "gcm" template, which only allows choosing the block cipher, e.g. "gcm(aes)"; or by "gcm_base", which allows choosing the ctr and ghash implementations, e.g. "gcm_base(ctr(aes-generic),ghash-generic)". However, a "gcm_base" instance prevents a "gcm" instance from being registered using the same implementations. Nor will the instance be found by lookups of "gcm". This can be used as a denial of service. Moreover, "gcm_base" instances are never tested by the crypto self-tests, even if there are compatible "gcm" tests. The root cause of these problems is that instances of the two templates use different cra_names. Therefore, fix these problems by making "gcm_base" instances set the same cra_name as "gcm" instances, e.g. "gcm(aes)" instead of "gcm_base(ctr(aes-generic),ghash-generic)". This requires extracting the block cipher name from the name of the ctr algorithm. It also requires starting to verify that the algorithms are really ctr and ghash, not something else entirely. But it would be bizarre if anyone were actually using non-gcm-compatible algorithms with gcm_base, so this shouldn't break anyone in practice. Fixes: d00aa19b507b ("[CRYPTO] gcm: Allow block cipher parameter") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/gcm.c | 32 +++++++++----------------------- 1 file changed, 9 insertions(+), 23 deletions(-) diff --git a/crypto/gcm.c b/crypto/gcm.c index e1a11f529d257..c7354ed1fa4d4 100644 --- a/crypto/gcm.c +++ b/crypto/gcm.c @@ -597,7 +597,6 @@ static void crypto_gcm_free(struct aead_instance *inst) static int crypto_gcm_create_common(struct crypto_template *tmpl, struct rtattr **tb, - const char *full_name, const char *ctr_name, const char *ghash_name) { @@ -638,7 +637,7 @@ static int crypto_gcm_create_common(struct crypto_template *tmpl, goto err_free_inst; err = -EINVAL; - if (ghash->digestsize != 16) + if (strcmp(ghash->base.cra_name, "ghash") != 0) goto err_drop_ghash; crypto_set_skcipher_spawn(&ctx->ctr, aead_crypto_instance(inst)); @@ -650,24 +649,23 @@ static int crypto_gcm_create_common(struct crypto_template *tmpl, ctr = crypto_spawn_skcipher_alg(&ctx->ctr); - /* We only support 16-byte blocks. */ + /* The skcipher algorithm must be CTR mode, using 16-byte blocks. */ err = -EINVAL; - if (crypto_skcipher_alg_ivsize(ctr) != 16) + if (strncmp(ctr->base.cra_name, "ctr(", 4) != 0 || + crypto_skcipher_alg_ivsize(ctr) != 16) goto out_put_ctr; - /* Not a stream cipher? */ - if (ctr->base.cra_blocksize != 1) + err = -ENAMETOOLONG; + if (snprintf(inst->alg.base.cra_name, CRYPTO_MAX_ALG_NAME, + "gcm(%s", ctr->base.cra_name + 4) >= CRYPTO_MAX_ALG_NAME) goto out_put_ctr; - err = -ENAMETOOLONG; if (snprintf(inst->alg.base.cra_driver_name, CRYPTO_MAX_ALG_NAME, "gcm_base(%s,%s)", ctr->base.cra_driver_name, ghash_alg->cra_driver_name) >= CRYPTO_MAX_ALG_NAME) goto out_put_ctr; - memcpy(inst->alg.base.cra_name, full_name, CRYPTO_MAX_ALG_NAME); - inst->alg.base.cra_flags = (ghash->base.cra_flags | ctr->base.cra_flags) & CRYPTO_ALG_ASYNC; inst->alg.base.cra_priority = (ghash->base.cra_priority + @@ -709,7 +707,6 @@ static int crypto_gcm_create(struct crypto_template *tmpl, struct rtattr **tb) { const char *cipher_name; char ctr_name[CRYPTO_MAX_ALG_NAME]; - char full_name[CRYPTO_MAX_ALG_NAME]; cipher_name = crypto_attr_alg_name(tb[1]); if (IS_ERR(cipher_name)) @@ -719,12 +716,7 @@ static int crypto_gcm_create(struct crypto_template *tmpl, struct rtattr **tb) CRYPTO_MAX_ALG_NAME) return -ENAMETOOLONG; - if (snprintf(full_name, CRYPTO_MAX_ALG_NAME, "gcm(%s)", cipher_name) >= - CRYPTO_MAX_ALG_NAME) - return -ENAMETOOLONG; - - return crypto_gcm_create_common(tmpl, tb, full_name, - ctr_name, "ghash"); + return crypto_gcm_create_common(tmpl, tb, ctr_name, "ghash"); } static int crypto_gcm_base_create(struct crypto_template *tmpl, @@ -732,7 +724,6 @@ static int crypto_gcm_base_create(struct crypto_template *tmpl, { const char *ctr_name; const char *ghash_name; - char full_name[CRYPTO_MAX_ALG_NAME]; ctr_name = crypto_attr_alg_name(tb[1]); if (IS_ERR(ctr_name)) @@ -742,12 +733,7 @@ static int crypto_gcm_base_create(struct crypto_template *tmpl, if (IS_ERR(ghash_name)) return PTR_ERR(ghash_name); - if (snprintf(full_name, CRYPTO_MAX_ALG_NAME, "gcm_base(%s,%s)", - ctr_name, ghash_name) >= CRYPTO_MAX_ALG_NAME) - return -ENAMETOOLONG; - - return crypto_gcm_create_common(tmpl, tb, full_name, - ctr_name, ghash_name); + return crypto_gcm_create_common(tmpl, tb, ctr_name, ghash_name); } static int crypto_rfc4106_setkey(struct crypto_aead *parent, const u8 *key, -- 2.21.0

6 years, 5 months

2
1
0 0

[PATCH v2 6/7] crypto: ccm - fix incompatibility between "ccm" and "ccm_base"

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> CCM instances can be created by either the "ccm" template, which only allows choosing the block cipher, e.g. "ccm(aes)"; or by "ccm_base", which allows choosing the ctr and cbcmac implementations, e.g. "ccm_base(ctr(aes-generic),cbcmac(aes-generic))". However, a "ccm_base" instance prevents a "ccm" instance from being registered using the same implementations. Nor will the instance be found by lookups of "ccm". This can be used as a denial of service. Moreover, "ccm_base" instances are never tested by the crypto self-tests, even if there are compatible "ccm" tests. The root cause of these problems is that instances of the two templates use different cra_names. Therefore, fix these problems by making "ccm_base" instances set the same cra_name as "ccm" instances, e.g. "ccm(aes)" instead of "ccm_base(ctr(aes-generic),cbcmac(aes-generic))". This requires extracting the block cipher name from the name of the ctr and cbcmac algorithms. It also requires starting to verify that the algorithms are really ctr and cbcmac using the same block cipher, not something else entirely. But it would be bizarre if anyone were actually using non-ccm-compatible algorithms with ccm_base, so this shouldn't break anyone in practice. Fixes: 4a49b499dfa0 ("[CRYPTO] ccm: Added CCM mode") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/ccm.c | 43 +++++++++++++++++-------------------------- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/crypto/ccm.c b/crypto/ccm.c index 50df8f001c1c9..dbb3b6d8e6136 100644 --- a/crypto/ccm.c +++ b/crypto/ccm.c @@ -458,7 +458,6 @@ static void crypto_ccm_free(struct aead_instance *inst) static int crypto_ccm_create_common(struct crypto_template *tmpl, struct rtattr **tb, - const char *full_name, const char *ctr_name, const char *mac_name) { @@ -486,7 +485,8 @@ static int crypto_ccm_create_common(struct crypto_template *tmpl, mac = __crypto_hash_alg_common(mac_alg); err = -EINVAL; - if (mac->digestsize != 16) + if (strncmp(mac->base.cra_name, "cbcmac(", 7) != 0 || + mac->digestsize != 16) goto out_put_mac; inst = kzalloc(sizeof(*inst) + sizeof(*ictx), GFP_KERNEL); @@ -509,23 +509,26 @@ static int crypto_ccm_create_common(struct crypto_template *tmpl, ctr = crypto_spawn_skcipher_alg(&ictx->ctr); - /* Not a stream cipher? */ + /* The skcipher algorithm must be CTR mode, using 16-byte blocks. */ err = -EINVAL; - if (ctr->base.cra_blocksize != 1) + if (strncmp(ctr->base.cra_name, "ctr(", 4) != 0 || + crypto_skcipher_alg_ivsize(ctr) != 16) goto err_drop_ctr; - /* We want the real thing! */ - if (crypto_skcipher_alg_ivsize(ctr) != 16) + /* ctr and cbcmac must use the same underlying block cipher. */ + if (strcmp(ctr->base.cra_name + 4, mac->base.cra_name + 7) != 0) goto err_drop_ctr; err = -ENAMETOOLONG; + if (snprintf(inst->alg.base.cra_name, CRYPTO_MAX_ALG_NAME, + "ccm(%s", ctr->base.cra_name + 4) >= CRYPTO_MAX_ALG_NAME) + goto err_drop_ctr; + if (snprintf(inst->alg.base.cra_driver_name, CRYPTO_MAX_ALG_NAME, "ccm_base(%s,%s)", ctr->base.cra_driver_name, mac->base.cra_driver_name) >= CRYPTO_MAX_ALG_NAME) goto err_drop_ctr; - memcpy(inst->alg.base.cra_name, full_name, CRYPTO_MAX_ALG_NAME); - inst->alg.base.cra_flags = ctr->base.cra_flags & CRYPTO_ALG_ASYNC; inst->alg.base.cra_priority = (mac->base.cra_priority + ctr->base.cra_priority) / 2; @@ -567,7 +570,6 @@ static int crypto_ccm_create(struct crypto_template *tmpl, struct rtattr **tb) const char *cipher_name; char ctr_name[CRYPTO_MAX_ALG_NAME]; char mac_name[CRYPTO_MAX_ALG_NAME]; - char full_name[CRYPTO_MAX_ALG_NAME]; cipher_name = crypto_attr_alg_name(tb[1]); if (IS_ERR(cipher_name)) @@ -581,35 +583,24 @@ static int crypto_ccm_create(struct crypto_template *tmpl, struct rtattr **tb) cipher_name) >= CRYPTO_MAX_ALG_NAME) return -ENAMETOOLONG; - if (snprintf(full_name, CRYPTO_MAX_ALG_NAME, "ccm(%s)", cipher_name) >= - CRYPTO_MAX_ALG_NAME) - return -ENAMETOOLONG; - - return crypto_ccm_create_common(tmpl, tb, full_name, ctr_name, - mac_name); + return crypto_ccm_create_common(tmpl, tb, ctr_name, mac_name); } static int crypto_ccm_base_create(struct crypto_template *tmpl, struct rtattr **tb) { const char *ctr_name; - const char *cipher_name; - char full_name[CRYPTO_MAX_ALG_NAME]; + const char *mac_name; ctr_name = crypto_attr_alg_name(tb[1]); if (IS_ERR(ctr_name)) return PTR_ERR(ctr_name); - cipher_name = crypto_attr_alg_name(tb[2]); - if (IS_ERR(cipher_name)) - return PTR_ERR(cipher_name); - - if (snprintf(full_name, CRYPTO_MAX_ALG_NAME, "ccm_base(%s,%s)", - ctr_name, cipher_name) >= CRYPTO_MAX_ALG_NAME) - return -ENAMETOOLONG; + mac_name = crypto_attr_alg_name(tb[2]); + if (IS_ERR(mac_name)) + return PTR_ERR(mac_name); - return crypto_ccm_create_common(tmpl, tb, full_name, ctr_name, - cipher_name); + return crypto_ccm_create_common(tmpl, tb, ctr_name, mac_name); } static int crypto_rfc4309_setkey(struct crypto_aead *parent, const u8 *key, -- 2.21.0

6 years, 5 months

2
1
0 0

[PATCH v2 2/7] crypto: salsa20 - don't access already-freed walk.iv

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> If the user-provided IV needs to be aligned to the algorithm's alignmask, then skcipher_walk_virt() copies the IV into a new aligned buffer walk.iv. But skcipher_walk_virt() can fail afterwards, and then if the caller unconditionally accesses walk.iv, it's a use-after-free. salsa20-generic doesn't set an alignmask, so currently it isn't affected by this despite unconditionally accessing walk.iv. However this is more subtle than desired, and it was actually broken prior to the alignmask being removed by commit b62b3db76f73 ("crypto: salsa20-generic - cleanup and convert to skcipher API"). Since salsa20-generic does not update the IV and does not need any IV alignment, update it to use req->iv instead of walk.iv. Fixes: 2407d60872dd ("[CRYPTO] salsa20: Salsa20 stream cipher") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/salsa20_generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/salsa20_generic.c b/crypto/salsa20_generic.c index 443fba09cbed7..faed244be316f 100644 --- a/crypto/salsa20_generic.c +++ b/crypto/salsa20_generic.c @@ -160,7 +160,7 @@ static int salsa20_crypt(struct skcipher_request *req) err = skcipher_walk_virt(&walk, req, false); - salsa20_init(state, ctx, walk.iv); + salsa20_init(state, ctx, req->iv); while (walk.nbytes > 0) { unsigned int nbytes = walk.nbytes; -- 2.21.0

6 years, 5 months

2
1
0 0

[PATCH v2 4/7] crypto: arm64/aes-neonbs - don't access already-freed walk.iv

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> If the user-provided IV needs to be aligned to the algorithm's alignmask, then skcipher_walk_virt() copies the IV into a new aligned buffer walk.iv. But skcipher_walk_virt() can fail afterwards, and then if the caller unconditionally accesses walk.iv, it's a use-after-free. xts-aes-neonbs doesn't set an alignmask, so currently it isn't affected by this despite unconditionally accessing walk.iv. However this is more subtle than desired, and unconditionally accessing walk.iv has caused a real problem in other algorithms. Thus, update xts-aes-neonbs to start checking the return value of skcipher_walk_virt(). Fixes: 1abee99eafab ("crypto: arm64/aes - reimplement bit-sliced ARM/NEON implementation for arm64") Cc: <stable(a)vger.kernel.org> # v4.11+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- arch/arm64/crypto/aes-neonbs-glue.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c index 4737b6c6c5cf5..5144551177334 100644 --- a/arch/arm64/crypto/aes-neonbs-glue.c +++ b/arch/arm64/crypto/aes-neonbs-glue.c @@ -304,6 +304,8 @@ static int __xts_crypt(struct skcipher_request *req, int err; err = skcipher_walk_virt(&walk, req, false); + if (err) + return err; kernel_neon_begin(); neon_aes_ecb_encrypt(walk.iv, walk.iv, ctx->twkey, ctx->key.rounds, 1); -- 2.21.0

6 years, 5 months

2
1
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: 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 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] ✅ /kernel/distribution/ltp/lite ✅ AMTU (Abstract Machine Test Utility) [1] 🚧 ✅ audit: audit testsuite test [2] ✅ httpd: mod_ssl smoke sanity [3] ✅ httpd: php sanity [4] 🚧 ✅ iotop: sanity [5] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport 🚧 ✅ tuned: tune-processes-through-perf [6] 🚧 ✅ stress: stress-ng [7] ppc64le: ✅ Boot test [0] ✅ /kernel/distribution/ltp/lite ✅ AMTU (Abstract Machine Test Utility) [1] 🚧 ✅ audit: audit testsuite test [2] ✅ httpd: mod_ssl smoke sanity [3] ✅ httpd: php sanity [4] 🚧 ✅ iotop: sanity [5] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport 🚧 ✅ selinux-policy: serge-testsuite [8] 🚧 ✅ tuned: tune-processes-through-perf [6] 🚧 ✅ stress: stress-ng [7] x86_64: ✅ Boot test [0] ✅ /kernel/distribution/ltp/lite ✅ AMTU (Abstract Machine Test Utility) [1] 🚧 ✅ audit: audit testsuite test [2] ✅ httpd: mod_ssl smoke sanity [3] ✅ httpd: php sanity [4] 🚧 ✅ iotop: sanity [5] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport 🚧 ✅ selinux-policy: serge-testsuite [8] 🚧 ✅ tuned: tune-processes-through-perf [6] 🚧 ✅ stress: stress-ng [7] 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#misc/amtu [2]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [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/iot… [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#stress/stres… [8]: 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, 5 months

1
0
0 0

[PATCH] drm/i915/dp: revert back to max link rate and lane count on eDP

by Jani Nikula

Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow") started to optize the eDP 1.4+ link config, both per spec and as preparation for display stream compression support. Sadly, we again face panels that flat out fail with parameters they claim to support. Revert, and go back to the drawing board. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959 Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow") Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Manasi Navare <manasi.d.navare(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Matt Atwood <matthew.s.atwood(a)intel.com> Cc: "Lee, Shawn C" <shawn.c.lee(a)intel.com> Cc: Dave Airlie <airlied(a)gmail.com> Cc: intel-gfx(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.0+ Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- drivers/gpu/drm/i915/intel_dp.c | 67 +++++---------------------------- 1 file changed, 9 insertions(+), 58 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 72c490..fd0f53 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1856,42 +1856,6 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp, return -EINVAL; } -/* Optimize link config in order: max bpp, min lanes, min clock */ -static int -intel_dp_compute_link_config_fast(struct intel_dp *intel_dp, - struct intel_crtc_state *pipe_config, - const struct link_config_limits *limits) -{ - struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; - int bpp, clock, lane_count; - int mode_rate, link_clock, link_avail; - - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) { - mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, - bpp); - - for (lane_count = limits->min_lane_count; - lane_count <= limits->max_lane_count; - lane_count <<= 1) { - for (clock = limits->min_clock; clock <= limits->max_clock; clock++) { - link_clock = intel_dp->common_rates[clock]; - link_avail = intel_dp_max_data_rate(link_clock, - lane_count); - - if (mode_rate <= link_avail) { - pipe_config->lane_count = lane_count; - pipe_config->pipe_bpp = bpp; - pipe_config->port_clock = link_clock; - - return 0; - } - } - } - } - - return -EINVAL; -} - static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc) { int i, num_bpc; @@ -2031,12 +1995,10 @@ intel_dp_compute_link_config(struct intel_encoder *encoder, if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) { /* * Use the maximum clock and number of lanes the eDP panel - * advertizes being capable of. The eDP 1.3 and earlier panels - * are generally designed to support only a single clock and - * lane configuration, and typically these values correspond to - * the native resolution of the panel. With eDP 1.4 rate select - * and DSC, this is decreasingly the case, and we need to be - * able to select less than maximum link config. + * advertizes being capable of. The panels are generally + * designed to support only a single clock and lane + * configuration, and typically these values correspond to the + * native resolution of the panel. */ limits.min_lane_count = limits.max_lane_count; limits.min_clock = limits.max_clock; @@ -2050,22 +2012,11 @@ intel_dp_compute_link_config(struct intel_encoder *encoder, intel_dp->common_rates[limits.max_clock], limits.max_bpp, adjusted_mode->crtc_clock); - if (intel_dp_is_edp(intel_dp)) - /* - * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4 - * section A.1: "It is recommended that the minimum number of - * lanes be used, using the minimum link rate allowed for that - * lane configuration." - * - * Note that we use the max clock and lane count for eDP 1.3 and - * earlier, and fast vs. wide is irrelevant. - */ - ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config, - &limits); - else - /* Optimize for slow and wide. */ - ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, - &limits); + /* + * Optimize for slow and wide. This is the place to add alternative + * optimization policy. + */ + ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits); /* enable compression if the mode doesn't fit available BW */ DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en); -- 2.20.1

6 years, 5 months

3
8
0 0

[PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for v4.19 and v5.0 stable respectively. Thank you!

6 years, 5 months

2
1
0 0

[PATCH] i3c: Fix the verification of random PID

by Vitor Soares

The validation of random PID should be done by checking the boardinfo->pid instead of info.pid which is empty. Doing the change the info struture declaration is no longer necessary. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares(a)synopsys.com> Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: <stable(a)vger.kernel.org> --- drivers/i3c/master.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c index 569ea68..d23a57e 100644 --- a/drivers/i3c/master.c +++ b/drivers/i3c/master.c @@ -2006,7 +2006,6 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master, { struct i3c_dev_boardinfo *boardinfo; struct device *dev = &master->dev; - struct i3c_device_info info = { }; enum i3c_addr_slot_status addrstatus; u32 init_dyn_addr = 0; @@ -2038,8 +2037,8 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master, boardinfo->pid = ((u64)reg[1] << 32) | reg[2]; - if ((info.pid & GENMASK_ULL(63, 48)) || - I3C_PID_RND_LOWER_32BITS(info.pid)) + if ((boardinfo->pid & GENMASK_ULL(63, 48)) || + I3C_PID_RND_LOWER_32BITS(boardinfo->pid)) return -EINVAL; boardinfo->init_dyn_addr = init_dyn_addr; -- 2.7.4

6 years, 5 months

2
1
0 0

[PATCH v5 00/10] mm: Sub-section memory hotplug support

by Dan Williams

Changes since v4 [1]: - Given v4 was from March of 2017 the bulk of the changes result from rebasing the patch set from a v4.11-rc2 baseline to v5.1-rc1. - A unit test is added to ndctl to exercise the creation and dax mounting of multiple independent namespaces in a single 128M section. [1]: https://lwn.net/Articles/717383/ --- Quote patch7: "The libnvdimm sub-system has suffered a series of hacks and broken workarounds for the memory-hotplug implementation's awkward section-aligned (128MB) granularity. For example the following backtrace is emitted when attempting arch_add_memory() with physical address ranges that intersect 'System RAM' (RAM) with 'Persistent Memory' (PMEM) within a given section: WARNING: CPU: 0 PID: 558 at kernel/memremap.c:300 devm_memremap_pages+0x3b5/0x4c0 devm_memremap_pages attempted on mixed region [mem 0x200000000-0x2fbffffff flags 0x200] [..] Call Trace: dump_stack+0x86/0xc3 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 devm_memremap_pages+0x3b5/0x4c0 __wrap_devm_memremap_pages+0x58/0x70 [nfit_test_iomap] pmem_attach_disk+0x19a/0x440 [nd_pmem] Recently it was discovered that the problem goes beyond RAM vs PMEM collisions as some platform produce PMEM vs PMEM collisions within a given section. The libnvdimm workaround for that case revealed that the libnvdimm section-alignment-padding implementation has been broken for a long while. A fix for that long-standing breakage introduces as many problems as it solves as it would require a backward-incompatible change to the namespace metadata interpretation. Instead of that dubious route [2], address the root problem in the memory-hotplug implementation." The approach is taken is to observe that each section already maintains an array of 'unsigned long' values to hold the pageblock_flags. A single additional 'unsigned long' is added to house a 'sub-section active' bitmask. Each bit tracks the mapped state of one sub-section's worth of capacity which is SECTION_SIZE / BITS_PER_LONG, or 2MB on x86-64. The implication of allowing sections to be piecemeal mapped/unmapped is that the valid_section() helper is no longer authoritative to determine if a section is fully mapped. Instead pfn_valid() is updated to consult the section-active bitmask. Given that typical memory hotplug still has deep "section" dependencies the sub-section capability is limited to 'want_memblock=false' invocations of arch_add_memory(), effectively only devm_memremap_pages() users for now. With this in place the hacks in the libnvdimm sub-system can be dropped, and other devm_memremap_pages() users need no longer be constrained to 128MB mapping granularity. [2]: https://lore.kernel.org/r/155000671719.348031.2347363160141119237.stgit@dwi… --- Dan Williams (10): mm/sparsemem: Introduce struct mem_section_usage mm/sparsemem: Introduce common definitions for the size and mask of a section mm/sparsemem: Add helpers track active portions of a section at boot mm/hotplug: Prepare shrink_{zone,pgdat}_span for sub-section removal mm/sparsemem: Convert kmalloc_section_memmap() to populate_section_memmap() mm/sparsemem: Prepare for sub-section ranges mm/sparsemem: Support sub-section hotplug mm/devm_memremap_pages: Enable sub-section remap libnvdimm/pfn: Fix fsdax-mode namespace info-block zero-fields libnvdimm/pfn: Stop padding pmem namespaces to section alignment arch/x86/mm/init_64.c | 15 +- drivers/nvdimm/dax_devs.c | 2 drivers/nvdimm/pfn.h | 12 - drivers/nvdimm/pfn_devs.c | 93 +++------- include/linux/memory_hotplug.h | 7 - include/linux/mm.h | 4 include/linux/mmzone.h | 60 ++++++ kernel/memremap.c | 57 ++---- mm/hmm.c | 2 mm/memory_hotplug.c | 119 +++++++----- mm/page_alloc.c | 6 - mm/sparse-vmemmap.c | 21 +- mm/sparse.c | 382 ++++++++++++++++++++++++++++------------ 13 files changed, 476 insertions(+), 304 deletions(-)

6 years, 5 months

4
20
0 0

Collaboration

by djohnsto＠zoho.com

Good day. I am D C Johnston, a broker working with Sikhombo Wealth Services. We are a wealth management company based in South Africa. I am contacting you because one of my high profile clients is interested in investing in your country and has asked me to look for individuals and companies with interesting business ideas and companies that he can invest in. He wants to expand his portfolio and has interest in investing a substantial amount of revenue abroad. I got your contact when searching the internet through the directory enquiries and I believe that my client will be interested in working with you. As you can imagine, we have not had any prior communication before so I will be keeping the details to a minimum until I get a confirmation from you that you are interested in this proposal. I will then give you more details upon receiving your positive response. Please provide your direct telephone number as well so that I can give you a call to discuss further. Best regards D C Johnston Sikhombo Wealth Services

6 years, 5 months

1
0
0 0

[PATCH v2 1/7] crypto: lrw - don't access already-freed walk.iv

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> If the user-provided IV needs to be aligned to the algorithm's alignmask, then skcipher_walk_virt() copies the IV into a new aligned buffer walk.iv. But skcipher_walk_virt() can fail afterwards, and then if the caller unconditionally accesses walk.iv, it's a use-after-free. Fix this in the LRW template by checking the return value of skcipher_walk_virt(). This bug was detected by my patches that improve testmgr to fuzz algorithms against their generic implementation. When the extra self-tests were run on a KASAN-enabled kernel, a KASAN use-after-free splat occured during lrw(aes) testing. Fixes: c778f96bf347 ("crypto: lrw - Optimize tweak computation") Cc: <stable(a)vger.kernel.org> # v4.20+ Cc: Ondrej Mosnacek <omosnace(a)redhat.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/lrw.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/crypto/lrw.c b/crypto/lrw.c index 0430ccd087286..b6666c595a686 100644 --- a/crypto/lrw.c +++ b/crypto/lrw.c @@ -162,8 +162,10 @@ static int xor_tweak(struct skcipher_request *req, bool second_pass) } err = skcipher_walk_virt(&w, req, false); - iv = (__be32 *)w.iv; + if (err) + return err; + iv = (__be32 *)w.iv; counter[0] = be32_to_cpu(iv[3]); counter[1] = be32_to_cpu(iv[2]); counter[2] = be32_to_cpu(iv[1]); -- 2.21.0

6 years, 5 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: 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 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 - release 20190115 [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 - release 20190115 [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 - release 20190115 [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, 5 months

1
0
0 0

[PATCH v2 hulk-4.19-next 03/10] scsi:hisi_sas: fix calls to dma_set_mask_and_coherent()

by chenxiang

From: c00284940 <c00284940(a)huawei.com> plinth inclusion category: bugfix bugzilla: NA DTS: DTS2019030103192 CVE: NA The change to use dma_set_mask_and_coherent() incorrectly made a second call with the 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded. This resulted in FC connections failing due to corrupted data buffers, and various other SCSI/FCP I/O errors. Fixes: e4db40e ("scsi: hisi_sas: use dma_set_mask_and_coherent") Cc: <stable(a)vger.kernel.org> Signed-off-by: c00284940 <c00284940(a)huawei.com> Reviewed-on: http://10.90.31.173:8080/4799 Tested-by: public TuringEE <turingee(a)huawei.com> Reviewed-by: huangdaode 00314581 <huangdaode(a)hisilicon.com> Reviewed-by: public TuringEE <turingee(a)huawei.com> --- drivers/scsi/hisi_sas/hisi_sas_main.c | 8 ++++++-- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 15 +++++++-------- 2 files changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index 30db81d..8e9d980 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -2567,6 +2567,7 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct platform_device *pdev, struct Scsi_Host *shost; struct hisi_hba *hisi_hba; struct device *dev = &pdev->dev; + int error; shost = scsi_host_alloc(hw->sht, sizeof(*hisi_hba)); if (!shost) { @@ -2587,8 +2588,11 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct platform_device *pdev, if (hisi_sas_get_fw_info(hisi_hba) < 0) goto err_out; - if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)) && - dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { + error = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)); + if (error) + error = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)); + + if (error) { dev_err(dev, "No usable DMA addressing method\n"); goto err_out; } diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index b4bde32..24db55f 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -2903,14 +2903,13 @@ hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) if (rc) goto err_out_disable_device; - if ((pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) != 0) || - (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64)) != 0)) { - if ((pci_set_dma_mask(pdev, DMA_BIT_MASK(32)) != 0) || - (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32)) != 0)) { - dev_err(dev, "No usable DMA addressing method\n"); - rc = -EIO; - goto err_out_regions; - } + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); + if (rc) + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); + if (rc) { + dev_err(dev, "No usable DMA addressing method\n"); + rc = -ENODEV; + goto err_out_regions; } shost = hisi_sas_shost_alloc_pci(pdev); -- 2.8.1

6 years, 5 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror