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

[PATCH] HID: input: fix leaking custom input node name

by Stefan Agner

Make sure to free the custom input node name on disconnect. Cc: stable(a)vger.kernel.org # v4.18+ Fixes: c554bb045511 ("HID: input: append a suffix matching the application") Signed-off-by: Stefan Agner <stefan(a)agner.ch> --- Found with kmemleak, after unplugging a Logitech Unifying receiver: unreferenced object 0xc2345b80 (size 64): comm "kworker/0:1", pid 20, jiffies 4294955181 (age 320.740s) hex dump (first 32 bytes): 4c 6f 67 69 74 65 63 68 20 55 53 42 20 52 65 63 Logitech USB Rec 65 69 76 65 72 20 53 79 73 74 65 6d 20 43 6f 6e eiver System Con backtrace: [<8fec5a71>] __kmalloc_track_caller+0x1dc/0x300 [<5b926275>] kvasprintf+0x60/0xcc [<21fc360f>] kasprintf+0x38/0x54 [<3b6ce9f0>] hidinput_connect+0x23a8/0x4c60 [<deaab707>] hid_connect+0x30c/0x38c [<5a28f7c9>] hid_hw_start+0x44/0x64 [<267d70e8>] hid_generic_probe+0x34/0x38 [<d68c31b1>] hid_device_probe+0xdc/0x13c [<09414e91>] really_probe+0x1d8/0x2c4 [<f9d7157f>] driver_probe_device+0x68/0x184 [<1def17c8>] __device_attach_driver+0xa0/0xd4 [<d3b2081b>] bus_for_each_drv+0x60/0xc0 [<379d02f8>] __device_attach+0xdc/0x144 [<7026ace5>] device_initial_probe+0x14/0x18 [<44527d01>] bus_probe_device+0x90/0x98 [<cf58bf2f>] device_add+0x424/0x62c drivers/hid/hid-input.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c index 4e94ea3e280a..ac201817a2dd 100644 --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1815,6 +1815,7 @@ void hidinput_disconnect(struct hid_device *hid) input_unregister_device(hidinput->input); else input_free_device(hidinput->input); + kfree(hidinput->name); kfree(hidinput); } -- 2.18.0

7 years

2
1
0 0

Editing is it

by Jason

Do you have photos for cutting out,or adding clipping path? We are here to help you for that also including retouching. Both for product photos and portrait photos. Yours, Jason

7 years

1
0
0 0

v3.18.120 build: 0 failures 1 warnings (v3.18.120)

by Build bot for Mark Brown

Tree/Branch: v3.18.120 Git describe: v3.18.120 Commit: a5f9be3576 Linux 3.18.120 Build Time: 0 min 1 sec Passed: 7 / 7 (100.00 %) Failed: 0 / 7 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 7 warnings 0 mismatches : x86_64-allmodconfig 2 warnings 0 mismatches : x86_64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 9 ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 7 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: x86_64-allnoconfig arm-multi_v7_defconfig arm-allmodconfig arm-allnoconfig arm-multi_v5_defconfig

7 years

1
0
0 0

[PATCH] tty: serial: lpuart: avoid leaking struct tty_struct

by Stefan Agner

The function tty_port_tty_get() gets a reference to the tty. Since the code is not using tty_port_tty_set(), the reference is kept even after closing the tty. Avoid using tty_port_tty_get() by directly access the tty instance. Since lpuart_start_rx_dma() is called from the .startup() and .set_termios() callback, it is safe to assume the tty instance is valid. Cc: stable(a)vger.kernel.org # v4.9+ Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx") Signed-off-by: Stefan Agner <stefan(a)agner.ch> --- This fixes a memory leak observable when opening/closing the tty in a loop. This is also reported by kmemleak: unreferenced object 0xc9d17000 (size 1024): comm "(agetty)", pid 389, jiffies 4294943045 (age 100.670s) hex dump (first 32 bytes): 01 54 00 00 01 00 00 00 00 8c 9b c8 80 58 9b c8 .T...........X.. 48 58 c4 c0 00 00 00 00 00 00 00 00 00 00 00 00 HX.............. backtrace: [<(ptrval)>] kmem_cache_alloc_trace+0x160/0x2b8 [<(ptrval)>] alloc_tty_struct+0x44/0x254 [<(ptrval)>] tty_init_dev+0x44/0x1c8 [<(ptrval)>] tty_open+0x268/0x414 [<(ptrval)>] chrdev_open+0xb4/0x1bc [<(ptrval)>] do_dentry_open+0x1c0/0x388 [<(ptrval)>] vfs_open+0x34/0x38 [<(ptrval)>] path_openat+0x5b0/0x11bc [<(ptrval)>] do_filp_open+0x7c/0xe8 [<(ptrval)>] do_sys_open+0x188/0x20c [<(ptrval)>] sys_openat+0x14/0x18 [<(ptrval)>] ret_fast_syscall+0x0/0x28 [<(ptrval)>] 0xbee0a460 [<(ptrval)>] 0xffffffff I *think* the statement that accessing tty_struct without using tty_port_tty_get is safe in this case is true. It would be good if somebody with more TTY knowledge could review the change. -- Stefan drivers/tty/serial/fsl_lpuart.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c index 51e47a63d61a..3f8d1274fc85 100644 --- a/drivers/tty/serial/fsl_lpuart.c +++ b/drivers/tty/serial/fsl_lpuart.c @@ -979,7 +979,8 @@ static inline int lpuart_start_rx_dma(struct lpuart_port *sport) struct circ_buf *ring = &sport->rx_ring; int ret, nent; int bits, baud; - struct tty_struct *tty = tty_port_tty_get(&sport->port.state->port); + struct tty_port *port = &sport->port.state->port; + struct tty_struct *tty = port->tty; struct ktermios *termios = &tty->termios; baud = tty_get_baud_rate(tty); -- 2.18.0

7 years

1
0
0 0

[PATCH] xprtrdma: Fix disconnect regression

by Chuck Lever

I found that injecting disconnects with v4.18-rc resulted in random failures of the multi-threaded git regression test. The root cause appears to be that, after a reconnect, the RPC/RDMA transport is waking pending RPCs before the transport has posted enough Receive buffers to receive the Replies. If a Reply arrives before enough Receive buffers are posted, the connection is dropped. A few connection drops happen in quick succession as the client and server struggle to regain credit synchronization. This regression was introduced with commit 7c8d9e7c8863 ("xprtrdma: Move Receive posting to Receive handler"). The client is supposed to post a single Receive when a connection is established because it's not supposed to send more than one RPC Call before it gets a fresh credit grant in the first RPC Reply [RFC 8166, Section 3.3.3]. Unfortunately there appears to be a longstanding bug in the Linux client's credit accounting mechanism. On connect, it simply dumps all pending RPC Calls onto the new connection. It's possible it has done this ever since the RPC/RDMA transport was added to the kernel ten years ago. Servers have so far been tolerant of this bad behavior. Currently no server implementation ever changes its credit grant over reconnects, and servers always repost enough Receives before connections are fully established. The Linux client implementation used to post a Receive before each of these Calls. This has covered up the flooding send behavior. I could try to correct this old bug so that the client sends exactly one RPC Call and waits for a Reply. Since we are so close to the next merge window, I'm going to instead provide a simple patch to post enough Receives before a reconnect completes (based on the number of credits granted to the previous connection). The spurious disconnects will be gone, but the client will still send multiple RPC Calls immediately after a reconnect. Addressing the latter problem will wait for a merge window because a) I expect it to be a large change requiring lots of testing, and b) obviously the Linux client has interoperated successfully since day zero while still being broken. Fixes: 7c8d9e7c8863 ("xprtrdma: Move Receive posting to ... ") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- net/sunrpc/xprtrdma/verbs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Hi stable@ - This fix has been merged into v4.19 as upstream commit 8d4fb8ff427a ("xprtrdma: Fix disconnect regression"). It addresses a regression in v4.18. I expected it to go into late v4.18-rc, which is why there is no "cc: stable" on the original submission. Could you please apply it to 4.18.y ? Thank you! diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c index 042bb24..1386c6e 100644 --- a/net/sunrpc/xprtrdma/verbs.c +++ b/net/sunrpc/xprtrdma/verbs.c @@ -279,7 +279,6 @@ ++xprt->rx_xprt.connect_cookie; connstate = -ECONNABORTED; connected: - xprt->rx_buf.rb_credits = 1; ep->rep_connected = connstate; rpcrdma_conn_func(ep); wake_up_all(&ep->rep_connect_wait); @@ -754,6 +753,7 @@ } ep->rep_connected = 0; + rpcrdma_post_recvs(r_xprt, true); rc = rdma_connect(ia->ri_id, &ep->rep_remote_cma); if (rc) { @@ -772,8 +772,6 @@ dprintk("RPC: %s: connected\n", __func__); - rpcrdma_post_recvs(r_xprt, true); - out: if (rc) ep->rep_connected = rc; @@ -1170,6 +1168,7 @@ struct rpcrdma_req * list_add(&req->rl_list, &buf->rb_send_bufs); } + buf->rb_credits = 1; buf->rb_posted_receives = 0; INIT_LIST_HEAD(&buf->rb_recv_bufs);

7 years

2
1
0 0

[PATCH 4.4 0/5] 4.4.153-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.153 release. There are 5 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Aug 28 06:40:50 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.153-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.4.153-rc1 Vivek Goyal <vgoyal(a)redhat.com> ovl: warn instead of error if d_type is not supported Vivek Goyal <vgoyal(a)redhat.com> ovl: Do d_type check only if work dir creation was successful Vivek Goyal <vgoyal(a)redhat.com> ovl: Ensure upper filesystem supports d_type Eric Biggers <ebiggers(a)google.com> x86/mm: Fix use-after-free of ldt_struct Andi Kleen <ak(a)linux.intel.com> x86/mm/pat: Fix L1TF stable backport for CPA ------------- Diffstat: Makefile | 4 ++-- arch/x86/include/asm/mmu_context.h | 3 +-- arch/x86/mm/pageattr.c | 2 +- fs/overlayfs/overlayfs.h | 1 + fs/overlayfs/readdir.c | 37 +++++++++++++++++++++++++++++++++++++ fs/overlayfs/super.c | 20 ++++++++++++++++++++ 6 files changed, 62 insertions(+), 5 deletions(-)

7 years

4
8
0 0

[PATCH] soc: qcom: rmtfs-mem: Validate that scm is available

by Bjorn Andersson

The scm device must be present in order for the rmtfs driver to configure memory permissions for the rmtfs memory region, so check that it is probed before continuing. Cc: stable(a)vger.kernel.org Fixes: fa65f8045137 ("soc: qcom: rmtfs-mem: Add support for assigning memory to remote") Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- drivers/soc/qcom/rmtfs_mem.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/soc/qcom/rmtfs_mem.c b/drivers/soc/qcom/rmtfs_mem.c index 8a3678c2e83c..97bb5989aa21 100644 --- a/drivers/soc/qcom/rmtfs_mem.c +++ b/drivers/soc/qcom/rmtfs_mem.c @@ -212,6 +212,11 @@ static int qcom_rmtfs_mem_probe(struct platform_device *pdev) dev_err(&pdev->dev, "failed to parse qcom,vmid\n"); goto remove_cdev; } else if (!ret) { + if (!qcom_scm_is_available()) { + ret = -EPROBE_DEFER; + goto remove_cdev; + } + perms[0].vmid = QCOM_SCM_VMID_HLOS; perms[0].perm = QCOM_SCM_PERM_RW; perms[1].vmid = vmid; -- 2.18.0

7 years

1
0
0 0

[PATCH v2] selftests: membarrier: fix test by checking supported commands

by Rafael David Tinoco

Makes membarrier_test compatible with older kernels (LTS) by checking if the membarrier features exist before running the tests. Link: https://bugs.linaro.org/show_bug.cgi?id=3771 Signed-off-by: Rafael David Tinoco <rafael.tinoco(a)linaro.org> Cc: <stable(a)vger.kernel.org> #v4.17 --- .../selftests/membarrier/membarrier_test.c | 71 +++++++++++-------- 1 file changed, 40 insertions(+), 31 deletions(-) diff --git a/tools/testing/selftests/membarrier/membarrier_test.c b/tools/testing/selftests/membarrier/membarrier_test.c index 6793f8ecc8e7..4dc263824bda 100644 --- a/tools/testing/selftests/membarrier/membarrier_test.c +++ b/tools/testing/selftests/membarrier/membarrier_test.c @@ -223,7 +223,7 @@ static int test_membarrier_global_expedited_success(void) return 0; } -static int test_membarrier(void) +static int test_membarrier(int supported) { int status; @@ -236,21 +236,22 @@ static int test_membarrier(void) status = test_membarrier_global_success(); if (status) return status; - status = test_membarrier_private_expedited_fail(); - if (status) - return status; - status = test_membarrier_register_private_expedited_success(); - if (status) - return status; - status = test_membarrier_private_expedited_success(); - if (status) - return status; - status = sys_membarrier(MEMBARRIER_CMD_QUERY, 0); - if (status < 0) { - ksft_test_result_fail("sys_membarrier() failed\n"); - return status; + + /* commit 22e4ebb975822833b083533035233d128b30e98f added this feature */ + if (supported & MEMBARRIER_CMD_PRIVATE_EXPEDITED) { + status = test_membarrier_private_expedited_fail(); + if (status) + return status; + status = test_membarrier_register_private_expedited_success(); + if (status) + return status; + status = test_membarrier_private_expedited_success(); + if (status) + return status; } - if (status & MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE) { + + /* commit 70216e18e519a54a2f13569e8caff99a092a92d6 added this feature */ + if (supported & MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE) { status = test_membarrier_private_expedited_sync_core_fail(); if (status) return status; @@ -261,23 +262,28 @@ static int test_membarrier(void) if (status) return status; } - /* - * It is valid to send a global membarrier from a non-registered - * process. - */ - status = test_membarrier_global_expedited_success(); - if (status) - return status; - status = test_membarrier_register_global_expedited_success(); - if (status) - return status; - status = test_membarrier_global_expedited_success(); - if (status) - return status; + + /* commit c5f58bd58f432be5d92df33c5458e0bcbee3aadf added this feature */ + if (supported & MEMBARRIER_CMD_GLOBAL_EXPEDITED) { + /* + * It is valid to send a global membarrier from a non-registered + * process. + */ + status = test_membarrier_global_expedited_success(); + if (status) + return status; + status = test_membarrier_register_global_expedited_success(); + if (status) + return status; + status = test_membarrier_global_expedited_success(); + if (status) + return status; + } + return 0; } -static int test_membarrier_query(void) +static int test_membarrier_query(int *supported) { int flags = 0, ret; @@ -297,16 +303,19 @@ static int test_membarrier_query(void) ksft_exit_skip( "sys_membarrier unsupported: CMD_GLOBAL not found.\n"); + *supported = ret; ksft_test_result_pass("sys_membarrier available\n"); return 0; } int main(int argc, char **argv) { + int supported; + ksft_print_header(); - test_membarrier_query(); - test_membarrier(); + test_membarrier_query(&supported); + test_membarrier(supported); return ksft_exit_pass(); } -- 2.18.0

7 years

2
1
0 0

[char-misc for 4.9 2/2] mei: bus: need to unlink client before freeing

by Tomas Winkler

In case a client fails to connect in mei_cldev_enable(), the caller won't call the mei_cldev_disable leaving the client in a linked stated. Upon driver unload the client structure will be freed in mei_cl_bus_dev_release(), leaving a stale pointer on a fail_list. This will eventually end up in crash during power down flow in mei_cl_set_disonnected(). RIP: mei_cl_set_disconnected+0x5/0x260[mei] Call trace: mei_cl_all_disconnect+0x22/0x30 mei_reset+0x194/0x250 __synchronize_hardirq+0x43/0x50 _cond_resched+0x15/0x30 mei_me_intr_clear+0x20/0x100 mei_stop+0x76/0xb0 mei_me_shutdown+0x3f/0x80 pci_device_shutdown+0x34/0x60 kernel_restart+0x0e/0x30 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200455 Fixes: 'c110cdb17148 ("mei: bus: make a client pointer always available")' Cc: <stable(a)vger.kernel.org> 4.10+ Tested-by: Georg Müller <georgmueller(a)gmx.net> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> --- drivers/misc/mei/bus.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index 13c6c9a2248a..fc3872fe7b25 100644 --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -521,17 +521,15 @@ int mei_cldev_enable(struct mei_cl_device *cldev) cl = cldev->cl; + mutex_lock(&bus->device_lock); if (cl->state == MEI_FILE_UNINITIALIZED) { - mutex_lock(&bus->device_lock); ret = mei_cl_link(cl); - mutex_unlock(&bus->device_lock); if (ret) - return ret; + goto out; /* update pointers */ cl->cldev = cldev; } - mutex_lock(&bus->device_lock); if (mei_cl_is_connected(cl)) { ret = 0; goto out; @@ -875,12 +873,13 @@ static void mei_cl_bus_dev_release(struct device *dev) mei_me_cl_put(cldev->me_cl); mei_dev_bus_put(cldev->bus); + mei_cl_unlink(cldev->cl); kfree(cldev->cl); kfree(cldev); } static const struct device_type mei_cl_device_type = { - .release = mei_cl_bus_dev_release, + .release = mei_cl_bus_dev_release, }; /** -- 2.14.4

7 years

1
0
0 0

[char-misc for 4.9 1/2] mei: bus: fix hw module get/put balance

by Tomas Winkler

In case the device is not connected it doesn't 'get' hw module and hence should not 'put' it on disable. Cc: <stable(a)vger.kernel.org> 4.16+ Fixes:'commit 257355a44b99 ("mei: make module referencing local to the bus.c")' Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200455 Tested-by: Georg Müller <georgmueller(a)gmx.net> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> --- drivers/misc/mei/bus.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index 7bba62a72921..13c6c9a2248a 100644 --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -616,9 +616,8 @@ int mei_cldev_disable(struct mei_cl_device *cldev) if (err < 0) dev_err(bus->dev, "Could not disconnect from the ME client\n"); -out: mei_cl_bus_module_put(cldev); - +out: /* Flush queues and remove any pending read */ mei_cl_flush_queues(cl, NULL); mei_cl_unlink(cl); -- 2.14.4

7 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror