April 2019 - Linux-stable-mirror

Re: [PATCH v2] extcon: axp288: Add a depends on ACPI to the Kconfig entry

by Chanwoo Choi

Dear all, + stable(a)vger.kernel.org It should be posted to stable(a)vger.kernel.org in order to merge it to stable tree. Regards, Chanwoo Choi On 19. 4. 12. 오전 8:30, Chanwoo Choi wrote: > On 19. 4. 4. 오후 11:17, Yue Haibing wrote: >> From: YueHaibing <yuehaibing(a)huawei.com> >> >> As Hans de Goede pointed, using this driver without ACPI >> makes little sense, so add ACPI dependency to Kconfig entry >> to fix a build error while CONFIG_ACPI is not set. >> >> drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe': >> drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to incomplete type >> put_device(&adev->dev); >> >> Fixes: 0cf064db948a ("extcon: axp288: Convert to use acpi_dev_get_first_match_dev()") >> Reported-by: Hulk Robot <hulkci(a)huawei.com> >> Suggested-by: Hans de Goede <hdegoede(a)redhat.com> >> Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> >> --- >> v2: rework patch >> --- >> drivers/extcon/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig >> index 1ed4b45..de06faf 100644 >> --- a/drivers/extcon/Kconfig >> +++ b/drivers/extcon/Kconfig >> @@ -30,7 +30,7 @@ config EXTCON_ARIZONA >> >> config EXTCON_AXP288 >> tristate "X-Power AXP288 EXTCON support" >> - depends on MFD_AXP20X && USB_SUPPORT && X86 >> + depends on MFD_AXP20X && USB_SUPPORT && X86 && ACPI >> select USB_ROLE_SWITCH >> help >> Say Y here to enable support for USB peripheral detection >> > > Applied it. Thanks. > -- Best Regards, Chanwoo Choi Samsung Electronics

5 years, 9 months

1
0
0 0

[PATCH v2] drm/nouveau/i2c: Disable i2c bus access after ->fini()

by Lyude Paul

For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime suspend, the MMIO region that the i2c bus is on isn't accessible. On x86, the standard behavior for accessing an unavailable MMIO region is to just return ~0. Except, that turned out to be a lie. While computers with a clean concious will return ~0 in this scenario, some machines will actually completely hang a CPU on certian bad MMIO accesses. This was witnessed with someone's Lenovo ThinkPad P50, where sensors-detect attempting to access the i2c bus while the GPU was suspended would result in a CPU hang: CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1 Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017 RIP: 0010:ioread32+0x2b/0x30 Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3 48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f 40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48 RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13 RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186 RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4 RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7 R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000 R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000 FS: 00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: g94_i2c_aux_xfer+0x326/0x850 [nouveau] nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau] __i2c_transfer+0x14b/0x620 i2c_smbus_xfer_emulated+0x159/0x680 ? _raw_spin_unlock_irqrestore+0x1/0x60 ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0 ? __lock_is_held+0x59/0xa0 __i2c_smbus_xfer+0x138/0x5a0 i2c_smbus_xfer+0x4f/0x80 i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev] i2cdev_ioctl+0x1db/0x2c0 [i2c_dev] do_vfs_ioctl+0x408/0x750 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f25317f546b Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003 RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0 R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80 R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0 watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438] Yikes! While I wanted to try to make it so that accessing an i2c bus on nouveau would wake up the GPU as needed, airlied pointed out that pretty much any usecase for userspace accessing an i2c bus on a GPU (mainly for the DDC brightness control that some displays have) is going to only be useful while there's at least one display enabled on the GPU anyway, and the GPU never sleeps while there's displays running. Since teaching the i2c bus to wake up the GPU on userspace accesses is a good deal more difficult than it might seem, mostly due to the fact that we have to use the i2c bus during runtime resume of the GPU, we instead opt for the easiest solution: don't let userspace access i2c busses on the GPU at all while it's in runtime suspend. Changes since v1: * Also disable i2c busses that run over DP AUX Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org --- .../gpu/drm/nouveau/include/nvkm/subdev/i2c.h | 2 ++ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 26 ++++++++++++++++++- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h | 2 ++ .../gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 15 +++++++++++ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 21 ++++++++++++++- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h | 1 + 6 files changed, 65 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h index eef54e9b5d77..7957eafa5f0e 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h @@ -38,6 +38,7 @@ struct nvkm_i2c_bus { struct mutex mutex; struct list_head head; struct i2c_adapter i2c; + u8 enabled; }; int nvkm_i2c_bus_acquire(struct nvkm_i2c_bus *); @@ -57,6 +58,7 @@ struct nvkm_i2c_aux { struct mutex mutex; struct list_head head; struct i2c_adapter i2c; + u8 enabled; u32 intr; }; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c index 4c1f547da463..b4e7404fe660 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c @@ -105,9 +105,15 @@ nvkm_i2c_aux_acquire(struct nvkm_i2c_aux *aux) { struct nvkm_i2c_pad *pad = aux->pad; int ret; + AUX_TRACE(aux, "acquire"); mutex_lock(&aux->mutex); - ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_AUX); + + if (aux->enabled) + ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_AUX); + else + ret = -EIO; + if (ret) mutex_unlock(&aux->mutex); return ret; @@ -145,6 +151,24 @@ nvkm_i2c_aux_del(struct nvkm_i2c_aux **paux) } } +void +nvkm_i2c_aux_init(struct nvkm_i2c_aux *aux) +{ + AUX_TRACE(aux, "init"); + mutex_lock(&aux->mutex); + aux->enabled = true; + mutex_unlock(&aux->mutex); +} + +void +nvkm_i2c_aux_fini(struct nvkm_i2c_aux *aux) +{ + AUX_TRACE(aux, "fini"); + mutex_lock(&aux->mutex); + aux->enabled = false; + mutex_unlock(&aux->mutex); +} + int nvkm_i2c_aux_ctor(const struct nvkm_i2c_aux_func *func, struct nvkm_i2c_pad *pad, int id, diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h index 7d56c4ba693c..08f6b2ee64ab 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h @@ -16,6 +16,8 @@ int nvkm_i2c_aux_ctor(const struct nvkm_i2c_aux_func *, struct nvkm_i2c_pad *, int nvkm_i2c_aux_new_(const struct nvkm_i2c_aux_func *, struct nvkm_i2c_pad *, int id, struct nvkm_i2c_aux **); void nvkm_i2c_aux_del(struct nvkm_i2c_aux **); +void nvkm_i2c_aux_init(struct nvkm_i2c_aux *); +void nvkm_i2c_aux_fini(struct nvkm_i2c_aux *); int nvkm_i2c_aux_xfer(struct nvkm_i2c_aux *, bool retry, u8 type, u32 addr, u8 *data, u8 *size); diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c index 4f197b15acf6..ecacb22834d7 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c @@ -160,8 +160,18 @@ nvkm_i2c_fini(struct nvkm_subdev *subdev, bool suspend) { struct nvkm_i2c *i2c = nvkm_i2c(subdev); struct nvkm_i2c_pad *pad; + struct nvkm_i2c_bus *bus; + struct nvkm_i2c_aux *aux; u32 mask; + list_for_each_entry(aux, &i2c->aux, head) { + nvkm_i2c_aux_fini(aux); + } + + list_for_each_entry(bus, &i2c->bus, head) { + nvkm_i2c_bus_fini(bus); + } + if ((mask = (1 << i2c->func->aux) - 1), i2c->func->aux_stat) { i2c->func->aux_mask(i2c, NVKM_I2C_ANY, mask, 0); i2c->func->aux_stat(i2c, &mask, &mask, &mask, &mask); @@ -180,6 +190,7 @@ nvkm_i2c_init(struct nvkm_subdev *subdev) struct nvkm_i2c *i2c = nvkm_i2c(subdev); struct nvkm_i2c_bus *bus; struct nvkm_i2c_pad *pad; + struct nvkm_i2c_aux *aux; list_for_each_entry(pad, &i2c->pad, head) { nvkm_i2c_pad_init(pad); @@ -189,6 +200,10 @@ nvkm_i2c_init(struct nvkm_subdev *subdev) nvkm_i2c_bus_init(bus); } + list_for_each_entry(aux, &i2c->aux, head) { + nvkm_i2c_aux_init(aux); + } + return 0; } diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c index 807a2b67bd64..ed50cc3736b9 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c @@ -110,6 +110,19 @@ nvkm_i2c_bus_init(struct nvkm_i2c_bus *bus) BUS_TRACE(bus, "init"); if (bus->func->init) bus->func->init(bus); + + mutex_lock(&bus->mutex); + bus->enabled = true; + mutex_unlock(&bus->mutex); +} + +void +nvkm_i2c_bus_fini(struct nvkm_i2c_bus *bus) +{ + BUS_TRACE(bus, "fini"); + mutex_lock(&bus->mutex); + bus->enabled = false; + mutex_unlock(&bus->mutex); } void @@ -126,9 +139,15 @@ nvkm_i2c_bus_acquire(struct nvkm_i2c_bus *bus) { struct nvkm_i2c_pad *pad = bus->pad; int ret; + BUS_TRACE(bus, "acquire"); mutex_lock(&bus->mutex); - ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_I2C); + + if (bus->enabled) + ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_I2C); + else + ret = -EIO; + if (ret) mutex_unlock(&bus->mutex); return ret; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h index bea0dd33961e..465464bba58b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h @@ -18,6 +18,7 @@ int nvkm_i2c_bus_new_(const struct nvkm_i2c_bus_func *, struct nvkm_i2c_pad *, int id, struct nvkm_i2c_bus **); void nvkm_i2c_bus_del(struct nvkm_i2c_bus **); void nvkm_i2c_bus_init(struct nvkm_i2c_bus *); +void nvkm_i2c_bus_fini(struct nvkm_i2c_bus *); int nvkm_i2c_bit_xfer(struct nvkm_i2c_bus *, struct i2c_msg *, int); -- 2.20.1

5 years, 9 months

2
3
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 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.

5 years, 9 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.

5 years, 9 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

5 years, 9 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

5 years, 9 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

5 years, 9 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

5 years, 9 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

5 years, 9 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

5 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2019