This is a note to let you know that I've just added the patch titled
IB/core: Fix two kernel warnings triggered by rxe registration
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 02ee9da347873699603d9ce0112a80b5dd69dea1 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 3 Jan 2018 13:28:18 -0800
Subject: IB/core: Fix two kernel warnings triggered by rxe registration
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 02ee9da347873699603d9ce0112a80b5dd69dea1 upstream.
Eliminate the WARN_ONs that create following two warnings when
registering an rxe device:
WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/device.c:449 ib_register_device+0x591/0x640 [ib_core]
CPU: 2 PID: 1005 Comm: run_tests Not tainted 4.15.0-rc4-dbg+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:ib_register_device+0x591/0x640 [ib_core]
Call Trace:
rxe_register_device+0x3c6/0x470 [rdma_rxe]
rxe_add+0x543/0x5e0 [rdma_rxe]
rxe_net_add+0x37/0xb0 [rdma_rxe]
rxe_param_set_add+0x5a/0x120 [rdma_rxe]
param_attr_store+0x5e/0xc0
module_attr_store+0x19/0x30
sysfs_kf_write+0x3d/0x50
kernfs_fop_write+0x116/0x1a0
__vfs_write+0x23/0x120
vfs_write+0xbe/0x1b0
SyS_write+0x44/0xa0
entry_SYSCALL_64_fastpath+0x23/0x9a
WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/sysfs.c:1279 ib_device_register_sysfs+0x11d/0x160 [ib_core]
CPU: 2 PID: 1005 Comm: run_tests Tainted: G W 4.15.0-rc4-dbg+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:ib_device_register_sysfs+0x11d/0x160 [ib_core]
Call Trace:
ib_register_device+0x3f7/0x640 [ib_core]
rxe_register_device+0x3c6/0x470 [rdma_rxe]
rxe_add+0x543/0x5e0 [rdma_rxe]
rxe_net_add+0x37/0xb0 [rdma_rxe]
rxe_param_set_add+0x5a/0x120 [rdma_rxe]
param_attr_store+0x5e/0xc0
module_attr_store+0x19/0x30
sysfs_kf_write+0x3d/0x50
kernfs_fop_write+0x116/0x1a0
__vfs_write+0x23/0x120
vfs_write+0xbe/0x1b0
SyS_write+0x44/0xa0
entry_SYSCALL_64_fastpath+0x23/0x9a
The code should accept either a parent pointer or a fully specified DMA
specification without producing warnings.
Fixes: 99db9494035f ("IB/core: Remove ib_device.dma_device")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/device.c | 20 ++++++++++++++------
drivers/infiniband/core/sysfs.c | 1 -
2 files changed, 14 insertions(+), 7 deletions(-)
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -462,7 +462,6 @@ int ib_register_device(struct ib_device
struct ib_udata uhw = {.outlen = 0, .inlen = 0};
struct device *parent = device->dev.parent;
- WARN_ON_ONCE(!parent);
WARN_ON_ONCE(device->dma_device);
if (device->dev.dma_ops) {
/*
@@ -471,16 +470,25 @@ int ib_register_device(struct ib_device
* into device->dev.
*/
device->dma_device = &device->dev;
- if (!device->dev.dma_mask)
- device->dev.dma_mask = parent->dma_mask;
- if (!device->dev.coherent_dma_mask)
- device->dev.coherent_dma_mask =
- parent->coherent_dma_mask;
+ if (!device->dev.dma_mask) {
+ if (parent)
+ device->dev.dma_mask = parent->dma_mask;
+ else
+ WARN_ON_ONCE(true);
+ }
+ if (!device->dev.coherent_dma_mask) {
+ if (parent)
+ device->dev.coherent_dma_mask =
+ parent->coherent_dma_mask;
+ else
+ WARN_ON_ONCE(true);
+ }
} else {
/*
* The caller did not provide custom DMA operations. Use the
* DMA mapping operations of the parent device.
*/
+ WARN_ON_ONCE(!parent);
device->dma_device = parent;
}
--- a/drivers/infiniband/core/sysfs.c
+++ b/drivers/infiniband/core/sysfs.c
@@ -1276,7 +1276,6 @@ int ib_device_register_sysfs(struct ib_d
int ret;
int i;
- WARN_ON_ONCE(!device->dev.parent);
ret = dev_set_name(class_dev, "%s", device->name);
if (ret)
return ret;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.15/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch
queue-4.15/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch
queue-4.15/rdma-rxe-fix-rxe_qp_cleanup.patch
queue-4.15/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch
This is a note to let you know that I've just added the patch titled
IB/core: Avoid a potential OOPs for an unused optional parameter
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2ff124d597c2df8696169ce0006fc974c49a4569 Mon Sep 17 00:00:00 2001
From: "Michael J. Ruhl" <michael.j.ruhl(a)intel.com>
Date: Thu, 1 Feb 2018 12:31:06 -0800
Subject: IB/core: Avoid a potential OOPs for an unused optional parameter
From: Michael J. Ruhl <michael.j.ruhl(a)intel.com>
commit 2ff124d597c2df8696169ce0006fc974c49a4569 upstream.
The ev_file is an optional parameter for CQ creation. If the parameter
is not passed, the ev_file pointer will be NULL. Using that pointer
to set the cq_context will result in an OOPs.
Verify that ev_file is not NULL before using.
Cc: <stable(a)vger.kernel.org> # 4.14.x
Fixes: 9ee79fce3642 ("IB/core: Add completion queue (cq) object actions")
Reviewed-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Reviewed-by: Ira Weiny <ira.weiny(a)intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/uverbs_std_types.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/uverbs_std_types.c
+++ b/drivers/infiniband/core/uverbs_std_types.c
@@ -315,7 +315,7 @@ static int uverbs_create_cq_handler(stru
cq->uobject = &obj->uobject;
cq->comp_handler = ib_uverbs_comp_handler;
cq->event_handler = ib_uverbs_cq_event_handler;
- cq->cq_context = &ev_file->ev_queue;
+ cq->cq_context = ev_file ? &ev_file->ev_queue : NULL;
obj->uobject.object = cq;
obj->uobject.user_handle = user_handle;
atomic_set(&cq->usecnt, 0);
Patches currently in stable-queue which might be from michael.j.ruhl(a)intel.com are
queue-4.15/ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch
queue-4.15/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch
This is a note to let you know that I've just added the patch titled
selftests: seccomp: fix compile error seccomp_bpf
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
selftests-seccomp-fix-compile-error-seccomp_bpf.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 912ec316686df352028afb6efec59e47a958a24d Mon Sep 17 00:00:00 2001
From: Anders Roxell <anders.roxell(a)linaro.org>
Date: Fri, 5 Jan 2018 17:31:18 +0100
Subject: selftests: seccomp: fix compile error seccomp_bpf
From: Anders Roxell <anders.roxell(a)linaro.org>
commit 912ec316686df352028afb6efec59e47a958a24d upstream.
aarch64-linux-gnu-gcc -Wl,-no-as-needed -Wall
-lpthread seccomp_bpf.c -o seccomp_bpf
seccomp_bpf.c: In function 'tracer_ptrace':
seccomp_bpf.c:1720:12: error: '__NR_open' undeclared
(first use in this function)
if (nr == __NR_open)
^~~~~~~~~
seccomp_bpf.c:1720:12: note: each undeclared identifier is reported
only once for each function it appears in
In file included from seccomp_bpf.c:48:0:
seccomp_bpf.c: In function 'TRACE_syscall_ptrace_syscall_dropped':
seccomp_bpf.c:1795:39: error: '__NR_open' undeclared
(first use in this function)
EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open));
^
open(2) is a legacy syscall, replaced with openat(2) since 2.6.16.
Thus new architectures in the kernel, such as arm64, don't implement
these legacy syscalls.
Fixes: a33b2d0359a0 ("selftests/seccomp: Add tests for basic ptrace actions")
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
Tested-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
Cc: stable(a)vger.kernel.org
Acked-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -1717,7 +1717,7 @@ void tracer_ptrace(struct __test_metadat
if (nr == __NR_getpid)
change_syscall(_metadata, tracee, __NR_getppid);
- if (nr == __NR_open)
+ if (nr == __NR_openat)
change_syscall(_metadata, tracee, -1);
}
@@ -1792,7 +1792,7 @@ TEST_F(TRACE_syscall, ptrace_syscall_dro
true);
/* Tracer should skip the open syscall, resulting in EPERM. */
- EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open));
+ EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_openat));
}
TEST_F(TRACE_syscall, syscall_allowed)
Patches currently in stable-queue which might be from anders.roxell(a)linaro.org are
queue-4.14/selftests-seccomp-fix-compile-error-seccomp_bpf.patch
This is a note to let you know that I've just added the patch titled
RDMA/rxe: Fix rxe_qp_cleanup()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-rxe-fix-rxe_qp_cleanup.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Fri, 12 Jan 2018 15:11:59 -0800
Subject: RDMA/rxe: Fix rxe_qp_cleanup()
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 upstream.
rxe_qp_cleanup() can sleep so it must be run in thread context and
not in atomic context. This patch avoids that the following bug is
triggered:
Kernel BUG at 00000000560033f3 [verbose debug info unavailable]
BUG: sleeping function called from invalid context at net/core/sock.c:2761
in_atomic(): 1, irqs_disabled(): 0, pid: 7, name: ksoftirqd/0
INFO: lockdep is turned off.
Preemption disabled at:
[<00000000b6e69628>] __do_softirq+0x4e/0x540
CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.15.0-rc7-dbg+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x85/0xbf
___might_sleep+0x177/0x260
lock_sock_nested+0x1d/0x90
inet_shutdown+0x2e/0xd0
rxe_qp_cleanup+0x107/0x140 [rdma_rxe]
rxe_elem_release+0x18/0x80 [rdma_rxe]
rxe_requester+0x1cf/0x11b0 [rdma_rxe]
rxe_do_task+0x78/0xf0 [rdma_rxe]
tasklet_action+0x99/0x270
__do_softirq+0xc0/0x540
run_ksoftirqd+0x1c/0x70
smpboot_thread_fn+0x1be/0x270
kthread+0x117/0x130
ret_from_fork+0x24/0x30
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Moni Shoua <monis(a)mellanox.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/sw/rxe/rxe_qp.c | 12 ++++++++++--
drivers/infiniband/sw/rxe/rxe_verbs.h | 3 +++
2 files changed, 13 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/sw/rxe/rxe_qp.c
+++ b/drivers/infiniband/sw/rxe/rxe_qp.c
@@ -824,9 +824,9 @@ void rxe_qp_destroy(struct rxe_qp *qp)
}
/* called when the last reference to the qp is dropped */
-void rxe_qp_cleanup(struct rxe_pool_entry *arg)
+static void rxe_qp_do_cleanup(struct work_struct *work)
{
- struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem);
+ struct rxe_qp *qp = container_of(work, typeof(*qp), cleanup_work.work);
rxe_drop_all_mcast_groups(qp);
@@ -859,3 +859,11 @@ void rxe_qp_cleanup(struct rxe_pool_entr
kernel_sock_shutdown(qp->sk, SHUT_RDWR);
sock_release(qp->sk);
}
+
+/* called when the last reference to the qp is dropped */
+void rxe_qp_cleanup(struct rxe_pool_entry *arg)
+{
+ struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem);
+
+ execute_in_process_context(rxe_qp_do_cleanup, &qp->cleanup_work);
+}
--- a/drivers/infiniband/sw/rxe/rxe_verbs.h
+++ b/drivers/infiniband/sw/rxe/rxe_verbs.h
@@ -35,6 +35,7 @@
#define RXE_VERBS_H
#include <linux/interrupt.h>
+#include <linux/workqueue.h>
#include <rdma/rdma_user_rxe.h>
#include "rxe_pool.h"
#include "rxe_task.h"
@@ -281,6 +282,8 @@ struct rxe_qp {
struct timer_list rnr_nak_timer;
spinlock_t state_lock; /* guard requester and completer */
+
+ struct execute_work cleanup_work;
};
enum rxe_mem_state {
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch
queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch
queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch
queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch
This is a note to let you know that I've just added the patch titled
RDMA/rxe: Fix a race condition related to the QP error state
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 9 Jan 2018 11:23:40 -0800
Subject: RDMA/rxe: Fix a race condition related to the QP error state
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be upstream.
The following sequence:
* Change queue pair state into IB_QPS_ERR.
* Post a work request on the queue pair.
Triggers the following race condition in the rdma_rxe driver:
* rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function
that examines the QP send queue.
* rxe_post_send() posts a work request on the QP send queue.
If rxe_completer() runs prior to rxe_post_send(), it will drain the send
queue and the driver will assume no further action is necessary.
However, once we post the send to the send queue, because the queue is
in error, no send completion will ever happen and the send will get
stuck. In order to process the send, we need to make sure that
rxe_completer() gets run after a send is posted to a queue pair in an
error state. This patch ensures that happens.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Moni Shoua <monis(a)mellanox.com>
Cc: <stable(a)vger.kernel.org> # v4.8
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/sw/rxe/rxe_verbs.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/infiniband/sw/rxe/rxe_verbs.c
+++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
@@ -813,6 +813,8 @@ static int rxe_post_send_kernel(struct r
(queue_count(qp->sq.queue) > 1);
rxe_run_task(&qp->req.task, must_sched);
+ if (unlikely(qp->req.state == QP_STATE_ERROR))
+ rxe_run_task(&qp->comp.task, 1);
return err;
}
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch
queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch
queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch
queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch
This is a note to let you know that I've just added the patch titled
RDMA/rxe: Fix a race condition in rxe_requester()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-rxe-fix-a-race-condition-in-rxe_requester.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 65567e41219888feec72fee1de98ccf1efbbc16d Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Fri, 12 Jan 2018 15:11:58 -0800
Subject: RDMA/rxe: Fix a race condition in rxe_requester()
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 65567e41219888feec72fee1de98ccf1efbbc16d upstream.
The rxe driver works as follows:
* The send queue, receive queue and completion queues are implemented as
circular buffers.
* ib_post_send() and ib_post_recv() calls are serialized through a spinlock.
* Removing elements from various queues happens from tasklet
context. Tasklets are guaranteed to run on at most one CPU. This serializes
access to these queues. See also rxe_completer(), rxe_requester() and
rxe_responder().
* rxe_completer() processes the skbs queued onto qp->resp_pkts.
* rxe_requester() handles the send queue (qp->sq.queue).
* rxe_responder() processes the skbs queued onto qp->req_pkts.
Since rxe_drain_req_pkts() processes qp->req_pkts, calling
rxe_drain_req_pkts() from rxe_requester() is racy. Hence this patch.
Reported-by: Moni Shoua <monis(a)mellanox.com>
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/sw/rxe/rxe_loc.h | 1 -
drivers/infiniband/sw/rxe/rxe_req.c | 9 +--------
drivers/infiniband/sw/rxe/rxe_resp.c | 2 +-
3 files changed, 2 insertions(+), 10 deletions(-)
--- a/drivers/infiniband/sw/rxe/rxe_loc.h
+++ b/drivers/infiniband/sw/rxe/rxe_loc.h
@@ -237,7 +237,6 @@ int rxe_srq_from_attr(struct rxe_dev *rx
void rxe_release(struct kref *kref);
-void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify);
int rxe_completer(void *arg);
int rxe_requester(void *arg);
int rxe_responder(void *arg);
--- a/drivers/infiniband/sw/rxe/rxe_req.c
+++ b/drivers/infiniband/sw/rxe/rxe_req.c
@@ -594,15 +594,8 @@ int rxe_requester(void *arg)
rxe_add_ref(qp);
next_wqe:
- if (unlikely(!qp->valid)) {
- rxe_drain_req_pkts(qp, true);
+ if (unlikely(!qp->valid || qp->req.state == QP_STATE_ERROR))
goto exit;
- }
-
- if (unlikely(qp->req.state == QP_STATE_ERROR)) {
- rxe_drain_req_pkts(qp, true);
- goto exit;
- }
if (unlikely(qp->req.state == QP_STATE_RESET)) {
qp->req.wqe_index = consumer_index(qp->sq.queue);
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -1210,7 +1210,7 @@ static enum resp_states do_class_d1e_err
}
}
-void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify)
+static void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify)
{
struct sk_buff *skb;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch
queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch
queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch
queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch
This is a note to let you know that I've just added the patch titled
kselftest: fix OOM in memory compaction test
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kselftest-fix-oom-in-memory-compaction-test.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4c1baad223906943b595a887305f2e8124821dad Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 9 Jan 2018 17:26:24 +0100
Subject: kselftest: fix OOM in memory compaction test
From: Arnd Bergmann <arnd(a)arndb.de>
commit 4c1baad223906943b595a887305f2e8124821dad upstream.
Running the compaction_test sometimes results in out-of-memory
failures. When I debugged this, it turned out that the code to
reset the number of hugepages to the initial value is simply
broken since we write into an open sysctl file descriptor
multiple times without seeking back to the start.
Adding the lseek here fixes the problem.
Cc: stable(a)vger.kernel.org
Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
Link: https://bugs.linaro.org/show_bug.cgi?id=3145
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/vm/compaction_test.c | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/testing/selftests/vm/compaction_test.c
+++ b/tools/testing/selftests/vm/compaction_test.c
@@ -137,6 +137,8 @@ int check_compaction(unsigned long mem_f
printf("No of huge pages allocated = %d\n",
(atoi(nr_hugepages)));
+ lseek(fd, 0, SEEK_SET);
+
if (write(fd, initial_nr_hugepages, strlen(initial_nr_hugepages))
!= strlen(initial_nr_hugepages)) {
perror("Failed to write value to /proc/sys/vm/nr_hugepages\n");
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
This is a note to let you know that I've just added the patch titled
IB/umad: Fix use of unprotected device pointer
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-umad-fix-use-of-unprotected-device-pointer.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f23a5350e43c810ca36b26d4ed4ecd9a08686f47 Mon Sep 17 00:00:00 2001
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Date: Sun, 28 Jan 2018 11:25:29 +0200
Subject: IB/umad: Fix use of unprotected device pointer
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
commit f23a5350e43c810ca36b26d4ed4ecd9a08686f47 upstream.
The ib_write_umad() is protected by taking the umad file mutex.
However, it accesses file->port->ib_dev -- which is protected only by the
port's mutex (field file_mutex).
The ib_umad_remove_one() calls ib_umad_kill_port() which sets
port->ib_dev to NULL under the port mutex (NOT the file mutex).
It then sets the mad agent to "dead" under the umad file mutex.
This is a race condition -- because there is a window where
port->ib_dev is NULL, while the agent is not "dead".
As a result, we saw stack traces like:
[16490.678059] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
[16490.678246] IP: ib_umad_write+0x29c/0xa3a [ib_umad]
[16490.678333] PGD 0 P4D 0
[16490.678404] Oops: 0000 [#1] SMP PTI
[16490.678466] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) mlx4_en(OE) ptp pps_core mlx4_ib(OE-) ib_core(OE) mlx4_core(OE) mlx_compat
(OE) memtrack(OE) devlink mst_pciconf(OE) mst_pci(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache cfg80211 rfkill esp6_offload esp6 esp4_offload esp4 sunrpc kvm_intel kvm ppdev parport_pc irqbypass
parport joydev i2c_piix4 virtio_balloon cirrus drm_kms_helper ttm drm e1000 serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi qemu_fw_cfg [last unloaded: mlxfw]
[16490.679202] CPU: 4 PID: 3115 Comm: sminfo Tainted: G OE 4.14.13-300.fc27.x86_64 #1
[16490.679339] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
[16490.679477] task: ffff9cf753890000 task.stack: ffffaf70c26b0000
[16490.679571] RIP: 0010:ib_umad_write+0x29c/0xa3a [ib_umad]
[16490.679664] RSP: 0018:ffffaf70c26b3d90 EFLAGS: 00010202
[16490.679747] RAX: 0000000000000010 RBX: ffff9cf75610fd80 RCX: 0000000000000000
[16490.679856] RDX: 0000000000000001 RSI: 00007ffdf2bfd714 RDI: ffff9cf6bb2a9c00
In the above trace, ib_umad_write is trying to dereference the NULL
file->port->ib_dev pointer.
Fix this by using the agent's device pointer (the device field
in struct ib_mad_agent) -- which IS protected by the umad file mutex.
Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/user_mad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -500,7 +500,7 @@ static ssize_t ib_umad_write(struct file
}
memset(&ah_attr, 0, sizeof ah_attr);
- ah_attr.type = rdma_ah_find_type(file->port->ib_dev,
+ ah_attr.type = rdma_ah_find_type(agent->device,
file->port->port_num);
rdma_ah_set_dlid(&ah_attr, be16_to_cpu(packet->mad.hdr.lid));
rdma_ah_set_sl(&ah_attr, packet->mad.hdr.sl);
Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are
queue-4.14/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch
queue-4.14/ib-umad-fix-use-of-unprotected-device-pointer.patch
This is a note to let you know that I've just added the patch titled
IB/qib: Fix comparison error with qperf compare/swap test
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 Mon Sep 17 00:00:00 2001
From: Mike Marciniszyn <mike.marciniszyn(a)intel.com>
Date: Tue, 14 Nov 2017 04:34:52 -0800
Subject: IB/qib: Fix comparison error with qperf compare/swap test
From: Mike Marciniszyn <mike.marciniszyn(a)intel.com>
commit 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 upstream.
This failure exists with qib:
ver_rc_compare_swap:
mismatch, sequence 2, expected 123456789abcdef, got 0
The request builder was using the incorrect inlines to
build the request header resulting in incorrect data
in the atomic header.
Fix by using the appropriate inlines to create the request.
Fixes: 261a4351844b ("IB/qib,IB/hfi: Use core common header file")
Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/qib/qib_rc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/infiniband/hw/qib/qib_rc.c
+++ b/drivers/infiniband/hw/qib/qib_rc.c
@@ -434,13 +434,13 @@ no_flow_control:
qp->s_state = OP(COMPARE_SWAP);
put_ib_ateth_swap(wqe->atomic_wr.swap,
&ohdr->u.atomic_eth);
- put_ib_ateth_swap(wqe->atomic_wr.compare_add,
- &ohdr->u.atomic_eth);
+ put_ib_ateth_compare(wqe->atomic_wr.compare_add,
+ &ohdr->u.atomic_eth);
} else {
qp->s_state = OP(FETCH_ADD);
put_ib_ateth_swap(wqe->atomic_wr.compare_add,
&ohdr->u.atomic_eth);
- put_ib_ateth_swap(0, &ohdr->u.atomic_eth);
+ put_ib_ateth_compare(0, &ohdr->u.atomic_eth);
}
put_ib_ateth_vaddr(wqe->atomic_wr.remote_addr,
&ohdr->u.atomic_eth);
Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are
queue-4.14/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Date: Fri, 12 Jan 2018 07:58:40 +0200
Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream.
Allocating steerable UD QPs depends on having at least one IB port,
while releasing those QPs does not.
As a result, when there are only ETH ports, the IB (RoCE) driver
requests releasing a qp range whose base qp is zero, with
qp count zero.
When SR-IOV is enabled, and the VF driver is running on a VM over
a hypervisor which treats such qp release calls as errors
(rather than NOPs), we see lines in the VM message log like:
mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0
Fix this by adding a check for a zero count in mlx4_release_qp_range()
(which thus treats releasing 0 qps as a nop), and eliminating the
check for device managed flow steering when releasing steerable UD QPs.
(Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it
remains NULL when steerable UD QPs are not allocated).
Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device")
Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/main.c | 13 +++++--------
drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++
2 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2972,9 +2972,8 @@ err_steer_free_bitmap:
kfree(ibdev->ib_uc_qpns_bitmap);
err_steer_qp_release:
- if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED)
- mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
- ibdev->steer_qpn_count);
+ mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
+ ibdev->steer_qpn_count);
err_counter:
for (i = 0; i < ibdev->num_ports; ++i)
mlx4_ib_delete_counters_table(ibdev, &ibdev->counters_table[i]);
@@ -3079,11 +3078,9 @@ static void mlx4_ib_remove(struct mlx4_d
ibdev->iboe.nb.notifier_call = NULL;
}
- if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) {
- mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
- ibdev->steer_qpn_count);
- kfree(ibdev->ib_uc_qpns_bitmap);
- }
+ mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
+ ibdev->steer_qpn_count);
+ kfree(ibdev->ib_uc_qpns_bitmap);
iounmap(ibdev->uar_map);
for (p = 0; p < ibdev->num_ports; ++p)
--- a/drivers/net/ethernet/mellanox/mlx4/qp.c
+++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
@@ -287,6 +287,9 @@ void mlx4_qp_release_range(struct mlx4_d
u64 in_param = 0;
int err;
+ if (!cnt)
+ return;
+
if (mlx4_is_mfunc(dev)) {
set_param_l(&in_param, base_qpn);
set_param_h(&in_param, cnt);
Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are
queue-4.14/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch
queue-4.14/ib-umad-fix-use-of-unprotected-device-pointer.patch
This is a note to let you know that I've just added the patch titled
IB/core: Fix two kernel warnings triggered by rxe registration
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 02ee9da347873699603d9ce0112a80b5dd69dea1 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 3 Jan 2018 13:28:18 -0800
Subject: IB/core: Fix two kernel warnings triggered by rxe registration
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 02ee9da347873699603d9ce0112a80b5dd69dea1 upstream.
Eliminate the WARN_ONs that create following two warnings when
registering an rxe device:
WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/device.c:449 ib_register_device+0x591/0x640 [ib_core]
CPU: 2 PID: 1005 Comm: run_tests Not tainted 4.15.0-rc4-dbg+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:ib_register_device+0x591/0x640 [ib_core]
Call Trace:
rxe_register_device+0x3c6/0x470 [rdma_rxe]
rxe_add+0x543/0x5e0 [rdma_rxe]
rxe_net_add+0x37/0xb0 [rdma_rxe]
rxe_param_set_add+0x5a/0x120 [rdma_rxe]
param_attr_store+0x5e/0xc0
module_attr_store+0x19/0x30
sysfs_kf_write+0x3d/0x50
kernfs_fop_write+0x116/0x1a0
__vfs_write+0x23/0x120
vfs_write+0xbe/0x1b0
SyS_write+0x44/0xa0
entry_SYSCALL_64_fastpath+0x23/0x9a
WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/sysfs.c:1279 ib_device_register_sysfs+0x11d/0x160 [ib_core]
CPU: 2 PID: 1005 Comm: run_tests Tainted: G W 4.15.0-rc4-dbg+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:ib_device_register_sysfs+0x11d/0x160 [ib_core]
Call Trace:
ib_register_device+0x3f7/0x640 [ib_core]
rxe_register_device+0x3c6/0x470 [rdma_rxe]
rxe_add+0x543/0x5e0 [rdma_rxe]
rxe_net_add+0x37/0xb0 [rdma_rxe]
rxe_param_set_add+0x5a/0x120 [rdma_rxe]
param_attr_store+0x5e/0xc0
module_attr_store+0x19/0x30
sysfs_kf_write+0x3d/0x50
kernfs_fop_write+0x116/0x1a0
__vfs_write+0x23/0x120
vfs_write+0xbe/0x1b0
SyS_write+0x44/0xa0
entry_SYSCALL_64_fastpath+0x23/0x9a
The code should accept either a parent pointer or a fully specified DMA
specification without producing warnings.
Fixes: 99db9494035f ("IB/core: Remove ib_device.dma_device")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/device.c | 20 ++++++++++++++------
drivers/infiniband/core/sysfs.c | 1 -
2 files changed, 14 insertions(+), 7 deletions(-)
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -446,7 +446,6 @@ int ib_register_device(struct ib_device
struct ib_udata uhw = {.outlen = 0, .inlen = 0};
struct device *parent = device->dev.parent;
- WARN_ON_ONCE(!parent);
WARN_ON_ONCE(device->dma_device);
if (device->dev.dma_ops) {
/*
@@ -455,16 +454,25 @@ int ib_register_device(struct ib_device
* into device->dev.
*/
device->dma_device = &device->dev;
- if (!device->dev.dma_mask)
- device->dev.dma_mask = parent->dma_mask;
- if (!device->dev.coherent_dma_mask)
- device->dev.coherent_dma_mask =
- parent->coherent_dma_mask;
+ if (!device->dev.dma_mask) {
+ if (parent)
+ device->dev.dma_mask = parent->dma_mask;
+ else
+ WARN_ON_ONCE(true);
+ }
+ if (!device->dev.coherent_dma_mask) {
+ if (parent)
+ device->dev.coherent_dma_mask =
+ parent->coherent_dma_mask;
+ else
+ WARN_ON_ONCE(true);
+ }
} else {
/*
* The caller did not provide custom DMA operations. Use the
* DMA mapping operations of the parent device.
*/
+ WARN_ON_ONCE(!parent);
device->dma_device = parent;
}
--- a/drivers/infiniband/core/sysfs.c
+++ b/drivers/infiniband/core/sysfs.c
@@ -1262,7 +1262,6 @@ int ib_device_register_sysfs(struct ib_d
int ret;
int i;
- WARN_ON_ONCE(!device->dev.parent);
ret = dev_set_name(class_dev, "%s", device->name);
if (ret)
return ret;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch
queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch
queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch
queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch
This is a note to let you know that I've just added the patch titled
IB/core: Avoid a potential OOPs for an unused optional parameter
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2ff124d597c2df8696169ce0006fc974c49a4569 Mon Sep 17 00:00:00 2001
From: "Michael J. Ruhl" <michael.j.ruhl(a)intel.com>
Date: Thu, 1 Feb 2018 12:31:06 -0800
Subject: IB/core: Avoid a potential OOPs for an unused optional parameter
From: Michael J. Ruhl <michael.j.ruhl(a)intel.com>
commit 2ff124d597c2df8696169ce0006fc974c49a4569 upstream.
The ev_file is an optional parameter for CQ creation. If the parameter
is not passed, the ev_file pointer will be NULL. Using that pointer
to set the cq_context will result in an OOPs.
Verify that ev_file is not NULL before using.
Cc: <stable(a)vger.kernel.org> # 4.14.x
Fixes: 9ee79fce3642 ("IB/core: Add completion queue (cq) object actions")
Reviewed-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Reviewed-by: Ira Weiny <ira.weiny(a)intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/uverbs_std_types.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/uverbs_std_types.c
+++ b/drivers/infiniband/core/uverbs_std_types.c
@@ -315,7 +315,7 @@ static int uverbs_create_cq_handler(stru
cq->uobject = &obj->uobject;
cq->comp_handler = ib_uverbs_comp_handler;
cq->event_handler = ib_uverbs_cq_event_handler;
- cq->cq_context = &ev_file->ev_queue;
+ cq->cq_context = ev_file ? &ev_file->ev_queue : NULL;
obj->uobject.object = cq;
obj->uobject.user_handle = user_handle;
atomic_set(&cq->usecnt, 0);
Patches currently in stable-queue which might be from michael.j.ruhl(a)intel.com are
queue-4.14/ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch
queue-4.14/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Date: Fri, 12 Jan 2018 07:58:40 +0200
Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream.
Allocating steerable UD QPs depends on having at least one IB port,
while releasing those QPs does not.
As a result, when there are only ETH ports, the IB (RoCE) driver
requests releasing a qp range whose base qp is zero, with
qp count zero.
When SR-IOV is enabled, and the VF driver is running on a VM over
a hypervisor which treats such qp release calls as errors
(rather than NOPs), we see lines in the VM message log like:
mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0
Fix this by adding a check for a zero count in mlx4_release_qp_range()
(which thus treats releasing 0 qps as a nop), and eliminating the
check for device managed flow steering when releasing steerable UD QPs.
(Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it
remains NULL when steerable UD QPs are not allocated).
Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device")
Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/main.c | 13 +++++--------
drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++
2 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2348,9 +2348,8 @@ err_steer_free_bitmap:
kfree(ibdev->ib_uc_qpns_bitmap);
err_steer_qp_release:
- if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED)
- mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
- ibdev->steer_qpn_count);
+ mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
+ ibdev->steer_qpn_count);
err_counter:
for (; i; --i)
if (ibdev->counters[i - 1] != -1)
@@ -2452,11 +2451,9 @@ static void mlx4_ib_remove(struct mlx4_d
ibdev->iboe.nb.notifier_call = NULL;
}
- if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) {
- mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
- ibdev->steer_qpn_count);
- kfree(ibdev->ib_uc_qpns_bitmap);
- }
+ mlx4_qp_release_range(dev, ibdev->steer_qpn_base,
+ ibdev->steer_qpn_count);
+ kfree(ibdev->ib_uc_qpns_bitmap);
if (ibdev->iboe.nb_inet.notifier_call) {
if (unregister_inetaddr_notifier(&ibdev->iboe.nb_inet))
--- a/drivers/net/ethernet/mellanox/mlx4/qp.c
+++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
@@ -257,6 +257,9 @@ void mlx4_qp_release_range(struct mlx4_d
u64 in_param = 0;
int err;
+ if (!cnt)
+ return;
+
if (mlx4_is_mfunc(dev)) {
set_param_l(&in_param, base_qpn);
set_param_h(&in_param, cnt);
Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are
queue-3.18/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch
Various people have reported the Crucial MX100 512GB model not working
with LPM set to min_power. I've now received a report that it also does
not work with the new med_power_with_dipm level.
It does work with medium_power, but that has no measurable power-savings
and given the amount of people being bitten by the other levels not
working, this commit just disables LPM altogether.
Note all reporters of this have either the 512GB model (max capacity), or
are not specifying their SSD's size. So for now this quirk assumes this is
a problem with the 512GB model only.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=89261
Buglink: https://github.com/linrunner/TLP/issues/84
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/ata/libata-core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3c09122bf038..d8be0fe548f7 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4530,6 +4530,11 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
{ "PIONEER DVD-RW DVR-212D", NULL, ATA_HORKAGE_NOSETXFER },
{ "PIONEER DVD-RW DVR-216D", NULL, ATA_HORKAGE_NOSETXFER },
+ /* The 512GB version of the MX100 has both queued TRIM and LPM issues */
+ { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
--
2.14.3
This is a note to let you know that I've just added the patch titled
powerpc/64s: Simple RFI macro conversions
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-simple-rfi-macro-conversions.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 222f20f140623ef6033491d0103ee0875fe87d35 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 10 Jan 2018 03:07:15 +1100
Subject: powerpc/64s: Simple RFI macro conversions
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 222f20f140623ef6033491d0103ee0875fe87d35 upstream.
[just the top part of this commit, to fix a 4.9.y build error - gregkh]
This commit does simple conversions of rfi/rfid to the new macros that
include the expected destination context. By simple we mean cases
where there is a single well known destination context, and it's
simply a matter of substituting the instruction for the appropriate
macro.
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Cc: Yves-Alexis Perez <corsac(a)debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/entry_64.S | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -39,6 +39,11 @@
#include <asm/tm.h>
#include <asm/ppc-opcode.h>
#include <asm/export.h>
+#ifdef CONFIG_PPC_BOOK3S
+#include <asm/exception-64s.h>
+#else
+#include <asm/exception-64e.h>
+#endif
/*
* System calls.
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/powerpc-64s-simple-rfi-macro-conversions.patch
This is a note to let you know that I've just added the patch titled
scsi: smartpqi: allow static build ("built-in")
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-smartpqi-allow-static-build-built-in.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a Mon Sep 17 00:00:00 2001
From: Steffen Weber <steffen.weber(a)gmail.com>
Date: Tue, 2 Jan 2018 19:24:09 +0100
Subject: scsi: smartpqi: allow static build ("built-in")
From: Steffen Weber <steffen.weber(a)gmail.com>
commit dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a upstream.
If CONFIG_SCSI_SMARTPQI=y then don't build this driver as a module.
Signed-off-by: Steffen Weber <steffen.weber(a)gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/smartpqi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/smartpqi/Makefile
+++ b/drivers/scsi/smartpqi/Makefile
@@ -1,3 +1,3 @@
ccflags-y += -I.
-obj-m += smartpqi.o
+obj-$(CONFIG_SCSI_SMARTPQI) += smartpqi.o
smartpqi-objs := smartpqi_init.o smartpqi_sis.o smartpqi_sas_transport.o
Patches currently in stable-queue which might be from steffen.weber(a)gmail.com are
queue-4.9/scsi-smartpqi-allow-static-build-built-in.patch
Hi Greg,
could you please apply commit dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a
("scsi: smartpqi: allow static build") to 4.15-table, 4.14-stable and
4.9-stable?
(The smartpqi driver did not exist 4.4-stable, so there's no need to
go back further.)
Thanks,
Steffen
This is a note to let you know that I've just added the patch titled
scsi: smartpqi: allow static build ("built-in")
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-smartpqi-allow-static-build-built-in.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a Mon Sep 17 00:00:00 2001
From: Steffen Weber <steffen.weber(a)gmail.com>
Date: Tue, 2 Jan 2018 19:24:09 +0100
Subject: scsi: smartpqi: allow static build ("built-in")
From: Steffen Weber <steffen.weber(a)gmail.com>
commit dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a upstream.
If CONFIG_SCSI_SMARTPQI=y then don't build this driver as a module.
Signed-off-by: Steffen Weber <steffen.weber(a)gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/smartpqi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/smartpqi/Makefile
+++ b/drivers/scsi/smartpqi/Makefile
@@ -1,3 +1,3 @@
ccflags-y += -I.
-obj-m += smartpqi.o
+obj-$(CONFIG_SCSI_SMARTPQI) += smartpqi.o
smartpqi-objs := smartpqi_init.o smartpqi_sis.o smartpqi_sas_transport.o
Patches currently in stable-queue which might be from steffen.weber(a)gmail.com are
queue-4.15/scsi-smartpqi-allow-static-build-built-in.patch
This is a note to let you know that I've just added the patch titled
scsi: smartpqi: allow static build ("built-in")
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-smartpqi-allow-static-build-built-in.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a Mon Sep 17 00:00:00 2001
From: Steffen Weber <steffen.weber(a)gmail.com>
Date: Tue, 2 Jan 2018 19:24:09 +0100
Subject: scsi: smartpqi: allow static build ("built-in")
From: Steffen Weber <steffen.weber(a)gmail.com>
commit dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a upstream.
If CONFIG_SCSI_SMARTPQI=y then don't build this driver as a module.
Signed-off-by: Steffen Weber <steffen.weber(a)gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/smartpqi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/smartpqi/Makefile
+++ b/drivers/scsi/smartpqi/Makefile
@@ -1,3 +1,3 @@
ccflags-y += -I.
-obj-m += smartpqi.o
+obj-$(CONFIG_SCSI_SMARTPQI) += smartpqi.o
smartpqi-objs := smartpqi_init.o smartpqi_sis.o smartpqi_sas_transport.o
Patches currently in stable-queue which might be from steffen.weber(a)gmail.com are
queue-4.14/scsi-smartpqi-allow-static-build-built-in.patch
On Fri, Feb 16, 2018 at 11:03 PM, Steven Rostedt <rostedt(a)goodmis.org> wrote:
> On Fri, 16 Feb 2018 22:41:11 +0100
> Arnd Bergmann <arnd(a)arndb.de> wrote:
>
>> This can easily double the time for compiling a driver but does not
>> provide any benefit for the compile tester, so it's better left disabled.
>>
>> In addition, any 'inline' function that is not also 'static' and that
>> contains an 'if' causes a warning like
>>
>> include/linux/string.h:212:2: note: in expansion of macro 'if'
>> if (strscpy(p, q, p_size < q_size ? p_size : q_size) < 0)
>> ^~
>> include/linux/compiler.h:162:4: warning: '______f' is static but declared in inline function 'strcpy' which is not static
>>
>> without this patch, and I could not come up with a nice fix for that.
>> In combination with my patch to always enable 'CONFIG_COMPILE_TEST'
>> during 'randconfig' builds, we can at least hide these warnings for
>> most users.
>
> This looks like it fixes the same issue that was already fixed and is
> in Linus's tree.
>
> http://lkml.kernel.org/r/9199446b-a141-c0c3-9678-a3f9107f2750@infradead.org
>
> See commit 68e76e034b6b1 ("tracing: Prevent PROFILE_ALL_BRANCHES when
> FORTIFY_SOURCE=y")
Ah, right. I missed that when I wrote the new changelog text for this old
patch of mine. It also means I should rebase the patch so it applies
on mainline, as I still want PROFILE_ALL_BRANCHES to be disabled
in COMPILE_TEST kernels for the build speed aspect.
Greg, could you add the 68e76e034b6b1 commit to 4.14-stable and
4.15-stable in the meantime?
Arnd
This is a note to let you know that I've just added the patch titled
tracing: Prevent PROFILE_ALL_BRANCHES when FORTIFY_SOURCE=y
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tracing-prevent-profile_all_branches-when-fortify_source-y.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 68e76e034b6b1c1ce2eece1ab8ae4008e14be470 Mon Sep 17 00:00:00 2001
From: Randy Dunlap <rdunlap(a)infradead.org>
Date: Mon, 15 Jan 2018 11:07:27 -0800
Subject: tracing: Prevent PROFILE_ALL_BRANCHES when FORTIFY_SOURCE=y
From: Randy Dunlap <rdunlap(a)infradead.org>
commit 68e76e034b6b1c1ce2eece1ab8ae4008e14be470 upstream.
I regularly get 50 MB - 60 MB files during kernel randconfig builds.
These large files mostly contain (many repeats of; e.g., 124,594):
In file included from ../include/linux/string.h:6:0,
from ../include/linux/uuid.h:20,
from ../include/linux/mod_devicetable.h:13,
from ../scripts/mod/devicetable-offsets.c:3:
../include/linux/compiler.h:64:4: warning: '______f' is static but declared in inline function 'strcpy' which is not static [enabled by default]
______f = { \
^
../include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if'
^
../include/linux/string.h:425:2: note: in expansion of macro 'if'
if (p_size == (size_t)-1 && q_size == (size_t)-1)
^
This only happens when CONFIG_FORTIFY_SOURCE=y and
CONFIG_PROFILE_ALL_BRANCHES=y, so prevent PROFILE_ALL_BRANCHES if
FORTIFY_SOURCE=y.
Link: http://lkml.kernel.org/r/9199446b-a141-c0c3-9678-a3f9107f2750@infradead.org
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -343,7 +343,7 @@ config PROFILE_ANNOTATED_BRANCHES
on if you need to profile the system's use of these macros.
config PROFILE_ALL_BRANCHES
- bool "Profile all if conditionals"
+ bool "Profile all if conditionals" if !FORTIFY_SOURCE
select TRACE_BRANCH_PROFILING
help
This tracer profiles all branch conditions. Every if ()
Patches currently in stable-queue which might be from rdunlap(a)infradead.org are
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
Tree/Branch: v4.15.4
Git describe: v4.15.4
Commit: bb61956d9d Linux 4.15.4
Build Time: 112 min 28 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm64-allmodconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
1 ../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Tree/Branch: v4.14.20
Git describe: v4.14.20
Commit: 7e83b2ff48 Linux 4.14.20
Build Time: 109 min 30 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm64-allmodconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
1 ../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/sched/mm.h:188:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Hi Ingo,
Here is a small pile of cleanups and fixes for nospec.h after inspection
from Linus, Rasmus, and Christian. Full changelogs below:
These have received a build success notification from 0day across 126
configs.
---
Dan Williams (2):
nospec: Kill array_index_nospec_mask_check()
nospec: Include asm/barrier.h dependency
Rasmus Villemoes (1):
nospec: Allow index argument to have const-qualified type
include/linux/nospec.h | 26 +++-----------------------
1 file changed, 3 insertions(+), 23 deletions(-)
--
nospec: Kill array_index_nospec_mask_check()
There are multiple problems with the dynamic sanity checking in
array_index_nospec_mask_check():
* It causes unnecessary overhead in the 32-bit case since integer sized
@index values will no longer cause the check to be compiled away like
in the 64-bit case.
* In the 32-bit case it may trigger with user controllable input when
the expectation is that should only trigger during development of new
kernel enabling.
* The macro reuses the input parameter in multiple locations which is
broken if someone passes an expression like 'index++' to
array_index_nospec().
nospec: Allow index argument to have const-qualified type
The last expression in a statement expression need not be a bare
variable, quoting gcc docs
The last thing in the compound statement should be an expression
followed by a semicolon; the value of this subexpression serves as the
value of the entire construct.
and we already use that in e.g. the min/max macros which end with a
ternary expression.
This way, we can allow index to have const-qualified type, which will in
some cases avoid the need for introducing a local copy of index of
non-const qualified type. That, in turn, can prevent readers not
familiar with the internals of array_index_nospec from wondering about
the seemingly redundant extra variable, and I think that's worthwhile
considering how confusing the whole _nospec business is.
The expression _i&_mask has type unsigned long (since that is the type
of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to
that), so in order not to change the type of the whole expression, add
a cast back to typeof(_i).
nospec: Include asm/barrier.h dependency
The nospec.h header expects the per-architecture header file
asm/barrier.h to optionally define array_index_mask_nospec(). Include
that dependency to prevent inadvertent fallback to the default
array_index_mask_nospec() implementation. The default implementation may
not provide a full mitigation on architectures that perform data value
speculation.
The patch titled
Subject: mm: don't defer struct page initialization for Xen pv guests
has been added to the -mm tree. Its filename is
mm-dont-defer-struct-page-initialization-for-xen-pv-guests.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-dont-defer-struct-page-initiali…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-dont-defer-struct-page-initiali…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Juergen Gross <jgross(a)suse.com>
Subject: mm: don't defer struct page initialization for Xen pv guests
f7f99100d8d95d ("mm: stop zeroing memory during allocation in vmemmap")
broke Xen pv domains in some configurations, as the "Pinned" information
in struct page of early page tables could get lost. This will lead to the
kernel trying to write directly into the page tables instead of asking the
hypervisor to do so. The result is a crash like the following:
[ 0.004000] BUG: unable to handle kernel paging request at ffff8801ead19008
[ 0.004000] IP: xen_set_pud+0x4e/0xd0
[ 0.004000] PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065
[ 0.004000] Oops: 0003 [#1] PREEMPT SMP
[ 0.004000] Modules linked in:
[ 0.004000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ #271
[ 0.004000] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014
[ 0.004000] task: ffffffff81c10480 task.stack: ffffffff81c00000
[ 0.004000] RIP: e030:xen_set_pud+0x4e/0xd0
[ 0.004000] RSP: e02b:ffffffff81c03cd8 EFLAGS: 00010246
[ 0.004000] RAX: 002ffff800000800 RBX: ffff88020fd31000 RCX: 0000000000000000
[ 0.004000] RDX: ffffea0000000000 RSI: 00000001b8308067 RDI: ffff8801ead19008
[ 0.004000] RBP: ffff8801ead19008 R08: aaaaaaaaaaaaaaaa R09: 00000000063f4c80
[ 0.004000] R10: aaaaaaaaaaaaaaaa R11: 0720072007200720 R12: 00000001b8308067
[ 0.004000] R13: ffffffff81c8a9cc R14: ffff88018fd31000 R15: 000077ff80000000
[ 0.004000] FS: 0000000000000000(0000) GS:ffff88020f600000(0000) knlGS:0000000000000000
[ 0.004000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.004000] CR2: ffff8801ead19008 CR3: 0000000001c09000 CR4: 0000000000042660
[ 0.004000] Call Trace:
[ 0.004000] __pmd_alloc+0x128/0x140
[ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0
[ 0.004000] ioremap_page_range+0x3f4/0x410
[ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0
[ 0.004000] __ioremap_caller+0x1c3/0x2e0
[ 0.004000] acpi_os_map_iomem+0x175/0x1b0
[ 0.004000] acpi_tb_acquire_table+0x39/0x66
[ 0.004000] acpi_tb_validate_table+0x44/0x7c
[ 0.004000] acpi_tb_verify_temp_table+0x45/0x304
[ 0.004000] ? acpi_ut_acquire_mutex+0x12a/0x1c2
[ 0.004000] acpi_reallocate_root_table+0x12d/0x141
[ 0.004000] acpi_early_init+0x4d/0x10a
[ 0.004000] start_kernel+0x3eb/0x4a1
[ 0.004000] ? set_init_arg+0x55/0x55
[ 0.004000] xen_start_kernel+0x528/0x532
[ 0.004000] Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3
[ 0.004000] RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8
[ 0.004000] CR2: ffff8801ead19008
[ 0.004000] ---[ end trace 38eca2e56f1b642e ]---
Avoid this problem by not deferring struct page initialization when
running as Xen pv guest.
Link: http://lkml.kernel.org/r/20180216154101.22865-1-jgross@suse.com
Fixes: f7f99100d8d95d ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Steven Sistare <steven.sistare(a)oracle.com>
Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com>
Cc: Bob Picco <bob.picco(a)oracle.com>
Cc: <stable(a)vger.kernel.org> [4.15.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests mm/page_alloc.c
--- a/mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests
+++ a/mm/page_alloc.c
@@ -347,6 +347,9 @@ static inline bool update_defer_init(pg_
/* Always populate low zones for address-constrained allocations */
if (zone_end < pgdat_end_pfn(pgdat))
return true;
+ /* Xen PV domains need page structures early */
+ if (xen_pv_domain())
+ return true;
(*nr_initialised)++;
if ((*nr_initialised > pgdat->static_init_pgcnt) &&
(pfn & (PAGES_PER_SECTION - 1)) == 0) {
_
Patches currently in -mm which might be from jgross(a)suse.com are
mm-dont-defer-struct-page-initialization-for-xen-pv-guests.patch
From: Casey Leedom <leedom(a)chelsio.com>
We've run into a problem where our device is attached
to a Virtual Machine and the use of the new pci_set_vpd_size()
API doesn't help. The VM kernel has been informed that
the accesses are okay, but all of the actual VPD Capability
Accesses are trapped down into the KVM Hypervisor where it
goes ahead and imposes the silent denials.
The right idea is to follow the kernel.org
commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
to establish a PCI Quirk for our T3-based adapters. This commit
extends that PCI Quirk to cover Chelsio T4 devices and later.
The advantage of this approach is that the VPD Size gets set early
in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
driver even be available in the Base OS/Hypervisor. Thus PF4 can
be exported to a Virtual Machine and everything should work.
Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
Cc: <stable(a)vger.kernel.org> # v4.9+
Signed-off-by: Casey Leedom <leedom(a)chelsio.com>
Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 --------
drivers/pci/quirks.c | 39 ++++++++++++++++++------------
2 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 047609e..920bccd 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -2637,7 +2637,6 @@ void t4_get_regs(struct adapter *adap, void *buf, size_t buf_size)
}
#define EEPROM_STAT_ADDR 0x7bfc
-#define VPD_SIZE 0x800
#define VPD_BASE 0x400
#define VPD_BASE_OLD 0
#define VPD_LEN 1024
@@ -2704,15 +2703,6 @@ int t4_get_raw_vpd_params(struct adapter *adapter, struct vpd_params *p)
if (!vpd)
return -ENOMEM;
- /* We have two VPD data structures stored in the adapter VPD area.
- * By default, Linux calculates the size of the VPD area by traversing
- * the first VPD area at offset 0x0, so we need to tell the OS what
- * our real VPD size is.
- */
- ret = pci_set_vpd_size(adapter->pdev, VPD_SIZE);
- if (ret < 0)
- goto out;
-
/* Card information normally starts at VPD_BASE but early cards had
* it at 0.
*/
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index fc73401..8b14bd3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3419,22 +3419,29 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
{
- pci_set_vpd_size(dev, 8192);
-}
-
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+ int chip = (dev->device & 0xf000) >> 12;
+ int func = (dev->device & 0x0f00) >> 8;
+ int prod = (dev->device & 0x00ff) >> 0;
+
+ /*
+ * If this is a T3-based adapter, there's a 1KB VPD area at offset
+ * 0xc00 which contains the preferred VPD values. If this is a T4 or
+ * later based adapter, the special VPD is at offset 0x400 for the
+ * Physical Functions (the SR-IOV Virtual Functions have no VPD
+ * Capabilities). The PCI VPD Access core routines will normally
+ * compute the size of the VPD by parsing the VPD Data Structure at
+ * offset 0x000. This will result in silent failures when attempting
+ * to accesses these other VPD areas which are beyond those computed
+ * limits.
+ */
+ if (chip == 0x0 && prod >= 0x20)
+ pci_set_vpd_size(dev, 8192);
+ else if (chip >= 0x4 && func < 0x8)
+ pci_set_vpd_size(dev, 2048);
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+ quirk_chelsio_extend_vpd);
#ifdef CONFIG_ACPI
/*
--
2.1.0
We get a warning about some slow configurations in randconfig kernels:
mm/memory.c:83:2: error: #warning Unfortunate NUMA and NUMA Balancing config, growing page-frame for last_cpupid. [-Werror=cpp]
The warning is reasonable by itself, but gets in the way of
randconfig build testing, so I'm hiding it whenever CONFIG_COMPILE_TEST
is set. The warning was added in 2013 in commit 75980e97dacc ("mm: fold
page->_last_nid into page->flags where possible").
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
mm/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index a728bed16c20..fc7779165dcf 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -81,7 +81,7 @@
#include "internal.h"
-#ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
+#if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST)
#warning Unfortunate NUMA and NUMA Balancing config, growing page-frame for last_cpupid.
#endif
--
2.9.0
This is the start of the stable review cycle for the 4.9.81 release.
There are 92 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 Sun Feb 11 13:39:04 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.81-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.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.9.81-rc1
Borislav Petkov <bp(a)suse.de>
x86/microcode: Do the family check first
Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
drm: rcar-du: Fix race condition when disabling planes at CRTC stop
Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
drm: rcar-du: Use the VBK interrupt for vblank events
Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
ASoC: rsnd: avoid duplicate free_irq()
Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
ASoC: rsnd: don't call free_irq() on Parent SSI
Julian Scheel <julian(a)jusst.de>
ASoC: simple-card: Fix misleading error message
Robert Baronescu <robert.baronescu(a)nxp.com>
crypto: tcrypt - fix S/G table for test_aead_speed()
KarimAllah Ahmed <karahmed(a)amazon.de>
KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL
KarimAllah Ahmed <karahmed(a)amazon.de>
KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL
KarimAllah Ahmed <karahmed(a)amazon.de>
KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES
Ashok Raj <ashok.raj(a)intel.com>
KVM/x86: Add IBPB support
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: VMX: make MSR bitmaps per-VCPU
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: VMX: introduce alloc_loaded_vmcs
Jim Mattson <jmattson(a)google.com>
KVM: nVMX: Eliminate vmcs02 pool
David Matlack <dmatlack(a)google.com>
KVM: nVMX: mark vmcs12 pages dirty on L2 exit
David Hildenbrand <david(a)redhat.com>
KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail
David Hildenbrand <david(a)redhat.com>
KVM: nVMX: kmap() can't fail
Darren Kenny <darren.kenny(a)oracle.com>
x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL
Arnd Bergmann <arnd(a)arndb.de>
x86/pti: Mark constant arrays as __initconst
KarimAllah Ahmed <karahmed(a)amazon.de>
x86/spectre: Simplify spectre_v2 command line parsing
David Woodhouse <dwmw(a)amazon.co.uk>
x86/retpoline: Avoid retpolines for built-in __init functions
Dan Williams <dan.j.williams(a)intel.com>
x86/kvm: Update spectre-v1 mitigation
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/paravirt: Remove 'noreplace-paravirt' cmdline option
David Woodhouse <dwmw(a)amazon.co.uk>
x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel
Colin Ian King <colin.king(a)canonical.com>
x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable"
Dan Williams <dan.j.williams(a)intel.com>
x86/spectre: Report get_user mitigation for spectre_v1
Dan Williams <dan.j.williams(a)intel.com>
nl80211: Sanitize array index in parse_txq_params
Dan Williams <dan.j.williams(a)intel.com>
vfs, fdtable: Prevent bounds-check bypass via speculative execution
Dan Williams <dan.j.williams(a)intel.com>
x86/syscall: Sanitize syscall table de-references under speculation
Dan Williams <dan.j.williams(a)intel.com>
x86/get_user: Use pointer masking to limit speculation
Dan Williams <dan.j.williams(a)intel.com>
x86/uaccess: Use __uaccess_begin_nospec() and uaccess_try_nospec
Dan Williams <dan.j.williams(a)intel.com>
x86/usercopy: Replace open coded stac/clac with __uaccess_{begin, end}
Dan Williams <dan.j.williams(a)intel.com>
x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
Dan Williams <dan.j.williams(a)intel.com>
x86: Introduce barrier_nospec
Dan Williams <dan.j.williams(a)intel.com>
x86: Implement array_index_mask_nospec
Dan Williams <dan.j.williams(a)intel.com>
array_index_nospec: Sanitize speculative array de-references
Mark Rutland <mark.rutland(a)arm.com>
Documentation: Document array_index_nospec
Andy Lutomirski <luto(a)kernel.org>
x86/asm: Move 'status' from thread_struct to thread_info
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Push extra regs right away
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Remove the SYSCALL64 fast path
Dou Liyang <douly.fnst(a)cn.fujitsu.com>
x86/spectre: Check CONFIG_RETPOLINE in command line parser
Borislav Petkov <bp(a)alien8.de>
x86/retpoline: Simplify vmexit_fill_RSB()
David Woodhouse <dwmw(a)amazon.co.uk>
x86/cpufeatures: Clean up Spectre v2 related CPUID flags
Thomas Gleixner <tglx(a)linutronix.de>
x86/cpu/bugs: Make retpoline module warning conditional
Borislav Petkov <bp(a)suse.de>
x86/bugs: Drop one "mitigation" from dmesg
Borislav Petkov <bp(a)suse.de>
x86/nospec: Fix header guards names
Borislav Petkov <bp(a)suse.de>
x86/alternative: Print unadorned pointers
David Woodhouse <dwmw(a)amazon.co.uk>
x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support
David Woodhouse <dwmw(a)amazon.co.uk>
x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes
David Woodhouse <dwmw(a)amazon.co.uk>
x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
David Woodhouse <dwmw(a)amazon.co.uk>
x86/msr: Add definitions for new speculation control MSRs
David Woodhouse <dwmw(a)amazon.co.uk>
x86/cpufeatures: Add AMD feature bits for Speculation Control
David Woodhouse <dwmw(a)amazon.co.uk>
x86/cpufeatures: Add Intel feature bits for Speculation Control
David Woodhouse <dwmw(a)amazon.co.uk>
x86/cpufeatures: Add CPUID_7_EDX CPUID leaf
Andi Kleen <ak(a)linux.intel.com>
module/retpoline: Warn about missing retpoline in module
Peter Zijlstra <peterz(a)infradead.org>
KVM: VMX: Make indirect call speculation safe
Peter Zijlstra <peterz(a)infradead.org>
KVM: x86: Make indirect calls in emulator speculation safe
Waiman Long <longman(a)redhat.com>
x86/retpoline: Remove the esp/rsp thunk
Eric Biggers <ebiggers(a)google.com>
KEYS: encrypted: fix buffer overread in valid_master_desc()
Takashi Iwai <tiwai(a)suse.de>
b43: Add missing MODULE_FIRMWARE()
Jesse Chan <jc(a)linux.com>
media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Borislav Petkov <bp(a)suse.de>
x86/microcode/AMD: Do not load when running on a hypervisor
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/asm: Fix inline asm call constraints for GCC 4.4
Eric Dumazet <edumazet(a)google.com>
soreuseport: fix mem leak in reuseport_add_sock()
Martin KaFai Lau <kafai(a)fb.com>
ipv6: Fix SO_REUSEPORT UDP socket with implicit sk_ipv6only
Paolo Abeni <pabeni(a)redhat.com>
cls_u32: add missing RCU annotation.
Neal Cardwell <ncardwell(a)google.com>
tcp_bbr: fix pacing_gain to always be unity when using lt_bw
Jason Wang <jasowang(a)redhat.com>
vhost_net: stop device during reset owner
Li RongQing <lirongqing(a)baidu.com>
tcp: release sk_frag.page in tcp_disconnect
Chunhao Lin <hau(a)realtek.com>
r8169: fix RTL8168EP take too long to complete driver initialization.
Kristian Evensen <kristian.evensen(a)gmail.com>
qmi_wwan: Add support for Quectel EP06
Junxiao Bi <junxiao.bi(a)oracle.com>
qlcnic: fix deadlock bug
Eric Dumazet <edumazet(a)google.com>
net: igmp: add a missing rcu locking section
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
ip6mr: fix stale iterator
Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
serial: core: mark port as initialized after successful IRQ change
Hugh Dickins <hughd(a)google.com>
kaiser: allocate pgd with order 0 when pti=off
Dave Hansen <dave.hansen(a)linux.intel.com>
x86/pti: Make unpoison of pgd for trusted boot work for real
Hugh Dickins <hughd(a)google.com>
kaiser: fix intel_bts perf crashes
Jesse Chan <jc(a)linux.com>
ASoC: pcm512x: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Jesse Chan <jc(a)linux.com>
pinctrl: pxa: pxa2xx: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Jesse Chan <jc(a)linux.com>
auxdisplay: img-ascii-lcd: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/64s: Allow control of RFI flush via debugfs
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/64s: Wire up cpu_show_meltdown()
Oliver O'Halloran <oohall(a)gmail.com>
powerpc/powernv: Check device-tree for RFI flush settings
Michael Neuling <mikey(a)neuling.org>
powerpc/pseries: Query hypervisor for RFI flush settings
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/64s: Support disabling RFI flush with no_rfi_flush and nopti
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/64s: Add support for RFI flush of L1-D cache
Nicholas Piggin <npiggin(a)gmail.com>
powerpc/64s: Convert slb_miss_common to use RFI_TO_USER/KERNEL
Nicholas Piggin <npiggin(a)gmail.com>
powerpc/64: Convert the syscall exit path to use RFI_TO_USER/KERNEL
Nicholas Piggin <npiggin(a)gmail.com>
powerpc/64: Convert fast_exception_return to use RFI_TO_USER/KERNEL
Nicholas Piggin <npiggin(a)gmail.com>
powerpc/64: Add macros for annotating the destination of rfid/hrfid
Michael Neuling <mikey(a)neuling.org>
powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper
-------------
Diffstat:
Documentation/kernel-parameters.txt | 2 -
Documentation/speculation.txt | 90 +++
Makefile | 4 +-
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/exception-64e.h | 6 +
arch/powerpc/include/asm/exception-64s.h | 53 ++
arch/powerpc/include/asm/feature-fixups.h | 15 +
arch/powerpc/include/asm/hvcall.h | 17 +
arch/powerpc/include/asm/paca.h | 10 +
arch/powerpc/include/asm/plpar_wrappers.h | 14 +
arch/powerpc/include/asm/setup.h | 13 +
arch/powerpc/kernel/asm-offsets.c | 4 +
arch/powerpc/kernel/entry_64.S | 30 +-
arch/powerpc/kernel/exceptions-64s.S | 108 ++-
arch/powerpc/kernel/setup_64.c | 139 ++++
arch/powerpc/kernel/vmlinux.lds.S | 9 +
arch/powerpc/lib/feature-fixups.c | 42 ++
arch/powerpc/platforms/powernv/setup.c | 50 ++
arch/powerpc/platforms/pseries/setup.c | 35 +
arch/x86/entry/common.c | 9 +-
arch/x86/entry/entry_32.S | 3 +-
arch/x86/entry/entry_64.S | 134 +---
arch/x86/entry/syscall_64.c | 7 +-
arch/x86/events/intel/bts.c | 44 +-
arch/x86/include/asm/asm-prototypes.h | 4 +-
arch/x86/include/asm/asm.h | 4 +-
arch/x86/include/asm/barrier.h | 28 +
arch/x86/include/asm/cpufeature.h | 7 +-
arch/x86/include/asm/cpufeatures.h | 22 +-
arch/x86/include/asm/disabled-features.h | 3 +-
arch/x86/include/asm/intel-family.h | 7 +-
arch/x86/include/asm/msr-index.h | 12 +
arch/x86/include/asm/msr.h | 3 +-
arch/x86/include/asm/nospec-branch.h | 91 +--
arch/x86/include/asm/pgalloc.h | 11 -
arch/x86/include/asm/pgtable.h | 6 +
arch/x86/include/asm/processor.h | 2 -
arch/x86/include/asm/required-features.h | 3 +-
arch/x86/include/asm/syscall.h | 6 +-
arch/x86/include/asm/thread_info.h | 3 +-
arch/x86/include/asm/uaccess.h | 15 +-
arch/x86/include/asm/uaccess_32.h | 12 +-
arch/x86/include/asm/uaccess_64.h | 12 +-
arch/x86/kernel/alternative.c | 28 +-
arch/x86/kernel/cpu/bugs.c | 128 +++-
arch/x86/kernel/cpu/common.c | 70 +-
arch/x86/kernel/cpu/intel.c | 66 ++
arch/x86/kernel/cpu/microcode/core.c | 47 +-
arch/x86/kernel/cpu/scattered.c | 2 -
arch/x86/kernel/process_64.c | 4 +-
arch/x86/kernel/ptrace.c | 2 +-
arch/x86/kernel/signal.c | 2 +-
arch/x86/kernel/tboot.c | 10 +
arch/x86/kvm/cpuid.c | 21 +-
arch/x86/kvm/cpuid.h | 31 +
arch/x86/kvm/emulate.c | 10 +-
arch/x86/kvm/svm.c | 116 ++++
arch/x86/kvm/vmx.c | 763 +++++++++++----------
arch/x86/kvm/x86.c | 1 +
arch/x86/lib/Makefile | 1 +
arch/x86/lib/getuser.S | 10 +
arch/x86/lib/retpoline.S | 57 +-
arch/x86/lib/usercopy_32.c | 8 +-
crypto/tcrypt.c | 6 +-
drivers/auxdisplay/img-ascii-lcd.c | 4 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 55 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 8 +
drivers/media/platform/soc_camera/soc_scale_crop.c | 4 +
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 18 +-
drivers/net/ethernet/realtek/r8169.c | 4 +-
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/wireless/broadcom/b43/main.c | 10 +
drivers/pinctrl/pxa/pinctrl-pxa2xx.c | 4 +
drivers/tty/serial/serial_core.c | 2 +
drivers/vhost/net.c | 1 +
include/linux/fdtable.h | 5 +-
include/linux/init.h | 9 +-
include/linux/module.h | 9 +
include/linux/nospec.h | 72 ++
kernel/module.c | 11 +
net/core/sock_reuseport.c | 35 +-
net/ipv4/igmp.c | 4 +
net/ipv4/tcp.c | 6 +
net/ipv4/tcp_bbr.c | 6 +-
net/ipv6/af_inet6.c | 11 +-
net/ipv6/ip6mr.c | 1 +
net/sched/cls_u32.c | 12 +-
net/wireless/nl80211.c | 9 +-
scripts/mod/modpost.c | 9 +
security/keys/encrypted-keys/encrypted.c | 31 +-
sound/soc/codecs/pcm512x-spi.c | 4 +
sound/soc/generic/simple-card.c | 8 +-
sound/soc/sh/rcar/ssi.c | 5 +
93 files changed, 2034 insertions(+), 797 deletions(-)
commit 05e89fb576f580ac95e7a5d00bdb34830b09671a upstream.
It is no longer possible to build BT_HCIUART into the kernel
when SERIAL_DEV_BUS is a loadable module, even if none of the
SERIAL_DEV_BUS based implementations are selected:
drivers/bluetooth/hci_ldisc.o: In function `hci_uart_set_flow_control':
hci_ldisc.c:(.text+0xb40): undefined reference to `serdev_device_set_flow_control'
hci_ldisc.c:(.text+0xb5c): undefined reference to `serdev_device_set_tiocm'
This adds a dependency to avoid the broken configuration.
Fixes: 7841d554809b ("Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
drivers/bluetooth/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 98a60db8e5d1..b33c8d6eb8c7 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -66,6 +66,7 @@ config BT_HCIBTSDIO
config BT_HCIUART
tristate "HCI UART driver"
+ depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
depends on TTY
help
Bluetooth HCI UART driver.
@@ -80,7 +81,6 @@ config BT_HCIUART
config BT_HCIUART_SERDEV
bool
depends on SERIAL_DEV_BUS && BT_HCIUART
- depends on SERIAL_DEV_BUS=y || SERIAL_DEV_BUS=BT_HCIUART
default y
config BT_HCIUART_H4
--
2.9.0
Selecting GENERIC_MSI_IRQ_DOMAIN on x86 causes a compile-time error in
some configurations:
drivers/base/platform-msi.c:37:19: error: field 'arg' has incomplete type
On the other architectures, we are fine, but here we should have an additional
dependency on X86_LOCAL_APIC so we can get the PCI_MSI_IRQ_DOMAIN symbol.
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
drivers/staging/fsl-mc/bus/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl-mc/bus/Kconfig
index 504c987447f2..eee1c1b277fa 100644
--- a/drivers/staging/fsl-mc/bus/Kconfig
+++ b/drivers/staging/fsl-mc/bus/Kconfig
@@ -8,7 +8,7 @@
config FSL_MC_BUS
bool "QorIQ DPAA2 fsl-mc bus driver"
- depends on OF && (ARCH_LAYERSCAPE || (COMPILE_TEST && (ARM || ARM64 || X86 || PPC)))
+ depends on OF && (ARCH_LAYERSCAPE || (COMPILE_TEST && (ARM || ARM64 || X86_LOCAL_APIC || PPC)))
select GENERIC_MSI_IRQ_DOMAIN
help
Driver to enable the bus infrastructure for the QorIQ DPAA2
--
2.9.0
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Commit 8419caa72702 ("ASoC: sgtl5000: Do not disable regulators in
SND_SOC_BIAS_OFF") causes the sgtl5000 to fail after a suspend/resume
sequence:
# aplay /media/a2002011001-e02.wav
Playing WAVE '/media/a2002011001-e02.wav' : Signed 16 bit Little
Endian, Rate 44100 Hz, Stereo
aplay: pcm_write:2051: write error: Input/output error
The problem is caused by the fact that the aforementioned commit
dropped the cache handling, so re-introduce the register map
resync to fix the problem.
Cc: <stable(a)vger.kernel.org>
Suggested-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
---
Changes since v2:
- Rebased against Linus' tree
sound/soc/codecs/sgtl5000.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index e1ab553..7ff5cb7 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -871,15 +871,26 @@ static int sgtl5000_pcm_hw_params(struct snd_pcm_substream *substream,
static int sgtl5000_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
{
+ struct sgtl5000_priv *sgtl = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
switch (level) {
case SND_SOC_BIAS_ON:
case SND_SOC_BIAS_PREPARE:
case SND_SOC_BIAS_STANDBY:
+ regcache_cache_only(sgtl->regmap, false);
+ ret = regcache_sync(sgtl->regmap);
+ if (ret) {
+ regcache_cache_only(sgtl->regmap, true);
+ return ret;
+ }
+
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP,
SGTL5000_REFTOP_POWERUP);
break;
case SND_SOC_BIAS_OFF:
+ regcache_cache_only(sgtl->regmap, true);
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP, 0);
break;
--
2.7.4
This is a note to let you know that I've just added the patch titled
binder: replace "%p" with "%pK"
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 8ca86f1639ec5890d400fff9211aca22d0a392eb Mon Sep 17 00:00:00 2001
From: Todd Kjos <tkjos(a)android.com>
Date: Wed, 7 Feb 2018 13:57:37 -0800
Subject: binder: replace "%p" with "%pK"
The format specifier "%p" can leak kernel addresses. Use
"%pK" instead. There were 4 remaining cases in binder.c.
Signed-off-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 31322e9a235d..a85f9033b57e 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2199,7 +2199,7 @@ static void binder_transaction_buffer_release(struct binder_proc *proc,
int debug_id = buffer->debug_id;
binder_debug(BINDER_DEBUG_TRANSACTION,
- "%d buffer release %d, size %zd-%zd, failed at %p\n",
+ "%d buffer release %d, size %zd-%zd, failed at %pK\n",
proc->pid, buffer->debug_id,
buffer->data_size, buffer->offsets_size, failed_at);
@@ -3711,7 +3711,7 @@ static int binder_thread_write(struct binder_proc *proc,
}
}
binder_debug(BINDER_DEBUG_DEAD_BINDER,
- "%d:%d BC_DEAD_BINDER_DONE %016llx found %p\n",
+ "%d:%d BC_DEAD_BINDER_DONE %016llx found %pK\n",
proc->pid, thread->pid, (u64)cookie,
death);
if (death == NULL) {
@@ -5042,7 +5042,7 @@ static void print_binder_transaction_ilocked(struct seq_file *m,
spin_lock(&t->lock);
to_proc = t->to_proc;
seq_printf(m,
- "%s %d: %p from %d:%d to %d:%d code %x flags %x pri %ld r%d",
+ "%s %d: %pK from %d:%d to %d:%d code %x flags %x pri %ld r%d",
prefix, t->debug_id, t,
t->from ? t->from->proc->pid : 0,
t->from ? t->from->pid : 0,
@@ -5066,7 +5066,7 @@ static void print_binder_transaction_ilocked(struct seq_file *m,
}
if (buffer->target_node)
seq_printf(m, " node %d", buffer->target_node->debug_id);
- seq_printf(m, " size %zd:%zd data %p\n",
+ seq_printf(m, " size %zd:%zd data %pK\n",
buffer->data_size, buffer->offsets_size,
buffer->data);
}
--
2.16.1
This is a note to let you know that I've just added the patch titled
ANDROID: binder: synchronize_rcu() when using POLLFREE.
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 5eeb2ca02a2f6084fc57ae5c244a38baab07033a Mon Sep 17 00:00:00 2001
From: Martijn Coenen <maco(a)android.com>
Date: Fri, 16 Feb 2018 09:47:15 +0100
Subject: ANDROID: binder: synchronize_rcu() when using POLLFREE.
To prevent races with ep_remove_waitqueue() removing the
waitqueue at the same time.
Reported-by: syzbot+a2a3c4909716e271487e(a)syzkaller.appspotmail.com
Signed-off-by: Martijn Coenen <maco(a)android.com>
Cc: stable <stable(a)vger.kernel.org> # 4.14+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a85f9033b57e..764b63a5aade 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4382,6 +4382,15 @@ static int binder_thread_release(struct binder_proc *proc,
binder_inner_proc_unlock(thread->proc);
+ /*
+ * This is needed to avoid races between wake_up_poll() above and
+ * and ep_remove_waitqueue() called for other reasons (eg the epoll file
+ * descriptor being closed); ep_remove_waitqueue() holds an RCU read
+ * lock, so we can be sure it's done after calling synchronize_rcu().
+ */
+ if (thread->looper & BINDER_LOOPER_STATE_POLL)
+ synchronize_rcu();
+
if (send_reply)
binder_send_failed_reply(send_reply, BR_DEAD_REPLY);
binder_release_work(proc, &thread->todo);
--
2.16.1
This is a note to let you know that I've just added the patch titled
ANDROID: binder: remove WARN() for redundant txn error
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e46a3b3ba7509cb7fda0e07bc7c63a2cd90f579b Mon Sep 17 00:00:00 2001
From: Todd Kjos <tkjos(a)android.com>
Date: Wed, 7 Feb 2018 12:38:47 -0800
Subject: ANDROID: binder: remove WARN() for redundant txn error
binder_send_failed_reply() is called when a synchronous
transaction fails. It reports an error to the thread that
is waiting for the completion. Given that the transaction
is synchronous, there should never be more than 1 error
response to that thread -- this was being asserted with
a WARN().
However, when exercising the driver with syzbot tests, cases
were observed where multiple "synchronous" requests were
sent without waiting for responses, so it is possible that
multiple errors would be reported to the thread. This testing
was conducted with panic_on_warn set which forced the crash.
This is easily reproduced by sending back-to-back
"synchronous" transactions without checking for any
response (eg, set read_size to 0):
bwr.write_buffer = (uintptr_t)&bc1;
bwr.write_size = sizeof(bc1);
bwr.read_buffer = (uintptr_t)&br;
bwr.read_size = 0;
ioctl(fd, BINDER_WRITE_READ, &bwr);
sleep(1);
bwr2.write_buffer = (uintptr_t)&bc2;
bwr2.write_size = sizeof(bc2);
bwr2.read_buffer = (uintptr_t)&br;
bwr2.read_size = 0;
ioctl(fd, BINDER_WRITE_READ, &bwr2);
sleep(1);
The first transaction is sent to the servicemanager and the reply
fails because no VMA is set up by this client. After
binder_send_failed_reply() is called, the BINDER_WORK_RETURN_ERROR
is sitting on the thread's todo list since the read_size was 0 and
the client is not waiting for a response.
The 2nd transaction is sent and the BINDER_WORK_RETURN_ERROR has not
been consumed, so the thread's reply_error.cmd is still set (normally
cleared when the BINDER_WORK_RETURN_ERROR is handled). Therefore
when the servicemanager attempts to reply to the 2nd failed
transaction, the error is already set and it triggers this warning.
This is a user error since it is not waiting for the synchronous
transaction to complete. If it ever does check, it will see an
error.
Changed the WARN() to a pr_warn().
Signed-off-by: Todd Kjos <tkjos(a)android.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index ad5e662e3e14..31322e9a235d 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1991,8 +1991,14 @@ static void binder_send_failed_reply(struct binder_transaction *t,
&target_thread->reply_error.work);
wake_up_interruptible(&target_thread->wait);
} else {
- WARN(1, "Unexpected reply error: %u\n",
- target_thread->reply_error.cmd);
+ /*
+ * Cannot get here for normal operation, but
+ * we can if multiple synchronous transactions
+ * are sent without blocking for responses.
+ * Just ignore the 2nd error in this case.
+ */
+ pr_warn("Unexpected reply error: %u\n",
+ target_thread->reply_error.cmd);
}
binder_inner_proc_unlock(target_thread->proc);
binder_thread_dec_tmpref(target_thread);
--
2.16.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 98112041bcca164676367e261c8c1073ef70cb51 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Mon, 12 Feb 2018 15:30:08 +0200
Subject: usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during
suspend/resume
In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init()
must be doene before dwc3_core_get_phy().
commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
broke this.
The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system suspend/resume it will
result in multiple calls to dwc3_core_get_phy() and dwc3_ulpi_init()
which is wrong.
Fix this by moving dwc3_ulpi_init() out of dwc3_phy_setup()
into dwc3_core_ulpi_init(). Use a flag 'ulpi_ready' to ensure that
dwc3_core_ulpi_init() is called only once from dwc3_core_init().
Use another flag 'phys_ready' to call dwc3_core_get_phy() only once from
dwc3_core_init().
Fixes: 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
Fixes: f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY")
Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/core.c | 47 ++++++++++++++++++++++++++++++++++++-----------
drivers/usb/dwc3/core.h | 5 +++++
2 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 59511f2cd3ac..f1d838a4acd6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,6 +486,22 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
}
+static int dwc3_core_ulpi_init(struct dwc3 *dwc)
+{
+ int intf;
+ int ret = 0;
+
+ intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
+
+ if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
+ (intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
+ dwc->hsphy_interface &&
+ !strncmp(dwc->hsphy_interface, "ulpi", 4)))
+ ret = dwc3_ulpi_init(dwc);
+
+ return ret;
+}
+
/**
* dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -497,7 +513,6 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
static int dwc3_phy_setup(struct dwc3 *dwc)
{
u32 reg;
- int ret;
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -568,9 +583,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
}
/* FALLTHROUGH */
case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
- ret = dwc3_ulpi_init(dwc);
- if (ret)
- return ret;
/* FALLTHROUGH */
default:
break;
@@ -727,6 +739,7 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
}
static int dwc3_core_get_phy(struct dwc3 *dwc);
+static int dwc3_core_ulpi_init(struct dwc3 *dwc);
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
@@ -758,17 +771,27 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc->maximum_speed = USB_SPEED_HIGH;
}
- ret = dwc3_core_get_phy(dwc);
+ ret = dwc3_phy_setup(dwc);
if (ret)
goto err0;
- ret = dwc3_core_soft_reset(dwc);
- if (ret)
- goto err0;
+ if (!dwc->ulpi_ready) {
+ ret = dwc3_core_ulpi_init(dwc);
+ if (ret)
+ goto err0;
+ dwc->ulpi_ready = true;
+ }
- ret = dwc3_phy_setup(dwc);
+ if (!dwc->phys_ready) {
+ ret = dwc3_core_get_phy(dwc);
+ if (ret)
+ goto err0a;
+ dwc->phys_ready = true;
+ }
+
+ ret = dwc3_core_soft_reset(dwc);
if (ret)
- goto err0;
+ goto err0a;
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
@@ -841,6 +864,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
phy_exit(dwc->usb2_generic_phy);
phy_exit(dwc->usb3_generic_phy);
+err0a:
+ dwc3_ulpi_exit(dwc);
+
err0:
return ret;
}
@@ -1235,7 +1261,6 @@ static int dwc3_probe(struct platform_device *pdev)
err3:
dwc3_free_event_buffers(dwc);
- dwc3_ulpi_exit(dwc);
err2:
pm_runtime_allow(&pdev->dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 185b9603fd98..860d2bc184d1 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -797,7 +797,9 @@ struct dwc3_scratchpad_array {
* @usb3_phy: pointer to USB3 PHY
* @usb2_generic_phy: pointer to USB2 PHY
* @usb3_generic_phy: pointer to USB3 PHY
+ * @phys_ready: flag to indicate that PHYs are ready
* @ulpi: pointer to ulpi interface
+ * @ulpi_ready: flag to indicate that ULPI is initialized
* @u2sel: parameter from Set SEL request.
* @u2pel: parameter from Set SEL request.
* @u1sel: parameter from Set SEL request.
@@ -895,7 +897,10 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ bool phys_ready;
+
struct ulpi *ulpi;
+ bool ulpi_ready;
void __iomem *regs;
size_t regs_size;
--
2.16.1
This is a note to let you know that I've just added the patch titled
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 17aa31f13cad25daa19d3f923323f552e87bc874 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 5 Feb 2018 17:12:35 +0900
Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx
path
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Cc: <stable(a)vger.kernel.org> # v3.19+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/renesas_usbhs/fifo.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 5925d111bd47..39fa2fc1b8b7 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -982,6 +982,10 @@ static int usbhsf_dma_prepare_pop_with_usb_dmac(struct usbhs_pkt *pkt,
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
+ /* return at this time if the pipe is running */
+ if (usbhs_pipe_is_running(pipe))
+ return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1172,6 +1176,7 @@ static int usbhsf_dma_pop_done_with_usb_dmac(struct usbhs_pkt *pkt,
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
+ usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
--
2.16.1
This is a note to let you know that I've just added the patch titled
usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 499350865387f8b8c40a9e9453a9a7eb3cec5dc4 Mon Sep 17 00:00:00 2001
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Thu, 18 Jan 2018 00:22:45 -0200
Subject: usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28
Commit e93650994a95 ("usb: phy: mxs: add usb charger type detection")
causes the following kernel hang on i.MX28:
[ 2.207973] usbcore: registered new interface driver usb-storage
[ 2.235659] Unable to handle kernel NULL pointer dereference at virtual address 00000188
[ 2.244195] pgd = (ptrval)
[ 2.246994] [00000188] *pgd=00000000
[ 2.250676] Internal error: Oops: 5 [#1] ARM
[ 2.254979] Modules linked in:
[ 2.258089] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc8-next-20180117-00002-g75d5f21 #7
[ 2.266724] Hardware name: Freescale MXS (Device Tree)
[ 2.271921] PC is at regmap_read+0x0/0x5c
[ 2.275977] LR is at mxs_phy_charger_detect+0x34/0x1dc
mxs_phy_charger_detect() makes accesses to the anatop registers via regmap,
however i.MX23/28 do not have such registers, which causes a NULL pointer
dereference.
Fix the issue by doing a NULL check on the 'regmap' pointer.
Fixes: e93650994a95 ("usb: phy: mxs: add usb charger type detection")
Cc: <stable(a)vger.kernel.org> # v4.15
Reviewed-by: Li Jun <jun.li(a)nxp.com>
Acked-by: Peter Chen <peter.chen(a)nxp.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/phy/phy-mxs-usb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index da031c45395a..fbec863350f6 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -602,6 +602,9 @@ static enum usb_charger_type mxs_phy_charger_detect(struct usb_phy *phy)
void __iomem *base = phy->io_priv;
enum usb_charger_type chgr_type = UNKNOWN_TYPE;
+ if (!regmap)
+ return UNKNOWN_TYPE;
+
if (mxs_charger_data_contact_detect(mxs_phy))
return chgr_type;
--
2.16.1
Ensure that cv_end is equal to ibdev->num_comp_vectors for the
NUMA node with the highest index. This patch improves spreading
of RDMA channels over completion vectors and thereby improves
performance, especially on systems with only a single NUMA node.
This patch drops support for the comp_vector login parameter by
ignoring the value of that parameter since I have not found a
good way to combine support for that parameter and automatic
spreading of RDMA channels over completion vectors.
Fixes: d92c0da71a35 ("IB/srp: Add multichannel support")
Reported-by: Alexander Schmid <alex(a)modula-shop-systems.de>
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Alexander Schmid <alex(a)modula-shop-systems.de>
Cc: stable(a)vger.kernel.org
---
drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index b48843833d69..241c0e72dce3 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -3871,12 +3871,10 @@ static ssize_t srp_create_target(struct device *dev,
num_online_nodes());
const int ch_end = ((node_idx + 1) * target->ch_count /
num_online_nodes());
- const int cv_start = (node_idx * ibdev->num_comp_vectors /
- num_online_nodes() + target->comp_vector)
- % ibdev->num_comp_vectors;
- const int cv_end = ((node_idx + 1) * ibdev->num_comp_vectors /
- num_online_nodes() + target->comp_vector)
- % ibdev->num_comp_vectors;
+ const int cv_start = node_idx * ibdev->num_comp_vectors /
+ num_online_nodes();
+ const int cv_end = (node_idx + 1) * ibdev->num_comp_vectors /
+ num_online_nodes();
int cpu_idx = 0;
for_each_online_cpu(cpu) {
--
2.16.1
The last expression in a statement expression need not be a bare
variable, quoting gcc docs
The last thing in the compound statement should be an expression
followed by a semicolon; the value of this subexpression serves as the
value of the entire construct.
and we already use that in e.g. the min/max macros which end with a
ternary expression.
This way, we can allow index to have const-qualified type, which will in
some cases avoid the need for introducing a local copy of index of
non-const qualified type. That, in turn, can prevent readers not
familiar with the internals of array_index_nospec from wondering about
the seemingly redundant extra variable, and I think that's worthwhile
considering how confusing the whole _nospec business is.
The expression _i&_mask has type unsigned long (since that is the type
of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to
that), so in order not to change the type of the whole expression, add
a cast back to typeof(_i).
Cc: stable(a)vger.kernel.org
Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
---
cc stable because if this is ok, there will probably be future users
relying on this which also get cc'ed to -stable.
include/linux/nospec.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index fbc98e2c8228..132e3f5a2e0d 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -72,7 +72,6 @@ static inline unsigned long array_index_mask_nospec(unsigned long index,
BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \
\
- _i &= _mask; \
- _i; \
+ (typeof(_i)) (_i & _mask); \
})
#endif /* _LINUX_NOSPEC_H */
--
2.15.1
This is a note to let you know that I've just added the patch titled
Add delay-init quirk for Corsair K70 RGB keyboards
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001
From: Jack Stocker <jackstocker.93(a)gmail.com>
Date: Thu, 15 Feb 2018 18:24:10 +0000
Subject: Add delay-init quirk for Corsair K70 RGB keyboards
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker <jackstocker.93(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 4024926c1d68..f4a548471f0f 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -226,6 +226,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
--
2.16.1
Please add this patch to stable 3.18, 4.4 and 4.9
It exists in 4.14.
----------------------------------------------------------------------------
commit 8598112d04af21cf6c895670e72dcb8a9f58e74f
Author: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Thu Aug 31 10:37:00 2017 +0200
xfrm: Fix return value check of copy_sec_ctx.
A recent commit added an output_mark. When copying
this output_mark, the return value of copy_sec_ctx
is overwitten without a check. Fix this by copying
the output_mark before the security context.
Fixes: 077fbac405bf ("net: xfrm: support setting an output mark.")
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
This is a note to let you know that I've just added the patch titled
usb: ohci: Proper handling of ed_rm_list to handle race condition
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 46408ea558df13b110e0866b99624384a33bdeba Mon Sep 17 00:00:00 2001
From: AMAN DEEP <aman.deep(a)samsung.com>
Date: Thu, 8 Feb 2018 11:55:01 +0800
Subject: usb: ohci: Proper handling of ed_rm_list to handle race condition
between usb_kill_urb() and finish_unlinks()
There is a race condition between finish_unlinks->finish_urb() function
and usb_kill_urb() in ohci controller case. The finish_urb calls
spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
then if during this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning for unlink, and
ed_rm_list will point to newly added.
When finish_urb() is completed in finish_unlinks() and ed->td_list
becomes empty as in below code (in finish_unlinks() function):
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}
The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
and previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later
last* is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep(a)samsung.com>
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-q.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c
index b2ec8c399363..4ccb85a67bb3 100644
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1019,6 +1019,8 @@ static void finish_unlinks(struct ohci_hcd *ohci)
* have modified this list. normally it's just prepending
* entries (which we'd ignore), but paranoia won't hurt.
*/
+ *last = ed->ed_next;
+ ed->ed_next = NULL;
modified = 0;
/* unlink urbs as requested, but rescan the list after
@@ -1077,21 +1079,22 @@ static void finish_unlinks(struct ohci_hcd *ohci)
goto rescan_this;
/*
- * If no TDs are queued, take ED off the ed_rm_list.
+ * If no TDs are queued, ED is now idle.
* Otherwise, if the HC is running, reschedule.
- * If not, leave it on the list for further dequeues.
+ * If the HC isn't running, add ED back to the
+ * start of the list for later processing.
*/
if (list_empty(&ed->td_list)) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed->state = ED_IDLE;
list_del(&ed->in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed_schedule(ohci, ed);
} else {
- last = &ed->ed_next;
+ ed->ed_next = ohci->ed_rm_list;
+ ohci->ed_rm_list = ed;
+ /* Don't loop on the same ED */
+ if (last == &ohci->ed_rm_list)
+ last = &ed->ed_next;
}
if (modified)
--
2.16.1
This is a note to let you know that I've just added the patch titled
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From d6efa938ac366fe8cb92d6157f74d43cc35f1c67 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 5 Feb 2018 17:12:35 +0900
Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx
path
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Cc: <stable(a)vger.kernel.org> # v3.19+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/renesas_usbhs/fifo.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 5925d111bd47..39fa2fc1b8b7 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -982,6 +982,10 @@ static int usbhsf_dma_prepare_pop_with_usb_dmac(struct usbhs_pkt *pkt,
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
+ /* return at this time if the pipe is running */
+ if (usbhs_pipe_is_running(pipe))
+ return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1172,6 +1176,7 @@ static int usbhsf_dma_pop_done_with_usb_dmac(struct usbhs_pkt *pkt,
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
+ usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
--
2.16.1
This is a note to let you know that I've just added the patch titled
usb: ldusb: add PIDs for new CASSY devices supported by this driver
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 52ad2bd8918158266fc88a05f95429b56b6a33c5 Mon Sep 17 00:00:00 2001
From: Karsten Koop <kkoop(a)ld-didactic.de>
Date: Fri, 9 Feb 2018 09:12:06 +0000
Subject: usb: ldusb: add PIDs for new CASSY devices supported by this driver
This patch adds support for new CASSY devices to the ldusb driver. The
PIDs are also added to the ignore list in hid-quirks.
Signed-off-by: Karsten Koop <kkoop(a)ld-didactic.de>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-quirks.c | 3 +++
drivers/usb/misc/ldusb.c | 6 ++++++
3 files changed, 12 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 43ddcdfbd0da..9454ac134ce2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -645,6 +645,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043
#define USB_DEVICE_ID_LD_JWM 0x1080
#define USB_DEVICE_ID_LD_DMMP 0x1081
#define USB_DEVICE_ID_LD_UMIP 0x1090
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 5f6035a5ce36..e92b77fa574a 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -809,6 +809,9 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c
index 63b9e85dc0e9..236a60f53099 100644
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -42,6 +42,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 /* USB Product ID of Micro-CASSY Time (reserved) */
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 /* USB Product ID of Micro-CASSY Temperature */
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 /* USB Product ID of Micro-CASSY pH */
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 /* USB Product ID of Power Analyser CASSY */
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 /* USB Product ID of Converter Controller CASSY */
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 /* USB Product ID of Machine Test CASSY */
#define USB_DEVICE_ID_LD_JWM 0x1080 /* USB Product ID of Joule and Wattmeter */
#define USB_DEVICE_ID_LD_DMMP 0x1081 /* USB Product ID of Digital Multimeter P (reserved) */
#define USB_DEVICE_ID_LD_UMIP 0x1090 /* USB Product ID of UMI P */
@@ -84,6 +87,9 @@ static const struct usb_device_id ld_usb_table[] = {
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
--
2.16.1
This is a note to let you know that I've just added the patch titled
usb: host: ehci: use correct device pointer for dma ops
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 02a10f061a3f8bca1b37332672f50a107198adbe Mon Sep 17 00:00:00 2001
From: Peter Chen <hzpeterchen(a)gmail.com>
Date: Thu, 1 Feb 2018 12:26:43 +0800
Subject: usb: host: ehci: use correct device pointer for dma ops
commit a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
converted to use hcd->self.sysdev for DMA operations instead of
hcd->self.controller, but forgot to do it for hcd test mode. Replace
the correct one in this commit.
Fixes: a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
Signed-off-by: Peter Chen <peter.chen(a)nxp.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ehci-hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index facafdf8fb95..d7641cbdee43 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -774,12 +774,12 @@ static struct urb *request_single_step_set_feature_urb(
atomic_inc(&urb->use_count);
atomic_inc(&urb->dev->urbnum);
urb->setup_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->setup_packet,
sizeof(struct usb_ctrlrequest),
DMA_TO_DEVICE);
urb->transfer_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->transfer_buffer,
urb->transfer_buffer_length,
DMA_FROM_DEVICE);
--
2.16.1
This is a note to let you know that I've just added the patch titled
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From b2685bdacdaab065c172b97b55ab46c6be77a037 Mon Sep 17 00:00:00 2001
From: Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
Date: Fri, 2 Feb 2018 13:51:39 +0800
Subject: ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and
io_watchdog_func()
Running io_watchdog_func() while ohci_urb_enqueue() is running can
cause a race condition where ohci->prev_frame_no is corrupted and the
watchdog can mis-detect following error:
ohci-platform 664a0800.usb: frame counter not updating; disabled
ohci-platform 664a0800.usb: HC died; cleaning up
Specifically, following scenario causes a race condition:
1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number
read by ohci_frame_no(ohci)
4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section
6. Later, ohci_urb_enqueue() is called
7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
8. The timer scheduled on step 4 expires and io_watchdog_func() runs
9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags)
and waits on it because ohci_urb_enqueue() is already in the
critical section on step 7
10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number
read by ohci_frame_no(ohci) because the frame number proceeded
between step 3 and 6
12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section, then wake up
io_watchdog_func() which is waiting on step 9
14. io_watchdog_func() enters the critical section
15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no
variable to the frame number
16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
On step 16, because this calling of io_watchdog_func() is scheduled on
step 4, the frame number set in ohci->prev_frame_no is expected to the
number set on step 3. However, ohci->prev_frame_no is overwritten on
step 11. Because step 16 is executed soon after step 11, the frame
number might not proceed, so ohci->prev_frame_no must equals to
frame_no.
To address above scenario, this patch introduces a special sentinel
value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when
the watchdog is not pending or running. When ohci_urb_enqueue()
schedules the watchdog (step 4 and 12 above), it compares
ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is
not overwritten while io_watchdog_func() is running.
Signed-off-by: Shigeru Yoshida <Shigeru.Yoshida(a)windriver.com>
Signed-off-by: Haiqing Bai <Haiqing.Bai(a)windriver.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-hcd.c | 10 +++++++---
drivers/usb/host/ohci-hub.c | 4 +++-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index ee9676349333..84f88fa411cd 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -74,6 +74,7 @@ static const char hcd_name [] = "ohci_hcd";
#define STATECHANGE_DELAY msecs_to_jiffies(300)
#define IO_WATCHDOG_DELAY msecs_to_jiffies(275)
+#define IO_WATCHDOG_OFF 0xffffff00
#include "ohci.h"
#include "pci-quirks.h"
@@ -231,7 +232,7 @@ static int ohci_urb_enqueue (
}
/* Start up the I/O watchdog timer, if it's not running */
- if (!timer_pending(&ohci->io_watchdog) &&
+ if (ohci->prev_frame_no == IO_WATCHDOG_OFF &&
list_empty(&ohci->eds_in_use) &&
!(ohci->flags & OHCI_QUIRK_QEMU)) {
ohci->prev_frame_no = ohci_frame_no(ohci);
@@ -501,6 +502,7 @@ static int ohci_init (struct ohci_hcd *ohci)
return 0;
timer_setup(&ohci->io_watchdog, io_watchdog_func, 0);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
ohci->hcca = dma_alloc_coherent (hcd->self.controller,
sizeof(*ohci->hcca), &ohci->hcca_dma, GFP_KERNEL);
@@ -730,7 +732,7 @@ static void io_watchdog_func(struct timer_list *t)
u32 head;
struct ed *ed;
struct td *td, *td_start, *td_next;
- unsigned frame_no;
+ unsigned frame_no, prev_frame_no = IO_WATCHDOG_OFF;
unsigned long flags;
spin_lock_irqsave(&ohci->lock, flags);
@@ -835,7 +837,7 @@ static void io_watchdog_func(struct timer_list *t)
}
}
if (!list_empty(&ohci->eds_in_use)) {
- ohci->prev_frame_no = frame_no;
+ prev_frame_no = frame_no;
ohci->prev_wdh_cnt = ohci->wdh_cnt;
ohci->prev_donehead = ohci_readl(ohci,
&ohci->regs->donehead);
@@ -845,6 +847,7 @@ static void io_watchdog_func(struct timer_list *t)
}
done:
+ ohci->prev_frame_no = prev_frame_no;
spin_unlock_irqrestore(&ohci->lock, flags);
}
@@ -973,6 +976,7 @@ static void ohci_stop (struct usb_hcd *hcd)
if (quirk_nec(ohci))
flush_work(&ohci->nec_work);
del_timer_sync(&ohci->io_watchdog);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
ohci_usb_reset(ohci);
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index fb7aaa3b9d06..634f3c7bf774 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -311,8 +311,10 @@ static int ohci_bus_suspend (struct usb_hcd *hcd)
rc = ohci_rh_suspend (ohci, 0);
spin_unlock_irq (&ohci->lock);
- if (rc == 0)
+ if (rc == 0) {
del_timer_sync(&ohci->io_watchdog);
+ ohci->prev_frame_no = IO_WATCHDOG_OFF;
+ }
return rc;
}
--
2.16.1
This is a note to let you know that I've just added the patch titled
xhci: fix xhci debugfs errors in xhci_stop
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 11cd764dc9a030991880ad4d51db93918afa5822 Mon Sep 17 00:00:00 2001
From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Date: Mon, 12 Feb 2018 14:24:51 +0200
Subject: xhci: fix xhci debugfs errors in xhci_stop
In function xhci_stop, xhci_debugfs_exit called before xhci_mem_cleanup.
xhci_debugfs_exit removed the xhci debugfs root nodes, xhci_mem_cleanup
called function xhci_free_virt_devices_depth_first which in turn called
function xhci_debugfs_remove_slot.
Function xhci_debugfs_remove_slot removed the nodes for devices, the nodes
folders are sub folder of xhci debugfs.
It is unreasonable to remove xhci debugfs root folder before
xhci debugfs sub folder. Function xhci_mem_cleanup should be called
before function xhci_debugfs_exit.
Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
Cc: <stable(a)vger.kernel.org> # v4.15
Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4adb6da0bd38..25d4b748a56f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -646,8 +646,6 @@ static void xhci_stop(struct usb_hcd *hcd)
return;
}
- xhci_debugfs_exit(xhci);
-
xhci_dbc_exit(xhci);
spin_lock_irq(&xhci->lock);
@@ -680,6 +678,7 @@ static void xhci_stop(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "cleaning up memory");
xhci_mem_cleanup(xhci);
+ xhci_debugfs_exit(xhci);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"xhci_stop completed - status = %x",
readl(&xhci->op_regs->status));
--
2.16.1
This is a note to let you know that I've just added the patch titled
xhci: xhci debugfs device nodes weren't removed after device plugged
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 8c5a93ebf7ac56d47f879b3c7c2f8c83b40c2cdb Mon Sep 17 00:00:00 2001
From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Date: Mon, 12 Feb 2018 14:24:50 +0200
Subject: xhci: xhci debugfs device nodes weren't removed after device plugged
out
There is a bug after plugged out USB device, the device and its ep00
nodes are still kept, we need to remove the nodes in xhci_free_dev when
USB device is plugged out.
Fixes: 052f71e25a7e ("xhci: Fix xhci debugfs NULL pointer dereference in resume from hibernate")
Cc: <stable(a)vger.kernel.org> # v4.15
Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b01bd643f905..4adb6da0bd38 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3545,12 +3545,10 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
virt_dev->eps[i].ep_state &= ~EP_STOP_CMD_PENDING;
del_timer_sync(&virt_dev->eps[i].stop_cmd_timer);
}
-
+ xhci_debugfs_remove_slot(xhci, udev->slot_id);
ret = xhci_disable_slot(xhci, udev->slot_id);
- if (ret) {
- xhci_debugfs_remove_slot(xhci, udev->slot_id);
+ if (ret)
xhci_free_virt_device(xhci, udev->slot_id);
- }
}
int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
--
2.16.1
This is a note to let you know that I've just added the patch titled
xhci: Fix xhci debugfs devices node disappearance after hibernation
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From d91676717261578f429d3577dbe9154b26e8abf7 Mon Sep 17 00:00:00 2001
From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Date: Mon, 12 Feb 2018 14:24:49 +0200
Subject: xhci: Fix xhci debugfs devices node disappearance after hibernation
During system resume from hibernation, xhci host is reset, all the
nodes in devices folder are removed in xhci_mem_cleanup function.
Later nodes in /sys/kernel/debug/usb/xhci/* are created again in
function xhci_run, but the nodes already exist, so the nodes still
keep the old ones, finally device nodes in xhci debugfs folder
/sys/kernel/debug/usb/xhci/*/devices/* are disappeared.
This fix removed xhci debugfs nodes before the nodes are re-created,
so all the nodes in xhci debugfs can be re-created successfully.
Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
Cc: <stable(a)vger.kernel.org> # v4.15
Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1eeb3396300f..b01bd643f905 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1014,6 +1014,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
xhci_dbg(xhci, "cleaning up memory\n");
xhci_mem_cleanup(xhci);
+ xhci_debugfs_exit(xhci);
xhci_dbg(xhci, "xhci_stop completed - status = %x\n",
readl(&xhci->op_regs->status));
--
2.16.1
This is a note to let you know that I've just added the patch titled
xhci: Fix NULL pointer in xhci debugfs
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From fa2dfd0ec22e0069c84dfae162972cbbc7c75488 Mon Sep 17 00:00:00 2001
From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Date: Mon, 12 Feb 2018 14:24:48 +0200
Subject: xhci: Fix NULL pointer in xhci debugfs
Commit dde634057da7 ("xhci: Fix use-after-free in xhci debugfs") causes a
null pointer dereference while fixing xhci-debugfs usage of ring pointers
that were freed during hibernate.
The fix passed addresses to ring pointers instead, but forgot to do this
change for the xhci_ring_trb_show function.
The address of the ring pointer passed to xhci-debugfs was of a temporary
ring pointer "new_ring" instead of the actual ring "ring" pointer. The
temporary new_ring pointer will be set to NULL later causing the NULL
pointer dereference.
This issue was seen when reading xhci related files in debugfs:
cat /sys/kernel/debug/usb/xhci/*/devices/*/ep*/trbs
[ 184.604861] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 184.613776] IP: xhci_ring_trb_show+0x3a/0x890
[ 184.618733] PGD 264193067 P4D 264193067 PUD 263238067 PMD 0
[ 184.625184] Oops: 0000 [#1] SMP
[ 184.726410] RIP: 0010:xhci_ring_trb_show+0x3a/0x890
[ 184.731944] RSP: 0018:ffffba8243c0fd90 EFLAGS: 00010246
[ 184.737880] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000295d6
[ 184.746020] RDX: 00000000000295d5 RSI: 0000000000000001 RDI: ffff971a6418d400
[ 184.754121] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 184.762222] R10: ffff971a64c98a80 R11: ffff971a62a00e40 R12: ffff971a62a85500
[ 184.770325] R13: 0000000000020000 R14: ffff971a6418d400 R15: ffff971a6418d400
[ 184.778448] FS: 00007fe725a79700(0000) GS:ffff971a6ec00000(0000) knlGS:0000000000000000
[ 184.787644] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 184.794168] CR2: 0000000000000000 CR3: 000000025f365005 CR4: 00000000003606f0
[ 184.802318] Call Trace:
[ 184.805094] ? seq_read+0x281/0x3b0
[ 184.809068] seq_read+0xeb/0x3b0
[ 184.812735] full_proxy_read+0x4d/0x70
[ 184.817007] __vfs_read+0x23/0x120
[ 184.820870] vfs_read+0x91/0x130
[ 184.824538] SyS_read+0x42/0x90
[ 184.828106] entry_SYSCALL_64_fastpath+0x1a/0x7d
Fixes: dde634057da7 ("xhci: Fix use-after-free in xhci debugfs")
Cc: <stable(a)vger.kernel.org> # v4.15
Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index e26e685d8a57..5851052d4668 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -211,7 +211,7 @@ static void xhci_ring_dump_segment(struct seq_file *s,
static int xhci_ring_trb_show(struct seq_file *s, void *unused)
{
int i;
- struct xhci_ring *ring = s->private;
+ struct xhci_ring *ring = *(struct xhci_ring **)s->private;
struct xhci_segment *seg = ring->first_seg;
for (i = 0; i < ring->num_segs; i++) {
@@ -387,7 +387,7 @@ void xhci_debugfs_create_endpoint(struct xhci_hcd *xhci,
snprintf(epriv->name, sizeof(epriv->name), "ep%02d", ep_index);
epriv->root = xhci_debugfs_create_ring_dir(xhci,
- &dev->eps[ep_index].new_ring,
+ &dev->eps[ep_index].ring,
epriv->name,
spriv->root);
spriv->eps[ep_index] = epriv;
--
2.16.1
On Thu, Feb 15, 2018 at 03:35:03PM +0000, Harsh Shandilya wrote:
> On Thu 15 Feb, 2018, 8:50 PM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.95 release.
> > There are 45 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 Sat Feb 17 14:40:54 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.95-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Builds and boots on the OnePlus 3T, no regressions in general usage or
> dmesg. Another peaceful and boring update :P
Boring is good, it's what you want with a stable kernel update :)
thanks for testing and letting me know.
greg k-h
This is a note to let you know that I've just added the patch titled
rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rcu-export-init_rcu_head-and-destroy_rcu_head-to-gpl-modules.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 156baec39732f025dc778e00da95fc10d6e45885 Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
Date: Thu, 7 Dec 2017 09:40:38 -0800
Subject: rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
From: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
commit 156baec39732f025dc778e00da95fc10d6e45885 upstream.
Use of init_rcu_head() and destroy_rcu_head() from modules results in
the following build-time error with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y:
ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them to
be used by GPL-licensed kernel modules.
Reported-by: Bart Van Assche <Bart.VanAssche(a)wdc.com>
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/rcu/update.c | 2 ++
1 file changed, 2 insertions(+)
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head
{
debug_object_init(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(init_rcu_head);
void destroy_rcu_head(struct rcu_head *head)
{
debug_object_free(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(destroy_rcu_head);
static bool rcuhead_is_static_object(void *addr)
{
Patches currently in stable-queue which might be from paulmck(a)linux.vnet.ibm.com are
queue-4.15/rcu-export-init_rcu_head-and-destroy_rcu_head-to-gpl-modules.patch
This is a note to let you know that I've just added the patch titled
rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rcu-export-init_rcu_head-and-destroy_rcu_head-to-gpl-modules.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 156baec39732f025dc778e00da95fc10d6e45885 Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
Date: Thu, 7 Dec 2017 09:40:38 -0800
Subject: rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
From: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
commit 156baec39732f025dc778e00da95fc10d6e45885 upstream.
Use of init_rcu_head() and destroy_rcu_head() from modules results in
the following build-time error with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y:
ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them to
be used by GPL-licensed kernel modules.
Reported-by: Bart Van Assche <Bart.VanAssche(a)wdc.com>
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/rcu/update.c | 2 ++
1 file changed, 2 insertions(+)
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -421,11 +421,13 @@ void init_rcu_head(struct rcu_head *head
{
debug_object_init(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(init_rcu_head);
void destroy_rcu_head(struct rcu_head *head)
{
debug_object_free(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(destroy_rcu_head);
static bool rcuhead_is_static_object(void *addr)
{
Patches currently in stable-queue which might be from paulmck(a)linux.vnet.ibm.com are
queue-4.14/rcu-export-init_rcu_head-and-destroy_rcu_head-to-gpl-modules.patch
This is a note to let you know that I've just added the patch titled
ovl: fix failure to fsync lower dir
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-fix-failure-to-fsync-lower-dir.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d796e77f1dd541fe34481af2eee6454688d13982 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 8 Nov 2017 09:39:46 +0200
Subject: ovl: fix failure to fsync lower dir
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Amir Goldstein <amir73il(a)gmail.com>
commit d796e77f1dd541fe34481af2eee6454688d13982 upstream.
As a writable mount, it is not expected for overlayfs to return
EINVAL/EROFS for fsync, even if dir/file is not changed.
This commit fixes the case of fsync of directory, which is easier to
address, because overlayfs already implements fsync file operation for
directories.
The problem reported by Raphael is that new PostgreSQL 10.0 with a
database in overlayfs where lower layer in squashfs fails to start.
The failure is due to fsync error, when PostgreSQL does fsync on all
existing db directories on startup and a specific directory exists
lower layer with no changes.
Reported-by: Raphael Hertzog <raphael(a)ouaza.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Tested-by: Raphaël Hertzog <hertzog(a)debian.org>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -434,10 +434,14 @@ static int ovl_dir_fsync(struct file *fi
struct dentry *dentry = file->f_path.dentry;
struct file *realfile = od->realfile;
+ /* Nothing to sync for lower */
+ if (!OVL_TYPE_UPPER(ovl_path_type(dentry)))
+ return 0;
+
/*
* Need to check if we started out being a lower dir, but got copied up
*/
- if (!od->is_upper && OVL_TYPE_UPPER(ovl_path_type(dentry))) {
+ if (!od->is_upper) {
struct inode *inode = file_inode(file);
realfile = lockless_dereference(od->upperfile);
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.9/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 05:02:38 -0500
Subject: mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.
Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct. With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr. Which is very wrong.
So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <dhowells(a)redhat.com>
Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com>
Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mn10300/mm/misalignment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mn10300/mm/misalignment.c
+++ b/arch/mn10300/mm/misalignment.c
@@ -437,7 +437,7 @@ transfer_failed:
info.si_signo = SIGSEGV;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = SEGV_MAPERR;
info.si_addr = (void *) regs->pc;
force_sig_info(SIGSEGV, &info, current);
return;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.9/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.9/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-4.9/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
This is a note to let you know that I've just added the patch titled
ftrace: Remove incorrect setting of glob search field
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ftrace-remove-incorrect-setting-of-glob-search-field.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7b6586562708d2b3a04fe49f217ddbadbbbb0546 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Mon, 5 Feb 2018 22:05:31 -0500
Subject: ftrace: Remove incorrect setting of glob search field
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit 7b6586562708d2b3a04fe49f217ddbadbbbb0546 upstream.
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal to glob only if glob started with '!' or '*'. In the former case
we would've buggered off with -EINVAL (not = 1). In the latter we
would've set func_g.search equal to glob + 1, calculated the length of
that thing in func_g.len and proceeded to reset func_g.search back to
glob.
Suppose the glob is e.g. *foo*. We end up with
func_g.type = MATCH_MIDDLE_ONLY;
func_g.len = 3;
func_g.search = "*foo";
Feeding that to ftrace_match_record() will not do anything sane - we
will be looking for names containing "*foo" (->len is ignored for that
one).
Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
Reviewed-by: Dmitry Safonov <0x7f454c46(a)gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/ftrace.c | 1 -
1 file changed, 1 deletion(-)
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3911,7 +3911,6 @@ __unregister_ftrace_function_probe(char
func_g.type = filter_parse_regex(glob, strlen(glob),
&func_g.search, ¬);
func_g.len = strlen(func_g.search);
- func_g.search = glob;
/* we do not support '!' for function probes */
if (WARN_ON(not))
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.9/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.9/ftrace-remove-incorrect-setting-of-glob-search-field.patch
queue-4.9/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Avoid PPS HW/SW state mismatch due to rounding
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5643205c6340b565a3be0fe0e7305dc4aa551c74 Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Wed, 29 Nov 2017 19:51:37 +0200
Subject: drm/i915: Avoid PPS HW/SW state mismatch due to rounding
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Imre Deak <imre.deak(a)intel.com>
commit 5643205c6340b565a3be0fe0e7305dc4aa551c74 upstream.
We store a SW state of the t11_t12 timing in 100usec units but have to
program it in 100msec as required by HW. The rounding used during
programming means there will be a mismatch between the SW and HW states
of this value triggering a "PPS state mismatch" error. Avoid this by
storing the already rounded-up value in the SW state.
Note that we still calculate panel_power_cycle_delay with the finer
100usec granularity to avoid any needless waits using that version of
the delay.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
Cc: joks <joks(a)linux.pl>
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129175137.2889-1-imre.de…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5063,6 +5063,12 @@ intel_dp_init_panel_power_sequencer(stru
*/
final->t8 = 1;
final->t9 = 1;
+
+ /*
+ * HW has only a 100msec granularity for t11_t12 so round it up
+ * accordingly.
+ */
+ final->t11_t12 = roundup(final->t11_t12, 100 * 10);
}
static void
Patches currently in stable-queue which might be from imre.deak(a)intel.com are
queue-4.9/drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
This is a note to let you know that I've just added the patch titled
ACPI: sbshc: remove raw pointer from printk() message
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-sbshc-remove-raw-pointer-from-printk-message.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 43cdd1b716b26f6af16da4e145b6578f98798bf6 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 19 Jan 2018 10:06:03 +0100
Subject: ACPI: sbshc: remove raw pointer from printk() message
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
commit 43cdd1b716b26f6af16da4e145b6578f98798bf6 upstream.
There's no need to be printing a raw kernel pointer to the kernel log at
every boot. So just remove it, and change the whole message to use the
correct dev_info() call at the same time.
Reported-by: Wang Qize <wang_qize(a)venustech.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/sbshc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -275,8 +275,8 @@ static int acpi_smbus_hc_add(struct acpi
device->driver_data = hc;
acpi_ec_add_query_handler(hc->ec, hc->query_bit, NULL, smbus_alarm, hc);
- printk(KERN_INFO PREFIX "SBS HC: EC = 0x%p, offset = 0x%0x, query_bit = 0x%0x\n",
- hc->ec, hc->offset, hc->query_bit);
+ dev_info(&device->dev, "SBS HC: offset = 0x%0x, query_bit = 0x%0x\n",
+ hc->offset, hc->query_bit);
return 0;
}
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.9/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.9/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.9/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.9/media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
queue-4.9/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.9/ubi-fastmap-erase-outdated-anchor-pebs-during-attach.patch
queue-4.9/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.9/crypto-talitos-fix-kernel-oops-on-hashing-an-empty-file.patch
queue-4.9/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.9/mtd-cfi-convert-inline-functions-to-macros.patch
queue-4.9/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch
queue-4.9/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
queue-4.9/clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
queue-4.9/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.9/alpha-fix-formating-of-stack-content.patch
queue-4.9/lib-ubsan-add-type-mismatch-handler-for-new-gcc-clang.patch
queue-4.9/kaiser-fix-compile-error-without-vsyscall.patch
queue-4.9/ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
queue-4.9/crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
queue-4.9/watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
queue-4.9/btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.9/usb-gadget-uvc-missing-files-for-configfs-interface.patch
queue-4.9/dmaengine-dmatest-fix-container_of-member-in-dmatest_callback.patch
queue-4.9/pktcdvd-fix-pkt_setup_dev-error-path.patch
queue-4.9/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.9/lib-ubsan.c-s-missaligned-misaligned.patch
queue-4.9/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.9/nsfs-mark-dentry-with-dcache_rcuaccess.patch
queue-4.9/acpi-nfit-fix-register-dimm-error-handling.patch
queue-4.9/pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch
queue-4.9/cifs-fix-missing-put_xid-in-cifs_file_strict_mmap.patch
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
queue-4.9/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.9/cifs-fix-autonegotiate-security-settings-mismatch.patch
queue-4.9/edac-octeon-fix-an-uninitialized-variable-warning.patch
queue-4.9/asoc-rockchip-i2s-fix-playback-after-runtime-resume.patch
queue-4.9/mtd-nand-brcmnand-disable-prefetch-by-default.patch
queue-4.9/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.9/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.9/asoc-skl-fix-kernel-warning-due-to-zero-nhtl-entry.patch
queue-4.9/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.9/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.9/posix-timer-properly-check-sigevent-sigev_notify.patch
queue-4.9/media-dvb-frontends-fix-i2c-access-helpers-for-kasan.patch
queue-4.9/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-4.9/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
queue-4.9/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch
queue-4.9/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.9/ftrace-remove-incorrect-setting-of-glob-search-field.patch
queue-4.9/powerpc-pseries-include-linux-types.h-in-asm-hvcall.h.patch
queue-4.9/fs-proc-kcore.c-use-probe_kernel_read-instead-of-memcpy.patch
queue-4.9/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.9/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
queue-4.9/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.9/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/kvm-arm-arm64-handle-cpu_pm_enter_failed.patch
queue-4.9/cifs-zero-sensitive-data-when-freeing.patch
queue-4.9/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
queue-4.9/media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
queue-4.9/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.9/dccp-cve-2017-8824-use-after-free-in-dccp-code.patch
queue-4.9/drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.9/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.9/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
queue-4.9/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
queue-4.9/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.9/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.9/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.9/mtd-nand-fix-nand_do_read_oob-return-value.patch
queue-4.9/media-v4l2-compat-ioctl32-copy-v4l2_window-global_alpha.patch
queue-4.9/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.9/ubifs-massage-assert-in-ubifs_xattr_set-wrt.-init_xattrs.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/nfs-fix-a-race-between-mmap-and-o_direct.patch
queue-4.9/alpha-fix-reboot-on-avanti-platform.patch
queue-4.9/ovl-fix-failure-to-fsync-lower-dir.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
queue-4.9/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
queue-4.9/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
queue-4.9/kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch
queue-4.9/acpi-sbshc-remove-raw-pointer-from-printk-message.patch
This is a note to let you know that I've just added the patch titled
acpi, nfit: fix register dimm error handling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-nfit-fix-register-dimm-error-handling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 23fbd7c70aec7600e3227eb24259fc55bf6e4881 Mon Sep 17 00:00:00 2001
From: Toshi Kani <toshi.kani(a)hpe.com>
Date: Fri, 2 Feb 2018 14:00:36 -0700
Subject: acpi, nfit: fix register dimm error handling
From: Toshi Kani <toshi.kani(a)hpe.com>
commit 23fbd7c70aec7600e3227eb24259fc55bf6e4881 upstream.
A NULL pointer reference kernel bug was observed when
acpi_nfit_add_dimm() called in acpi_nfit_register_dimms() failed. This
error path does not set nfit_mem->nvdimm, but the 2nd
list_for_each_entry() loop in the function assumes it's always set. Add
a check to nfit_mem->nvdimm.
Fixes: ba9c8dd3c222 ("acpi, nfit: add dimm device notification support")
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/nfit/core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1535,6 +1535,9 @@ static int acpi_nfit_register_dimms(stru
struct kernfs_node *nfit_kernfs;
nvdimm = nfit_mem->nvdimm;
+ if (!nvdimm)
+ continue;
+
nfit_kernfs = sysfs_get_dirent(nvdimm_kobj(nvdimm)->sd, "nfit");
if (nfit_kernfs)
nfit_mem->flags_attr = sysfs_get_dirent(nfit_kernfs,
Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are
queue-4.9/acpi-nfit-fix-register-dimm-error-handling.patch
This is a note to let you know that I've just added the patch titled
ovl: fix failure to fsync lower dir
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-fix-failure-to-fsync-lower-dir.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d796e77f1dd541fe34481af2eee6454688d13982 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 8 Nov 2017 09:39:46 +0200
Subject: ovl: fix failure to fsync lower dir
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Amir Goldstein <amir73il(a)gmail.com>
commit d796e77f1dd541fe34481af2eee6454688d13982 upstream.
As a writable mount, it is not expected for overlayfs to return
EINVAL/EROFS for fsync, even if dir/file is not changed.
This commit fixes the case of fsync of directory, which is easier to
address, because overlayfs already implements fsync file operation for
directories.
The problem reported by Raphael is that new PostgreSQL 10.0 with a
database in overlayfs where lower layer in squashfs fails to start.
The failure is due to fsync error, when PostgreSQL does fsync on all
existing db directories on startup and a specific directory exists
lower layer with no changes.
Reported-by: Raphael Hertzog <raphael(a)ouaza.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Tested-by: Raphaël Hertzog <hertzog(a)debian.org>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -441,10 +441,14 @@ static int ovl_dir_fsync(struct file *fi
struct dentry *dentry = file->f_path.dentry;
struct file *realfile = od->realfile;
+ /* Nothing to sync for lower */
+ if (!OVL_TYPE_UPPER(ovl_path_type(dentry)))
+ return 0;
+
/*
* Need to check if we started out being a lower dir, but got copied up
*/
- if (!od->is_upper && OVL_TYPE_UPPER(ovl_path_type(dentry))) {
+ if (!od->is_upper) {
struct inode *inode = file_inode(file);
realfile = lockless_dereference(od->upperfile);
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.4/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 05:02:38 -0500
Subject: mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.
Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct. With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr. Which is very wrong.
So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <dhowells(a)redhat.com>
Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com>
Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mn10300/mm/misalignment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mn10300/mm/misalignment.c
+++ b/arch/mn10300/mm/misalignment.c
@@ -437,7 +437,7 @@ transfer_failed:
info.si_signo = SIGSEGV;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = SEGV_MAPERR;
info.si_addr = (void *) regs->pc;
force_sig_info(SIGSEGV, &info, current);
return;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.4/netfilter-nf_queue-make-the-queue_handler-pernet.patch
queue-4.4/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.4/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-4.4/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
This is a note to let you know that I've just added the patch titled
ftrace: Remove incorrect setting of glob search field
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ftrace-remove-incorrect-setting-of-glob-search-field.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7b6586562708d2b3a04fe49f217ddbadbbbb0546 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Mon, 5 Feb 2018 22:05:31 -0500
Subject: ftrace: Remove incorrect setting of glob search field
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit 7b6586562708d2b3a04fe49f217ddbadbbbb0546 upstream.
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal to glob only if glob started with '!' or '*'. In the former case
we would've buggered off with -EINVAL (not = 1). In the latter we
would've set func_g.search equal to glob + 1, calculated the length of
that thing in func_g.len and proceeded to reset func_g.search back to
glob.
Suppose the glob is e.g. *foo*. We end up with
func_g.type = MATCH_MIDDLE_ONLY;
func_g.len = 3;
func_g.search = "*foo";
Feeding that to ftrace_match_record() will not do anything sane - we
will be looking for names containing "*foo" (->len is ignored for that
one).
Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
Reviewed-by: Dmitry Safonov <0x7f454c46(a)gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/ftrace.c | 1 -
1 file changed, 1 deletion(-)
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3845,7 +3845,6 @@ __unregister_ftrace_function_probe(char
func_g.type = filter_parse_regex(glob, strlen(glob),
&func_g.search, ¬);
func_g.len = strlen(func_g.search);
- func_g.search = glob;
/* we do not support '!' for function probes */
if (WARN_ON(not))
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.4/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.4/ftrace-remove-incorrect-setting-of-glob-search-field.patch
queue-4.4/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
ACPI: sbshc: remove raw pointer from printk() message
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-sbshc-remove-raw-pointer-from-printk-message.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 43cdd1b716b26f6af16da4e145b6578f98798bf6 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 19 Jan 2018 10:06:03 +0100
Subject: ACPI: sbshc: remove raw pointer from printk() message
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
commit 43cdd1b716b26f6af16da4e145b6578f98798bf6 upstream.
There's no need to be printing a raw kernel pointer to the kernel log at
every boot. So just remove it, and change the whole message to use the
correct dev_info() call at the same time.
Reported-by: Wang Qize <wang_qize(a)venustech.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/sbshc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -275,8 +275,8 @@ static int acpi_smbus_hc_add(struct acpi
device->driver_data = hc;
acpi_ec_add_query_handler(hc->ec, hc->query_bit, NULL, smbus_alarm, hc);
- printk(KERN_INFO PREFIX "SBS HC: EC = 0x%p, offset = 0x%0x, query_bit = 0x%0x\n",
- hc->ec, hc->offset, hc->query_bit);
+ dev_info(&device->dev, "SBS HC: offset = 0x%0x, query_bit = 0x%0x\n",
+ hc->offset, hc->query_bit);
return 0;
}
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.4/powerpc-simplify-module-toc-handling.patch
queue-4.4/powerpc-64s-simple-rfi-macro-conversions.patch
queue-4.4/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.4/crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
queue-4.4/media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
queue-4.4/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.4/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.4/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.4/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.4/mtd-cfi-convert-inline-functions-to-macros.patch
queue-4.4/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch
queue-4.4/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
queue-4.4/r8169-fix-rtl8168ep-take-too-long-to-complete-driver-initialization.patch
queue-4.4/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.4/powerpc-64-fix-flush_-d-i-cache_range-called-from-modules.patch
queue-4.4/powerpc-64-add-macros-for-annotating-the-destination-of-rfid-hrfid.patch
queue-4.4/tcp-release-sk_frag.page-in-tcp_disconnect.patch
queue-4.4/kaiser-fix-compile-error-without-vsyscall.patch
queue-4.4/ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
queue-4.4/crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
queue-4.4/drm-rcar-du-use-the-vbk-interrupt-for-vblank-events.patch
queue-4.4/watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
queue-4.4/btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
queue-4.4/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.4/usb-gadget-uvc-missing-files-for-configfs-interface.patch
queue-4.4/dmaengine-dmatest-fix-container_of-member-in-dmatest_callback.patch
queue-4.4/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch
queue-4.4/powerpc-pseries-add-h_get_cpu_characteristics-flags-wrapper.patch
queue-4.4/pktcdvd-fix-pkt_setup_dev-error-path.patch
queue-4.4/asoc-rsnd-don-t-call-free_irq-on-parent-ssi.patch
queue-4.4/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.4/net-igmp-add-a-missing-rcu-locking-section.patch
queue-4.4/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.4/nsfs-mark-dentry-with-dcache_rcuaccess.patch
queue-4.4/netfilter-nf_queue-make-the-queue_handler-pernet.patch
queue-4.4/powerpc-64s-allow-control-of-rfi-flush-via-debugfs.patch
queue-4.4/powerpc-powernv-check-device-tree-for-rfi-flush-settings.patch
queue-4.4/vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch
queue-4.4/asoc-rsnd-avoid-duplicate-free_irq.patch
queue-4.4/cifs-fix-missing-put_xid-in-cifs_file_strict_mmap.patch
queue-4.4/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.4/revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.4/cifs-fix-autonegotiate-security-settings-mismatch.patch
queue-4.4/edac-octeon-fix-an-uninitialized-variable-warning.patch
queue-4.4/don-t-put-symlink-bodies-in-pagecache-into-highmem.patch
queue-4.4/mtd-nand-brcmnand-disable-prefetch-by-default.patch
queue-4.4/powerpc-64s-convert-slb_miss_common-to-use-rfi_to_user-kernel.patch
queue-4.4/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.4/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-4.4/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.4/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.4/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.4/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.4/net-cdc_ncm-initialize-drvflags-before-usage.patch
queue-4.4/posix-timer-properly-check-sigevent-sigev_notify.patch
queue-4.4/ip6mr-fix-stale-iterator.patch
queue-4.4/x86-microcode-do-the-family-check-first.patch
queue-4.4/x86-kaiser-fix-build-error-with-kasan-function_graph_tracer.patch
queue-4.4/powerpc-64s-support-disabling-rfi-flush-with-no_rfi_flush-and-nopti.patch
queue-4.4/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-4.4/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
queue-4.4/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch
queue-4.4/powerpc-64-convert-the-syscall-exit-path-to-use-rfi_to_user-kernel.patch
queue-4.4/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.4/ftrace-remove-incorrect-setting-of-glob-search-field.patch
queue-4.4/powerpc-pseries-include-linux-types.h-in-asm-hvcall.h.patch
queue-4.4/drm-rcar-du-fix-race-condition-when-disabling-planes-at-crtc-stop.patch
queue-4.4/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.4/asoc-pcm512x-add-missing-module_description-author-license.patch
queue-4.4/vhost_net-stop-device-during-reset-owner.patch
queue-4.4/powerpc-bpf-jit-disable-classic-bpf-jit-on-ppc64le.patch
queue-4.4/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
queue-4.4/powerpc-64s-add-support-for-rfi-flush-of-l1-d-cache.patch
queue-4.4/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.4/usbip-vhci_hcd-clear-just-the-usb_port_stat_power-bit.patch
queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
queue-4.4/powerpc-pseries-query-hypervisor-for-rfi-flush-settings.patch
queue-4.4/nvme-fix-managing-degraded-controllers.patch
queue-4.4/cifs-zero-sensitive-data-when-freeing.patch
queue-4.4/qlcnic-fix-deadlock-bug.patch
queue-4.4/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
queue-4.4/media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
queue-4.4/powerpc-fix-vsx-enabling-flushing-to-also-test-msr_fp-and-msr_vec.patch
queue-4.4/dccp-cve-2017-8824-use-after-free-in-dccp-code.patch
queue-4.4/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.4/powerpc-64-convert-fast_exception_return-to-use-rfi_to_user-kernel.patch
queue-4.4/crypto-poly1305-remove-setkey-method.patch
queue-4.4/usbip-fix-3eee23c3ec14-tcp_socket-address-still-in-the-status-file.patch
queue-4.4/asoc-simple-card-fix-misleading-error-message.patch
queue-4.4/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.4/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.4/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
queue-4.4/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
queue-4.4/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.4/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.4/mtd-nand-fix-nand_do_read_oob-return-value.patch
queue-4.4/media-v4l2-compat-ioctl32-copy-v4l2_window-global_alpha.patch
queue-4.4/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_meltdown.patch
queue-4.4/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.4/alpha-fix-reboot-on-avanti-platform.patch
queue-4.4/ovl-fix-failure-to-fsync-lower-dir.patch
queue-4.4/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
queue-4.4/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
queue-4.4/kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch
queue-4.4/acpi-sbshc-remove-raw-pointer-from-printk-message.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: Fix crash after bad bar setup on driver attachment
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-fix-crash-after-bad-bar-setup-on-driver-attachment.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e4b9794efdce13242f4af6682f3ed48ce3864a87 Mon Sep 17 00:00:00 2001
From: James Smart <jsmart2021(a)gmail.com>
Date: Mon, 20 Nov 2017 16:00:31 -0800
Subject: scsi: lpfc: Fix crash after bad bar setup on driver attachment
From: James Smart <jsmart2021(a)gmail.com>
commit e4b9794efdce13242f4af6682f3ed48ce3864a87 upstream.
In test cases where an instance of the driver is detached and
reattached, the driver will crash on reattachment. There is a compound
if statement that will skip over the bar setup if the pci_resource_start
call is not successful. The driver erroneously returns success to its
bar setup in this scenario even though the bars aren't properly
configured.
Rework the offending code segment for proper initialization steps. If
the pci_resource_start call fails, -ENOMEM is now returned.
Sample stack:
rport-5:0-10: blocked FC remote port time out: removing rport
BUG: unable to handle kernel NULL pointer dereference at (null)
... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
...
... RIP: 0010:... ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
Call Trace:
... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc]
... ? __alloc_pages_nodemask+0x176/0x420
... ? __kmalloc+0x2e/0x230
... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc]
... ? mempool_alloc+0x69/0x170
... ? dma_generic_alloc_coherent+0x8f/0x140
... lpfc_sli_issue_mbox+0xf/0x20 [lpfc]
... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc]
... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc]
... lpfc_pci_probe_one+0x445/0x16f0 [lpfc]
... local_pci_probe+0x45/0xa0
... work_for_cpu_fn+0x14/0x20
... process_one_work+0x17a/0x440
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_init.c | 84 +++++++++++++++++++++++++-----------------
1 file changed, 51 insertions(+), 33 deletions(-)
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -9421,44 +9421,62 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba
lpfc_sli4_bar0_register_memmap(phba, if_type);
}
- if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) &&
- (pci_resource_start(pdev, PCI_64BIT_BAR2))) {
- /*
- * Map SLI4 if type 0 HBA Control Register base to a kernel
- * virtual address and setup the registers.
- */
- phba->pci_bar1_map = pci_resource_start(pdev, PCI_64BIT_BAR2);
- bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2);
- phba->sli4_hba.ctrl_regs_memmap_p =
- ioremap(phba->pci_bar1_map, bar1map_len);
- if (!phba->sli4_hba.ctrl_regs_memmap_p) {
- dev_printk(KERN_ERR, &pdev->dev,
- "ioremap failed for SLI4 HBA control registers.\n");
+ if (if_type == LPFC_SLI_INTF_IF_TYPE_0) {
+ if (pci_resource_start(pdev, PCI_64BIT_BAR2)) {
+ /*
+ * Map SLI4 if type 0 HBA Control Register base to a
+ * kernel virtual address and setup the registers.
+ */
+ phba->pci_bar1_map = pci_resource_start(pdev,
+ PCI_64BIT_BAR2);
+ bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2);
+ phba->sli4_hba.ctrl_regs_memmap_p =
+ ioremap(phba->pci_bar1_map,
+ bar1map_len);
+ if (!phba->sli4_hba.ctrl_regs_memmap_p) {
+ dev_err(&pdev->dev,
+ "ioremap failed for SLI4 HBA "
+ "control registers.\n");
+ error = -ENOMEM;
+ goto out_iounmap_conf;
+ }
+ phba->pci_bar2_memmap_p =
+ phba->sli4_hba.ctrl_regs_memmap_p;
+ lpfc_sli4_bar1_register_memmap(phba);
+ } else {
+ error = -ENOMEM;
goto out_iounmap_conf;
}
- phba->pci_bar2_memmap_p = phba->sli4_hba.ctrl_regs_memmap_p;
- lpfc_sli4_bar1_register_memmap(phba);
}
- if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) &&
- (pci_resource_start(pdev, PCI_64BIT_BAR4))) {
- /*
- * Map SLI4 if type 0 HBA Doorbell Register base to a kernel
- * virtual address and setup the registers.
- */
- phba->pci_bar2_map = pci_resource_start(pdev, PCI_64BIT_BAR4);
- bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4);
- phba->sli4_hba.drbl_regs_memmap_p =
- ioremap(phba->pci_bar2_map, bar2map_len);
- if (!phba->sli4_hba.drbl_regs_memmap_p) {
- dev_printk(KERN_ERR, &pdev->dev,
- "ioremap failed for SLI4 HBA doorbell registers.\n");
- goto out_iounmap_ctrl;
- }
- phba->pci_bar4_memmap_p = phba->sli4_hba.drbl_regs_memmap_p;
- error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0);
- if (error)
+ if (if_type == LPFC_SLI_INTF_IF_TYPE_0) {
+ if (pci_resource_start(pdev, PCI_64BIT_BAR4)) {
+ /*
+ * Map SLI4 if type 0 HBA Doorbell Register base to
+ * a kernel virtual address and setup the registers.
+ */
+ phba->pci_bar2_map = pci_resource_start(pdev,
+ PCI_64BIT_BAR4);
+ bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4);
+ phba->sli4_hba.drbl_regs_memmap_p =
+ ioremap(phba->pci_bar2_map,
+ bar2map_len);
+ if (!phba->sli4_hba.drbl_regs_memmap_p) {
+ dev_err(&pdev->dev,
+ "ioremap failed for SLI4 HBA"
+ " doorbell registers.\n");
+ error = -ENOMEM;
+ goto out_iounmap_ctrl;
+ }
+ phba->pci_bar4_memmap_p =
+ phba->sli4_hba.drbl_regs_memmap_p;
+ error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0);
+ if (error)
+ goto out_iounmap_all;
+ } else {
+ error = -ENOMEM;
goto out_iounmap_all;
+ }
}
return 0;
Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are
queue-4.15/scsi-lpfc-fix-crash-after-bad-bar-setup-on-driver-attachment.patch
This is a note to let you know that I've just added the patch titled
scsi: cxlflash: Reset command ioasc
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-cxlflash-reset-command-ioasc.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 96cf727fe8f102bf92150b741db71ee39fb8c521 Mon Sep 17 00:00:00 2001
From: Uma Krishnan <ukrishn(a)linux.vnet.ibm.com>
Date: Wed, 3 Jan 2018 16:54:02 -0600
Subject: scsi: cxlflash: Reset command ioasc
From: Uma Krishnan <ukrishn(a)linux.vnet.ibm.com>
commit 96cf727fe8f102bf92150b741db71ee39fb8c521 upstream.
In the event of a command failure, cxlflash returns the failure to the upper
layers to process. After processing the error, when the command is queued
again, the private command structure will not be zeroed and the ioasc could be
stale. Per the SISLite specification, the AFU only sets the ioasc in the
presence of a failure. Thus, even though the original command succeeds the
second time, the command is considered a failure due to stale ioasc. This
cycle repeats indefinitely and can cause a hang or IO failure.
To fix the issue, clear the ioasc before queuing any command.
[mkp: added Cc: stable per request]
Fixes: 479ad8e9d48c ("scsi: cxlflash: Remove zeroing of private command data")
Signed-off-by: Uma Krishnan <ukrishn(a)linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/cxlflash/main.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -620,6 +620,7 @@ static int cxlflash_queuecommand(struct
cmd->parent = afu;
cmd->hwq_index = hwq_index;
+ cmd->sa.ioasc = 0;
cmd->rcb.ctx_id = hwq->ctx_hndl;
cmd->rcb.msi = SISL_MSI_RRQ_UPDATED;
cmd->rcb.port_sel = CHAN2PORTMASK(scp->device->channel);
Patches currently in stable-queue which might be from ukrishn(a)linux.vnet.ibm.com are
queue-4.15/scsi-cxlflash-reset-command-ioasc.patch
This is a note to let you know that I've just added the patch titled
scsi: core: Ensure that the SCSI error handler gets woken up
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-core-ensure-that-the-scsi-error-handler-gets-woken-up.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3bd6f43f5cb3714f70c591514f344389df593501 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Mon, 4 Dec 2017 10:06:23 -0800
Subject: scsi: core: Ensure that the SCSI error handler gets woken up
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 3bd6f43f5cb3714f70c591514f344389df593501 upstream.
If scsi_eh_scmd_add() is called concurrently with
scsi_host_queue_ready() while shost->host_blocked > 0 then it can
happen that neither function wakes up the SCSI error handler. Fix
this by making every function that decreases the host_busy counter
wake up the error handler if necessary and by protecting the
host_failed checks with the SCSI host lock.
Reported-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
References: https://marc.info/?l=linux-kernel&m=150461610630736
Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Tested-by: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Konstantin Khorenko <khorenko(a)virtuozzo.com>
Cc: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/hosts.c | 6 ++++++
drivers/scsi/scsi_error.c | 18 ++++++++++++++++--
drivers/scsi/scsi_lib.c | 39 ++++++++++++++++++++++++++++-----------
include/scsi/scsi_host.h | 2 ++
4 files changed, 52 insertions(+), 13 deletions(-)
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -318,6 +318,9 @@ static void scsi_host_dev_release(struct
scsi_proc_hostdir_rm(shost->hostt);
+ /* Wait for functions invoked through call_rcu(&shost->rcu, ...) */
+ rcu_barrier();
+
if (shost->tmf_work_q)
destroy_workqueue(shost->tmf_work_q);
if (shost->ehandler)
@@ -325,6 +328,8 @@ static void scsi_host_dev_release(struct
if (shost->work_q)
destroy_workqueue(shost->work_q);
+ destroy_rcu_head(&shost->rcu);
+
if (shost->shost_state == SHOST_CREATED) {
/*
* Free the shost_dev device name here if scsi_host_alloc()
@@ -399,6 +404,7 @@ struct Scsi_Host *scsi_host_alloc(struct
INIT_LIST_HEAD(&shost->starved_list);
init_waitqueue_head(&shost->host_wait);
mutex_init(&shost->scan_mutex);
+ init_rcu_head(&shost->rcu);
index = ida_simple_get(&host_index_ida, 0, 0, GFP_KERNEL);
if (index < 0)
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -220,6 +220,17 @@ static void scsi_eh_reset(struct scsi_cm
}
}
+static void scsi_eh_inc_host_failed(struct rcu_head *head)
+{
+ struct Scsi_Host *shost = container_of(head, typeof(*shost), rcu);
+ unsigned long flags;
+
+ spin_lock_irqsave(shost->host_lock, flags);
+ shost->host_failed++;
+ scsi_eh_wakeup(shost);
+ spin_unlock_irqrestore(shost->host_lock, flags);
+}
+
/**
* scsi_eh_scmd_add - add scsi cmd to error handling.
* @scmd: scmd to run eh on.
@@ -242,9 +253,12 @@ void scsi_eh_scmd_add(struct scsi_cmnd *
scsi_eh_reset(scmd);
list_add_tail(&scmd->eh_entry, &shost->eh_cmd_q);
- shost->host_failed++;
- scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
+ /*
+ * Ensure that all tasks observe the host state change before the
+ * host_failed change.
+ */
+ call_rcu(&shost->rcu, scsi_eh_inc_host_failed);
}
/**
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -318,22 +318,39 @@ static void scsi_init_cmd_errh(struct sc
cmd->cmd_len = scsi_command_size(cmd->cmnd);
}
-void scsi_device_unbusy(struct scsi_device *sdev)
+/*
+ * Decrement the host_busy counter and wake up the error handler if necessary.
+ * Avoid as follows that the error handler is not woken up if shost->host_busy
+ * == shost->host_failed: use call_rcu() in scsi_eh_scmd_add() in combination
+ * with an RCU read lock in this function to ensure that this function in its
+ * entirety either finishes before scsi_eh_scmd_add() increases the
+ * host_failed counter or that it notices the shost state change made by
+ * scsi_eh_scmd_add().
+ */
+static void scsi_dec_host_busy(struct Scsi_Host *shost)
{
- struct Scsi_Host *shost = sdev->host;
- struct scsi_target *starget = scsi_target(sdev);
unsigned long flags;
+ rcu_read_lock();
atomic_dec(&shost->host_busy);
- if (starget->can_queue > 0)
- atomic_dec(&starget->target_busy);
-
- if (unlikely(scsi_host_in_recovery(shost) &&
- (shost->host_failed || shost->host_eh_scheduled))) {
+ if (unlikely(scsi_host_in_recovery(shost))) {
spin_lock_irqsave(shost->host_lock, flags);
- scsi_eh_wakeup(shost);
+ if (shost->host_failed || shost->host_eh_scheduled)
+ scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
}
+ rcu_read_unlock();
+}
+
+void scsi_device_unbusy(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev->host;
+ struct scsi_target *starget = scsi_target(sdev);
+
+ scsi_dec_host_busy(shost);
+
+ if (starget->can_queue > 0)
+ atomic_dec(&starget->target_busy);
atomic_dec(&sdev->device_busy);
}
@@ -1532,7 +1549,7 @@ starved:
list_add_tail(&sdev->starved_entry, &shost->starved_list);
spin_unlock_irq(shost->host_lock);
out_dec:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
return 0;
}
@@ -2020,7 +2037,7 @@ static blk_status_t scsi_queue_rq(struct
return BLK_STS_OK;
out_dec_host_busy:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
out_dec_target_busy:
if (scsi_target(sdev)->can_queue > 0)
atomic_dec(&scsi_target(sdev)->target_busy);
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -571,6 +571,8 @@ struct Scsi_Host {
struct blk_mq_tag_set tag_set;
};
+ struct rcu_head rcu;
+
atomic_t host_busy; /* commands actually active on low-level */
atomic_t host_blocked;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.15/scsi-core-ensure-that-the-scsi-error-handler-gets-woken-up.patch
queue-4.15/pktcdvd-fix-pkt_setup_dev-error-path.patch
queue-4.15/pktcdvd-fix-a-recently-introduced-null-pointer-dereference.patch
This is a note to let you know that I've just added the patch titled
ovl: take mnt_want_write() for work/index dir setup
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-take-mnt_want_write-for-work-index-dir-setup.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2ba9d57e65044859f7ff133bcb0a902769bf3bc6 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 3 Jan 2018 18:54:41 +0200
Subject: ovl: take mnt_want_write() for work/index dir setup
From: Amir Goldstein <amir73il(a)gmail.com>
commit 2ba9d57e65044859f7ff133bcb0a902769bf3bc6 upstream.
There are several write operations on upper fs not covered by
mnt_want_write():
- test set/remove OPAQUE xattr
- test create O_TMPFILE
- set ORIGIN xattr in ovl_verify_origin()
- cleanup of index entries in ovl_indexdir_cleanup()
Some of these go way back, but this patch only applies over the
v4.14 re-factoring of ovl_fill_super().
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/super.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -520,10 +520,6 @@ static struct dentry *ovl_workdir_create
bool retried = false;
bool locked = false;
- err = mnt_want_write(mnt);
- if (err)
- goto out_err;
-
inode_lock_nested(dir, I_MUTEX_PARENT);
locked = true;
@@ -588,7 +584,6 @@ retry:
goto out_err;
}
out_unlock:
- mnt_drop_write(mnt);
if (locked)
inode_unlock(dir);
@@ -930,12 +925,17 @@ out:
static int ovl_make_workdir(struct ovl_fs *ofs, struct path *workpath)
{
+ struct vfsmount *mnt = ofs->upper_mnt;
struct dentry *temp;
int err;
+ err = mnt_want_write(mnt);
+ if (err)
+ return err;
+
ofs->workdir = ovl_workdir_create(ofs, OVL_WORKDIR_NAME, false);
if (!ofs->workdir)
- return 0;
+ goto out;
/*
* Upper should support d_type, else whiteouts are visible. Given
@@ -945,7 +945,7 @@ static int ovl_make_workdir(struct ovl_f
*/
err = ovl_check_d_type_supported(workpath);
if (err < 0)
- return err;
+ goto out;
/*
* We allowed this configuration and don't want to break users over
@@ -969,6 +969,7 @@ static int ovl_make_workdir(struct ovl_f
if (err) {
ofs->noxattr = true;
pr_warn("overlayfs: upper fs does not support xattr.\n");
+ err = 0;
} else {
vfs_removexattr(ofs->workdir, OVL_XATTR_OPAQUE);
}
@@ -980,7 +981,9 @@ static int ovl_make_workdir(struct ovl_f
pr_warn("overlayfs: upper fs does not support file handles, falling back to index=off.\n");
}
- return 0;
+out:
+ mnt_drop_write(mnt);
+ return err;
}
static int ovl_get_workdir(struct ovl_fs *ofs, struct path *upperpath)
@@ -1027,8 +1030,13 @@ out:
static int ovl_get_indexdir(struct ovl_fs *ofs, struct ovl_entry *oe,
struct path *upperpath)
{
+ struct vfsmount *mnt = ofs->upper_mnt;
int err;
+ err = mnt_want_write(mnt);
+ if (err)
+ return err;
+
/* Verify lower root is upper root origin */
err = ovl_verify_origin(upperpath->dentry, oe->lowerstack[0].dentry,
false, true);
@@ -1056,6 +1064,7 @@ static int ovl_get_indexdir(struct ovl_f
pr_warn("overlayfs: try deleting index dir or mounting with '-o index=off' to disable inodes index.\n");
out:
+ mnt_drop_write(mnt);
return err;
}
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.15/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.15/ovl-take-mnt_want_write-for-work-index-dir-setup.patch
queue-4.15/ovl-hash-directory-inodes-for-fsnotify.patch
queue-4.15/ovl-force-r-o-mount-when-index-dir-creation-fails.patch
queue-4.15/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
ovl: take mnt_want_write() for removing impure xattr
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-take-mnt_want_write-for-removing-impure-xattr.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a5a927a7c82e28ea76599dee4019c41e372c911f Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 3 Jan 2018 18:54:42 +0200
Subject: ovl: take mnt_want_write() for removing impure xattr
From: Amir Goldstein <amir73il(a)gmail.com>
commit a5a927a7c82e28ea76599dee4019c41e372c911f upstream.
The optimization in ovl_cache_get_impure() that tries to remove an
unneeded "impure" xattr needs to take mnt_want_write() on upper fs.
Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs")
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -593,8 +593,15 @@ static struct ovl_dir_cache *ovl_cache_g
return ERR_PTR(res);
}
if (list_empty(&cache->entries)) {
- /* Good oportunity to get rid of an unnecessary "impure" flag */
- ovl_do_removexattr(ovl_dentry_upper(dentry), OVL_XATTR_IMPURE);
+ /*
+ * A good opportunity to get rid of an unneeded "impure" flag.
+ * Removing the "impure" xattr is best effort.
+ */
+ if (!ovl_want_write(dentry)) {
+ ovl_do_removexattr(ovl_dentry_upper(dentry),
+ OVL_XATTR_IMPURE);
+ ovl_drop_write(dentry);
+ }
ovl_clear_flag(OVL_IMPURE, d_inode(dentry));
kfree(cache);
return NULL;
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.15/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.15/ovl-take-mnt_want_write-for-work-index-dir-setup.patch
queue-4.15/ovl-hash-directory-inodes-for-fsnotify.patch
queue-4.15/ovl-force-r-o-mount-when-index-dir-creation-fails.patch
queue-4.15/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
ovl: hash directory inodes for fsnotify
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-hash-directory-inodes-for-fsnotify.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 31747eda41ef3c30c09c5c096b380bf54013746a Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Sun, 14 Jan 2018 18:35:40 +0200
Subject: ovl: hash directory inodes for fsnotify
From: Amir Goldstein <amir73il(a)gmail.com>
commit 31747eda41ef3c30c09c5c096b380bf54013746a upstream.
fsnotify pins a watched directory inode in cache, but if directory dentry
is released, new lookup will allocate a new dentry and a new inode.
Directory events will be notified on the new inode, while fsnotify listener
is watching the old pinned inode.
Hash all directory inodes to reuse the pinned inode on lookup. Pure upper
dirs are hashes by real upper inode, merge and lower dirs are hashed by
real lower inode.
The reference to lower inode was being held by the lower dentry object
in the overlay dentry (oe->lowerstack[0]). Releasing the overlay dentry
may drop lower inode refcount to zero. Add a refcount on behalf of the
overlay inode to prevent that.
As a by-product, hashing directory inodes also detects multiple
redirected dirs to the same lower dir and uncovered redirected dir
target on and returns -ESTALE on lookup.
The reported issue dates back to initial version of overlayfs, but this
patch depends on ovl_inode code that was introduced in kernel v4.13.
Reported-by: Niklas Cassel <niklas.cassel(a)axis.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Tested-by: Niklas Cassel <niklas.cassel(a)axis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/inode.c | 39 ++++++++++++++++++++++++++++-----------
fs/overlayfs/super.c | 1 +
fs/overlayfs/util.c | 4 ++--
3 files changed, 31 insertions(+), 13 deletions(-)
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -606,6 +606,16 @@ static int ovl_inode_set(struct inode *i
static bool ovl_verify_inode(struct inode *inode, struct dentry *lowerdentry,
struct dentry *upperdentry)
{
+ if (S_ISDIR(inode->i_mode)) {
+ /* Real lower dir moved to upper layer under us? */
+ if (!lowerdentry && ovl_inode_lower(inode))
+ return false;
+
+ /* Lookup of an uncovered redirect origin? */
+ if (!upperdentry && ovl_inode_upper(inode))
+ return false;
+ }
+
/*
* Allow non-NULL lower inode in ovl_inode even if lowerdentry is NULL.
* This happens when finding a copied up overlay inode for a renamed
@@ -633,6 +643,8 @@ struct inode *ovl_get_inode(struct dentr
struct inode *inode;
/* Already indexed or could be indexed on copy up? */
bool indexed = (index || (ovl_indexdir(dentry->d_sb) && !upperdentry));
+ struct dentry *origin = indexed ? lowerdentry : NULL;
+ bool is_dir;
if (WARN_ON(upperdentry && indexed && !lowerdentry))
return ERR_PTR(-EIO);
@@ -641,15 +653,19 @@ struct inode *ovl_get_inode(struct dentr
realinode = d_inode(lowerdentry);
/*
- * Copy up origin (lower) may exist for non-indexed upper, but we must
- * not use lower as hash key in that case.
- * Hash inodes that are or could be indexed by origin inode and
- * non-indexed upper inodes that could be hard linked by upper inode.
+ * Copy up origin (lower) may exist for non-indexed non-dir upper, but
+ * we must not use lower as hash key in that case.
+ * Hash non-dir that is or could be indexed by origin inode.
+ * Hash dir that is or could be merged by origin inode.
+ * Hash pure upper and non-indexed non-dir by upper inode.
*/
- if (!S_ISDIR(realinode->i_mode) && (upperdentry || indexed)) {
- struct inode *key = d_inode(indexed ? lowerdentry :
- upperdentry);
- unsigned int nlink;
+ is_dir = S_ISDIR(realinode->i_mode);
+ if (is_dir)
+ origin = lowerdentry;
+
+ if (upperdentry || origin) {
+ struct inode *key = d_inode(origin ?: upperdentry);
+ unsigned int nlink = is_dir ? 1 : realinode->i_nlink;
inode = iget5_locked(dentry->d_sb, (unsigned long) key,
ovl_inode_test, ovl_inode_set, key);
@@ -670,8 +686,9 @@ struct inode *ovl_get_inode(struct dentr
goto out;
}
- nlink = ovl_get_nlink(lowerdentry, upperdentry,
- realinode->i_nlink);
+ /* Recalculate nlink for non-dir due to indexing */
+ if (!is_dir)
+ nlink = ovl_get_nlink(lowerdentry, upperdentry, nlink);
set_nlink(inode, nlink);
} else {
inode = new_inode(dentry->d_sb);
@@ -685,7 +702,7 @@ struct inode *ovl_get_inode(struct dentr
ovl_set_flag(OVL_IMPURE, inode);
/* Check for non-merge dir that may have whiteouts */
- if (S_ISDIR(realinode->i_mode)) {
+ if (is_dir) {
struct ovl_entry *oe = dentry->d_fsdata;
if (((upperdentry && lowerdentry) || oe->numlower > 1) ||
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -211,6 +211,7 @@ static void ovl_destroy_inode(struct ino
struct ovl_inode *oi = OVL_I(inode);
dput(oi->__upperdentry);
+ iput(oi->lower);
kfree(oi->redirect);
ovl_dir_cache_free(inode);
mutex_destroy(&oi->lock);
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -257,7 +257,7 @@ void ovl_inode_init(struct inode *inode,
if (upperdentry)
OVL_I(inode)->__upperdentry = upperdentry;
if (lowerdentry)
- OVL_I(inode)->lower = d_inode(lowerdentry);
+ OVL_I(inode)->lower = igrab(d_inode(lowerdentry));
ovl_copyattr(d_inode(upperdentry ?: lowerdentry), inode);
}
@@ -273,7 +273,7 @@ void ovl_inode_update(struct inode *inod
*/
smp_wmb();
OVL_I(inode)->__upperdentry = upperdentry;
- if (!S_ISDIR(upperinode->i_mode) && inode_unhashed(inode)) {
+ if (inode_unhashed(inode)) {
inode->i_private = upperinode;
__insert_inode_hash(inode, (unsigned long) upperinode);
}
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.15/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.15/ovl-take-mnt_want_write-for-work-index-dir-setup.patch
queue-4.15/ovl-hash-directory-inodes-for-fsnotify.patch
queue-4.15/ovl-force-r-o-mount-when-index-dir-creation-fails.patch
queue-4.15/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
ovl: force r/o mount when index dir creation fails
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-force-r-o-mount-when-index-dir-creation-fails.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 972d0093c2f7b1bd57e47a1780a552dde528fd16 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Tue, 19 Sep 2017 12:14:18 +0300
Subject: ovl: force r/o mount when index dir creation fails
From: Amir Goldstein <amir73il(a)gmail.com>
commit 972d0093c2f7b1bd57e47a1780a552dde528fd16 upstream.
When work dir creation fails, a warning is emitted and overlay is
mounted r/o. Trying to remount r/w will fail with no work dir.
When index dir creation fails, the same warning is emitted and overlay
is mounted r/o, but trying to remount r/w will succeed. This may cause
unintentional corruption of filesystem consistency.
Adjust the behavior of index dir creation failure to that of work dir
creation failure and do not allow to remount r/w. User needs to state
an explicitly intention to work without an index by mounting with
option 'index=off' to allow r/w mount with no index dir.
When mounting with option 'index=on' and no 'upperdir', index is
implicitly disabled, so do not warn about no file handle support.
The issue was introduced with inodes index feature in v4.13, but this
patch will not apply cleanly before ovl_fill_super() re-factoring in
v4.15.
Fixes: 02bcd1577400 ("ovl: introduce the inodes index dir feature")
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/super.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -703,7 +703,8 @@ static int ovl_lower_dir(const char *nam
* The inodes index feature needs to encode and decode file
* handles, so it requires that all layers support them.
*/
- if (ofs->config.index && !ovl_can_decode_fh(path->dentry->d_sb)) {
+ if (ofs->config.index && ofs->config.upperdir &&
+ !ovl_can_decode_fh(path->dentry->d_sb)) {
ofs->config.index = false;
pr_warn("overlayfs: fs on '%s' does not support file handles, falling back to index=off.\n", name);
}
@@ -1257,11 +1258,16 @@ static int ovl_fill_super(struct super_b
if (err)
goto out_free_oe;
- if (!ofs->indexdir)
+ /* Force r/o mount with no index dir */
+ if (!ofs->indexdir) {
+ dput(ofs->workdir);
+ ofs->workdir = NULL;
sb->s_flags |= SB_RDONLY;
+ }
+
}
- /* Show index=off/on in /proc/mounts for any of the reasons above */
+ /* Show index=off in /proc/mounts for forced r/o mount */
if (!ofs->indexdir)
ofs->config.index = false;
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.15/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.15/ovl-take-mnt_want_write-for-work-index-dir-setup.patch
queue-4.15/ovl-hash-directory-inodes-for-fsnotify.patch
queue-4.15/ovl-force-r-o-mount-when-index-dir-creation-fails.patch
queue-4.15/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
ovl: fix failure to fsync lower dir
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-fix-failure-to-fsync-lower-dir.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d796e77f1dd541fe34481af2eee6454688d13982 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 8 Nov 2017 09:39:46 +0200
Subject: ovl: fix failure to fsync lower dir
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Amir Goldstein <amir73il(a)gmail.com>
commit d796e77f1dd541fe34481af2eee6454688d13982 upstream.
As a writable mount, it is not expected for overlayfs to return
EINVAL/EROFS for fsync, even if dir/file is not changed.
This commit fixes the case of fsync of directory, which is easier to
address, because overlayfs already implements fsync file operation for
directories.
The problem reported by Raphael is that new PostgreSQL 10.0 with a
database in overlayfs where lower layer in squashfs fails to start.
The failure is due to fsync error, when PostgreSQL does fsync on all
existing db directories on startup and a specific directory exists
lower layer with no changes.
Reported-by: Raphael Hertzog <raphael(a)ouaza.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Tested-by: Raphaël Hertzog <hertzog(a)debian.org>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -769,10 +769,14 @@ static int ovl_dir_fsync(struct file *fi
struct dentry *dentry = file->f_path.dentry;
struct file *realfile = od->realfile;
+ /* Nothing to sync for lower */
+ if (!OVL_TYPE_UPPER(ovl_path_type(dentry)))
+ return 0;
+
/*
* Need to check if we started out being a lower dir, but got copied up
*/
- if (!od->is_upper && OVL_TYPE_UPPER(ovl_path_type(dentry))) {
+ if (!od->is_upper) {
struct inode *inode = file_inode(file);
realfile = READ_ONCE(od->upperfile);
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.15/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.15/ovl-take-mnt_want_write-for-work-index-dir-setup.patch
queue-4.15/ovl-hash-directory-inodes-for-fsnotify.patch
queue-4.15/ovl-force-r-o-mount-when-index-dir-creation-fails.patch
queue-4.15/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
objtool: Fix switch-table detection
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
objtool-fix-switch-table-detection.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 99ce7962d52d1948ad6f2785e308d48e76e0a6ef Mon Sep 17 00:00:00 2001
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Thu, 8 Feb 2018 14:02:32 +0100
Subject: objtool: Fix switch-table detection
From: Peter Zijlstra <peterz(a)infradead.org>
commit 99ce7962d52d1948ad6f2785e308d48e76e0a6ef upstream.
Linus reported that GCC-7.3 generated a switch-table construct that
confused objtool. It turns out that, in particular due to KASAN, it is
possible to have unrelated .rodata usage in between the .rodata setup
for the switch-table and the following indirect jump.
The simple linear reverse search from the indirect jump would hit upon
the KASAN .rodata usage first and fail to find a switch_table,
resulting in a spurious 'sibling call with modified stack frame'
warning.
Fix this by creating a 'jump-stack' which we can 'unwind' during
reversal, thereby skipping over much of the in-between code.
This is not fool proof by any means, but is sufficient to make the
known cases work. Future work would be to construct more comprehensive
flow analysis code.
Reported-and-tested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20180208130232.GF25235@hirez.programming.kicks-ass…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/objtool/check.c | 41 +++++++++++++++++++++++++++++++++++++++--
tools/objtool/check.h | 1 +
2 files changed, 40 insertions(+), 2 deletions(-)
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -851,8 +851,14 @@ static int add_switch_table(struct objto
* This is a fairly uncommon pattern which is new for GCC 6. As of this
* writing, there are 11 occurrences of it in the allmodconfig kernel.
*
+ * As of GCC 7 there are quite a few more of these and the 'in between' code
+ * is significant. Esp. with KASAN enabled some of the code between the mov
+ * and jmpq uses .rodata itself, which can confuse things.
+ *
* TODO: Once we have DWARF CFI and smarter instruction decoding logic,
* ensure the same register is used in the mov and jump instructions.
+ *
+ * NOTE: RETPOLINE made it harder still to decode dynamic jumps.
*/
static struct rela *find_switch_table(struct objtool_file *file,
struct symbol *func,
@@ -874,12 +880,25 @@ static struct rela *find_switch_table(st
text_rela->addend + 4);
if (!rodata_rela)
return NULL;
+
file->ignore_unreachables = true;
return rodata_rela;
}
/* case 3 */
- func_for_each_insn_continue_reverse(file, func, insn) {
+ /*
+ * Backward search using the @first_jump_src links, these help avoid
+ * much of the 'in between' code. Which avoids us getting confused by
+ * it.
+ */
+ for (insn = list_prev_entry(insn, list);
+
+ &insn->list != &file->insn_list &&
+ insn->sec == func->sec &&
+ insn->offset >= func->offset;
+
+ insn = insn->first_jump_src ?: list_prev_entry(insn, list)) {
+
if (insn->type == INSN_JUMP_DYNAMIC)
break;
@@ -909,14 +928,32 @@ static struct rela *find_switch_table(st
return NULL;
}
+
static int add_func_switch_tables(struct objtool_file *file,
struct symbol *func)
{
- struct instruction *insn, *prev_jump = NULL;
+ struct instruction *insn, *last = NULL, *prev_jump = NULL;
struct rela *rela, *prev_rela = NULL;
int ret;
func_for_each_insn(file, func, insn) {
+ if (!last)
+ last = insn;
+
+ /*
+ * Store back-pointers for unconditional forward jumps such
+ * that find_switch_table() can back-track using those and
+ * avoid some potentially confusing code.
+ */
+ if (insn->type == INSN_JUMP_UNCONDITIONAL && insn->jump_dest &&
+ insn->offset > last->offset &&
+ insn->jump_dest->offset > insn->offset &&
+ !insn->jump_dest->first_jump_src) {
+
+ insn->jump_dest->first_jump_src = insn;
+ last = insn->jump_dest;
+ }
+
if (insn->type != INSN_JUMP_DYNAMIC)
continue;
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -47,6 +47,7 @@ struct instruction {
bool alt_group, visited, dead_end, ignore, hint, save, restore, ignore_alts;
struct symbol *call_dest;
struct instruction *jump_dest;
+ struct instruction *first_jump_src;
struct list_head alts;
struct symbol *func;
struct stack_op stack_op;
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.15/clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
queue-4.15/objtool-fix-switch-table-detection.patch
queue-4.15/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.15/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 05:02:38 -0500
Subject: mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.
Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct. With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr. Which is very wrong.
So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <dhowells(a)redhat.com>
Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com>
Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mn10300/mm/misalignment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mn10300/mm/misalignment.c
+++ b/arch/mn10300/mm/misalignment.c
@@ -437,7 +437,7 @@ transfer_failed:
info.si_signo = SIGSEGV;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = SEGV_MAPERR;
info.si_addr = (void *) regs->pc;
force_sig_info(SIGSEGV, &info, current);
return;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.15/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.15/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-4.15/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
This is a note to let you know that I've just added the patch titled
ftrace: Remove incorrect setting of glob search field
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ftrace-remove-incorrect-setting-of-glob-search-field.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7b6586562708d2b3a04fe49f217ddbadbbbb0546 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Mon, 5 Feb 2018 22:05:31 -0500
Subject: ftrace: Remove incorrect setting of glob search field
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit 7b6586562708d2b3a04fe49f217ddbadbbbb0546 upstream.
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal to glob only if glob started with '!' or '*'. In the former case
we would've buggered off with -EINVAL (not = 1). In the latter we
would've set func_g.search equal to glob + 1, calculated the length of
that thing in func_g.len and proceeded to reset func_g.search back to
glob.
Suppose the glob is e.g. *foo*. We end up with
func_g.type = MATCH_MIDDLE_ONLY;
func_g.len = 3;
func_g.search = "*foo";
Feeding that to ftrace_match_record() will not do anything sane - we
will be looking for names containing "*foo" (->len is ignored for that
one).
Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
Reviewed-by: Dmitry Safonov <0x7f454c46(a)gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/ftrace.c | 1 -
1 file changed, 1 deletion(-)
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4456,7 +4456,6 @@ unregister_ftrace_function_probe_func(ch
func_g.type = filter_parse_regex(glob, strlen(glob),
&func_g.search, ¬);
func_g.len = strlen(func_g.search);
- func_g.search = glob;
/* we do not support '!' for function probes */
if (WARN_ON(not))
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.15/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.15/ftrace-remove-incorrect-setting-of-glob-search-field.patch
queue-4.15/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Avoid PPS HW/SW state mismatch due to rounding
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5643205c6340b565a3be0fe0e7305dc4aa551c74 Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Wed, 29 Nov 2017 19:51:37 +0200
Subject: drm/i915: Avoid PPS HW/SW state mismatch due to rounding
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Imre Deak <imre.deak(a)intel.com>
commit 5643205c6340b565a3be0fe0e7305dc4aa551c74 upstream.
We store a SW state of the t11_t12 timing in 100usec units but have to
program it in 100msec as required by HW. The rounding used during
programming means there will be a mismatch between the SW and HW states
of this value triggering a "PPS state mismatch" error. Avoid this by
storing the already rounded-up value in the SW state.
Note that we still calculate panel_power_cycle_delay with the finer
100usec granularity to avoid any needless waits using that version of
the delay.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
Cc: joks <joks(a)linux.pl>
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129175137.2889-1-imre.de…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5336,6 +5336,12 @@ intel_dp_init_panel_power_sequencer(stru
*/
final->t8 = 1;
final->t9 = 1;
+
+ /*
+ * HW has only a 100msec granularity for t11_t12 so round it up
+ * accordingly.
+ */
+ final->t11_t12 = roundup(final->t11_t12, 100 * 10);
}
static void
Patches currently in stable-queue which might be from imre.deak(a)intel.com are
queue-4.15/drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
This is a note to let you know that I've just added the patch titled
devpts: fix error handling in devpts_mntget()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
devpts-fix-error-handling-in-devpts_mntget.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c9cc8d01fb04117928830449388512a5047569c9 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 31 Jan 2018 00:49:18 -0800
Subject: devpts: fix error handling in devpts_mntget()
From: Eric Biggers <ebiggers(a)google.com>
commit c9cc8d01fb04117928830449388512a5047569c9 upstream.
If devpts_ptmx_path() returns an error code, then devpts_mntget()
dereferences an ERR_PTR():
BUG: unable to handle kernel paging request at fffffffffffffff5
IP: devpts_mntget+0x13f/0x280 fs/devpts/inode.c:173
Fix it by returning early in the error paths.
Reproducer:
#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <sys/ioctl.h>
#define TIOCGPTPEER _IO('T', 0x41)
int main()
{
for (;;) {
int fd = open("/dev/ptmx", 0);
unshare(CLONE_NEWNS);
ioctl(fd, TIOCGPTPEER, 0);
}
}
Fixes: 311fc65c9fb9 ("pty: Repair TIOCGPTPEER")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/devpts/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -168,11 +168,11 @@ struct vfsmount *devpts_mntget(struct fi
dput(path.dentry);
if (err) {
mntput(path.mnt);
- path.mnt = ERR_PTR(err);
+ return ERR_PTR(err);
}
if (DEVPTS_SB(path.mnt->mnt_sb) != fsi) {
mntput(path.mnt);
- path.mnt = ERR_PTR(-ENODEV);
+ return ERR_PTR(-ENODEV);
}
return path.mnt;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.15/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.15/crypto-poly1305-remove-setkey-method.patch
queue-4.15/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.15/devpts-fix-error-handling-in-devpts_mntget.patch
queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: marvell: add Ethernet aliases
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-dts-marvell-add-ethernet-aliases.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 474c5885582c4a79c21bcf01ed98f98c935f1f4a Mon Sep 17 00:00:00 2001
From: Yan Markman <ymarkman(a)marvell.com>
Date: Wed, 3 Jan 2018 16:18:52 +0100
Subject: arm64: dts: marvell: add Ethernet aliases
From: Yan Markman <ymarkman(a)marvell.com>
commit 474c5885582c4a79c21bcf01ed98f98c935f1f4a upstream.
This patch adds Ethernet aliases in the Marvell Armada 7040 DB, 8040 DB
and 8040 mcbin device trees so that the bootloader setup the MAC
addresses correctly.
Signed-off-by: Yan Markman <ymarkman(a)marvell.com>
[Antoine: commit message, small fixes]
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 6 ++++++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 7 +++++++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 6 ++++++
3 files changed, 19 insertions(+)
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -61,6 +61,12 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth1;
+ ethernet2 = &cpm_eth2;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "usb3h0-vbus";
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -61,6 +61,13 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth2;
+ ethernet2 = &cps_eth0;
+ ethernet3 = &cps_eth1;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "cpm-usb3h0-vbus";
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -62,6 +62,12 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cps_eth0;
+ ethernet2 = &cps_eth1;
+ };
+
/* Regulator labels correspond with schematics */
v_3_3: regulator-3-3v {
compatible = "regulator-fixed";
Patches currently in stable-queue which might be from ymarkman(a)marvell.com are
queue-4.15/arm64-dts-marvell-add-ethernet-aliases.patch
This is a note to let you know that I've just added the patch titled
acpi, nfit: fix register dimm error handling
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-nfit-fix-register-dimm-error-handling.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 23fbd7c70aec7600e3227eb24259fc55bf6e4881 Mon Sep 17 00:00:00 2001
From: Toshi Kani <toshi.kani(a)hpe.com>
Date: Fri, 2 Feb 2018 14:00:36 -0700
Subject: acpi, nfit: fix register dimm error handling
From: Toshi Kani <toshi.kani(a)hpe.com>
commit 23fbd7c70aec7600e3227eb24259fc55bf6e4881 upstream.
A NULL pointer reference kernel bug was observed when
acpi_nfit_add_dimm() called in acpi_nfit_register_dimms() failed. This
error path does not set nfit_mem->nvdimm, but the 2nd
list_for_each_entry() loop in the function assumes it's always set. Add
a check to nfit_mem->nvdimm.
Fixes: ba9c8dd3c222 ("acpi, nfit: add dimm device notification support")
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/nfit/core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1867,6 +1867,9 @@ static int acpi_nfit_register_dimms(stru
struct kernfs_node *nfit_kernfs;
nvdimm = nfit_mem->nvdimm;
+ if (!nvdimm)
+ continue;
+
nfit_kernfs = sysfs_get_dirent(nvdimm_kobj(nvdimm)->sd, "nfit");
if (nfit_kernfs)
nfit_mem->flags_attr = sysfs_get_dirent(nfit_kernfs,
Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are
queue-4.15/acpi-nfit-fix-register-dimm-error-handling.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: Fix crash after bad bar setup on driver attachment
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-fix-crash-after-bad-bar-setup-on-driver-attachment.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e4b9794efdce13242f4af6682f3ed48ce3864a87 Mon Sep 17 00:00:00 2001
From: James Smart <jsmart2021(a)gmail.com>
Date: Mon, 20 Nov 2017 16:00:31 -0800
Subject: scsi: lpfc: Fix crash after bad bar setup on driver attachment
From: James Smart <jsmart2021(a)gmail.com>
commit e4b9794efdce13242f4af6682f3ed48ce3864a87 upstream.
In test cases where an instance of the driver is detached and
reattached, the driver will crash on reattachment. There is a compound
if statement that will skip over the bar setup if the pci_resource_start
call is not successful. The driver erroneously returns success to its
bar setup in this scenario even though the bars aren't properly
configured.
Rework the offending code segment for proper initialization steps. If
the pci_resource_start call fails, -ENOMEM is now returned.
Sample stack:
rport-5:0-10: blocked FC remote port time out: removing rport
BUG: unable to handle kernel NULL pointer dereference at (null)
... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
...
... RIP: 0010:... ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
Call Trace:
... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc]
... ? __alloc_pages_nodemask+0x176/0x420
... ? __kmalloc+0x2e/0x230
... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc]
... ? mempool_alloc+0x69/0x170
... ? dma_generic_alloc_coherent+0x8f/0x140
... lpfc_sli_issue_mbox+0xf/0x20 [lpfc]
... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc]
... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc]
... lpfc_pci_probe_one+0x445/0x16f0 [lpfc]
... local_pci_probe+0x45/0xa0
... work_for_cpu_fn+0x14/0x20
... process_one_work+0x17a/0x440
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_init.c | 84 +++++++++++++++++++++++++-----------------
1 file changed, 51 insertions(+), 33 deletions(-)
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -9413,44 +9413,62 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba
lpfc_sli4_bar0_register_memmap(phba, if_type);
}
- if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) &&
- (pci_resource_start(pdev, PCI_64BIT_BAR2))) {
- /*
- * Map SLI4 if type 0 HBA Control Register base to a kernel
- * virtual address and setup the registers.
- */
- phba->pci_bar1_map = pci_resource_start(pdev, PCI_64BIT_BAR2);
- bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2);
- phba->sli4_hba.ctrl_regs_memmap_p =
- ioremap(phba->pci_bar1_map, bar1map_len);
- if (!phba->sli4_hba.ctrl_regs_memmap_p) {
- dev_printk(KERN_ERR, &pdev->dev,
- "ioremap failed for SLI4 HBA control registers.\n");
+ if (if_type == LPFC_SLI_INTF_IF_TYPE_0) {
+ if (pci_resource_start(pdev, PCI_64BIT_BAR2)) {
+ /*
+ * Map SLI4 if type 0 HBA Control Register base to a
+ * kernel virtual address and setup the registers.
+ */
+ phba->pci_bar1_map = pci_resource_start(pdev,
+ PCI_64BIT_BAR2);
+ bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2);
+ phba->sli4_hba.ctrl_regs_memmap_p =
+ ioremap(phba->pci_bar1_map,
+ bar1map_len);
+ if (!phba->sli4_hba.ctrl_regs_memmap_p) {
+ dev_err(&pdev->dev,
+ "ioremap failed for SLI4 HBA "
+ "control registers.\n");
+ error = -ENOMEM;
+ goto out_iounmap_conf;
+ }
+ phba->pci_bar2_memmap_p =
+ phba->sli4_hba.ctrl_regs_memmap_p;
+ lpfc_sli4_bar1_register_memmap(phba);
+ } else {
+ error = -ENOMEM;
goto out_iounmap_conf;
}
- phba->pci_bar2_memmap_p = phba->sli4_hba.ctrl_regs_memmap_p;
- lpfc_sli4_bar1_register_memmap(phba);
}
- if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) &&
- (pci_resource_start(pdev, PCI_64BIT_BAR4))) {
- /*
- * Map SLI4 if type 0 HBA Doorbell Register base to a kernel
- * virtual address and setup the registers.
- */
- phba->pci_bar2_map = pci_resource_start(pdev, PCI_64BIT_BAR4);
- bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4);
- phba->sli4_hba.drbl_regs_memmap_p =
- ioremap(phba->pci_bar2_map, bar2map_len);
- if (!phba->sli4_hba.drbl_regs_memmap_p) {
- dev_printk(KERN_ERR, &pdev->dev,
- "ioremap failed for SLI4 HBA doorbell registers.\n");
- goto out_iounmap_ctrl;
- }
- phba->pci_bar4_memmap_p = phba->sli4_hba.drbl_regs_memmap_p;
- error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0);
- if (error)
+ if (if_type == LPFC_SLI_INTF_IF_TYPE_0) {
+ if (pci_resource_start(pdev, PCI_64BIT_BAR4)) {
+ /*
+ * Map SLI4 if type 0 HBA Doorbell Register base to
+ * a kernel virtual address and setup the registers.
+ */
+ phba->pci_bar2_map = pci_resource_start(pdev,
+ PCI_64BIT_BAR4);
+ bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4);
+ phba->sli4_hba.drbl_regs_memmap_p =
+ ioremap(phba->pci_bar2_map,
+ bar2map_len);
+ if (!phba->sli4_hba.drbl_regs_memmap_p) {
+ dev_err(&pdev->dev,
+ "ioremap failed for SLI4 HBA"
+ " doorbell registers.\n");
+ error = -ENOMEM;
+ goto out_iounmap_ctrl;
+ }
+ phba->pci_bar4_memmap_p =
+ phba->sli4_hba.drbl_regs_memmap_p;
+ error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0);
+ if (error)
+ goto out_iounmap_all;
+ } else {
+ error = -ENOMEM;
goto out_iounmap_all;
+ }
}
return 0;
Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are
queue-4.14/scsi-lpfc-fix-crash-after-bad-bar-setup-on-driver-attachment.patch
This is a note to let you know that I've just added the patch titled
scsi: cxlflash: Reset command ioasc
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-cxlflash-reset-command-ioasc.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 96cf727fe8f102bf92150b741db71ee39fb8c521 Mon Sep 17 00:00:00 2001
From: Uma Krishnan <ukrishn(a)linux.vnet.ibm.com>
Date: Wed, 3 Jan 2018 16:54:02 -0600
Subject: scsi: cxlflash: Reset command ioasc
From: Uma Krishnan <ukrishn(a)linux.vnet.ibm.com>
commit 96cf727fe8f102bf92150b741db71ee39fb8c521 upstream.
In the event of a command failure, cxlflash returns the failure to the upper
layers to process. After processing the error, when the command is queued
again, the private command structure will not be zeroed and the ioasc could be
stale. Per the SISLite specification, the AFU only sets the ioasc in the
presence of a failure. Thus, even though the original command succeeds the
second time, the command is considered a failure due to stale ioasc. This
cycle repeats indefinitely and can cause a hang or IO failure.
To fix the issue, clear the ioasc before queuing any command.
[mkp: added Cc: stable per request]
Fixes: 479ad8e9d48c ("scsi: cxlflash: Remove zeroing of private command data")
Signed-off-by: Uma Krishnan <ukrishn(a)linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/cxlflash/main.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -620,6 +620,7 @@ static int cxlflash_queuecommand(struct
cmd->parent = afu;
cmd->hwq_index = hwq_index;
+ cmd->sa.ioasc = 0;
cmd->rcb.ctx_id = hwq->ctx_hndl;
cmd->rcb.msi = SISL_MSI_RRQ_UPDATED;
cmd->rcb.port_sel = CHAN2PORTMASK(scp->device->channel);
Patches currently in stable-queue which might be from ukrishn(a)linux.vnet.ibm.com are
queue-4.14/scsi-cxlflash-reset-command-ioasc.patch
This is a note to let you know that I've just added the patch titled
scsi: core: Ensure that the SCSI error handler gets woken up
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-core-ensure-that-the-scsi-error-handler-gets-woken-up.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3bd6f43f5cb3714f70c591514f344389df593501 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Mon, 4 Dec 2017 10:06:23 -0800
Subject: scsi: core: Ensure that the SCSI error handler gets woken up
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 3bd6f43f5cb3714f70c591514f344389df593501 upstream.
If scsi_eh_scmd_add() is called concurrently with
scsi_host_queue_ready() while shost->host_blocked > 0 then it can
happen that neither function wakes up the SCSI error handler. Fix
this by making every function that decreases the host_busy counter
wake up the error handler if necessary and by protecting the
host_failed checks with the SCSI host lock.
Reported-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
References: https://marc.info/?l=linux-kernel&m=150461610630736
Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Tested-by: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Konstantin Khorenko <khorenko(a)virtuozzo.com>
Cc: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/hosts.c | 6 ++++++
drivers/scsi/scsi_error.c | 18 ++++++++++++++++--
drivers/scsi/scsi_lib.c | 39 ++++++++++++++++++++++++++++-----------
include/scsi/scsi_host.h | 2 ++
4 files changed, 52 insertions(+), 13 deletions(-)
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -318,6 +318,9 @@ static void scsi_host_dev_release(struct
scsi_proc_hostdir_rm(shost->hostt);
+ /* Wait for functions invoked through call_rcu(&shost->rcu, ...) */
+ rcu_barrier();
+
if (shost->tmf_work_q)
destroy_workqueue(shost->tmf_work_q);
if (shost->ehandler)
@@ -325,6 +328,8 @@ static void scsi_host_dev_release(struct
if (shost->work_q)
destroy_workqueue(shost->work_q);
+ destroy_rcu_head(&shost->rcu);
+
if (shost->shost_state == SHOST_CREATED) {
/*
* Free the shost_dev device name here if scsi_host_alloc()
@@ -399,6 +404,7 @@ struct Scsi_Host *scsi_host_alloc(struct
INIT_LIST_HEAD(&shost->starved_list);
init_waitqueue_head(&shost->host_wait);
mutex_init(&shost->scan_mutex);
+ init_rcu_head(&shost->rcu);
index = ida_simple_get(&host_index_ida, 0, 0, GFP_KERNEL);
if (index < 0)
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -220,6 +220,17 @@ static void scsi_eh_reset(struct scsi_cm
}
}
+static void scsi_eh_inc_host_failed(struct rcu_head *head)
+{
+ struct Scsi_Host *shost = container_of(head, typeof(*shost), rcu);
+ unsigned long flags;
+
+ spin_lock_irqsave(shost->host_lock, flags);
+ shost->host_failed++;
+ scsi_eh_wakeup(shost);
+ spin_unlock_irqrestore(shost->host_lock, flags);
+}
+
/**
* scsi_eh_scmd_add - add scsi cmd to error handling.
* @scmd: scmd to run eh on.
@@ -242,9 +253,12 @@ void scsi_eh_scmd_add(struct scsi_cmnd *
scsi_eh_reset(scmd);
list_add_tail(&scmd->eh_entry, &shost->eh_cmd_q);
- shost->host_failed++;
- scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
+ /*
+ * Ensure that all tasks observe the host state change before the
+ * host_failed change.
+ */
+ call_rcu(&shost->rcu, scsi_eh_inc_host_failed);
}
/**
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -318,22 +318,39 @@ static void scsi_init_cmd_errh(struct sc
cmd->cmd_len = scsi_command_size(cmd->cmnd);
}
-void scsi_device_unbusy(struct scsi_device *sdev)
+/*
+ * Decrement the host_busy counter and wake up the error handler if necessary.
+ * Avoid as follows that the error handler is not woken up if shost->host_busy
+ * == shost->host_failed: use call_rcu() in scsi_eh_scmd_add() in combination
+ * with an RCU read lock in this function to ensure that this function in its
+ * entirety either finishes before scsi_eh_scmd_add() increases the
+ * host_failed counter or that it notices the shost state change made by
+ * scsi_eh_scmd_add().
+ */
+static void scsi_dec_host_busy(struct Scsi_Host *shost)
{
- struct Scsi_Host *shost = sdev->host;
- struct scsi_target *starget = scsi_target(sdev);
unsigned long flags;
+ rcu_read_lock();
atomic_dec(&shost->host_busy);
- if (starget->can_queue > 0)
- atomic_dec(&starget->target_busy);
-
- if (unlikely(scsi_host_in_recovery(shost) &&
- (shost->host_failed || shost->host_eh_scheduled))) {
+ if (unlikely(scsi_host_in_recovery(shost))) {
spin_lock_irqsave(shost->host_lock, flags);
- scsi_eh_wakeup(shost);
+ if (shost->host_failed || shost->host_eh_scheduled)
+ scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
}
+ rcu_read_unlock();
+}
+
+void scsi_device_unbusy(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev->host;
+ struct scsi_target *starget = scsi_target(sdev);
+
+ scsi_dec_host_busy(shost);
+
+ if (starget->can_queue > 0)
+ atomic_dec(&starget->target_busy);
atomic_dec(&sdev->device_busy);
}
@@ -1532,7 +1549,7 @@ starved:
list_add_tail(&sdev->starved_entry, &shost->starved_list);
spin_unlock_irq(shost->host_lock);
out_dec:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
return 0;
}
@@ -1993,7 +2010,7 @@ static blk_status_t scsi_queue_rq(struct
return BLK_STS_OK;
out_dec_host_busy:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
out_dec_target_busy:
if (scsi_target(sdev)->can_queue > 0)
atomic_dec(&scsi_target(sdev)->target_busy);
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -571,6 +571,8 @@ struct Scsi_Host {
struct blk_mq_tag_set tag_set;
};
+ struct rcu_head rcu;
+
atomic_t host_busy; /* commands actually active on low-level */
atomic_t host_blocked;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/scsi-core-ensure-that-the-scsi-error-handler-gets-woken-up.patch
queue-4.14/pktcdvd-fix-pkt_setup_dev-error-path.patch
queue-4.14/pktcdvd-fix-a-recently-introduced-null-pointer-dereference.patch
This is a note to let you know that I've just added the patch titled
ovl: take mnt_want_write() for removing impure xattr
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-take-mnt_want_write-for-removing-impure-xattr.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a5a927a7c82e28ea76599dee4019c41e372c911f Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 3 Jan 2018 18:54:42 +0200
Subject: ovl: take mnt_want_write() for removing impure xattr
From: Amir Goldstein <amir73il(a)gmail.com>
commit a5a927a7c82e28ea76599dee4019c41e372c911f upstream.
The optimization in ovl_cache_get_impure() that tries to remove an
unneeded "impure" xattr needs to take mnt_want_write() on upper fs.
Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs")
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -575,8 +575,15 @@ static struct ovl_dir_cache *ovl_cache_g
return ERR_PTR(res);
}
if (list_empty(&cache->entries)) {
- /* Good oportunity to get rid of an unnecessary "impure" flag */
- ovl_do_removexattr(ovl_dentry_upper(dentry), OVL_XATTR_IMPURE);
+ /*
+ * A good opportunity to get rid of an unneeded "impure" flag.
+ * Removing the "impure" xattr is best effort.
+ */
+ if (!ovl_want_write(dentry)) {
+ ovl_do_removexattr(ovl_dentry_upper(dentry),
+ OVL_XATTR_IMPURE);
+ ovl_drop_write(dentry);
+ }
ovl_clear_flag(OVL_IMPURE, d_inode(dentry));
kfree(cache);
return NULL;
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.14/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.14/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
ovl: fix failure to fsync lower dir
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-fix-failure-to-fsync-lower-dir.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d796e77f1dd541fe34481af2eee6454688d13982 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 8 Nov 2017 09:39:46 +0200
Subject: ovl: fix failure to fsync lower dir
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Amir Goldstein <amir73il(a)gmail.com>
commit d796e77f1dd541fe34481af2eee6454688d13982 upstream.
As a writable mount, it is not expected for overlayfs to return
EINVAL/EROFS for fsync, even if dir/file is not changed.
This commit fixes the case of fsync of directory, which is easier to
address, because overlayfs already implements fsync file operation for
directories.
The problem reported by Raphael is that new PostgreSQL 10.0 with a
database in overlayfs where lower layer in squashfs fails to start.
The failure is due to fsync error, when PostgreSQL does fsync on all
existing db directories on startup and a specific directory exists
lower layer with no changes.
Reported-by: Raphael Hertzog <raphael(a)ouaza.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Tested-by: Raphaël Hertzog <hertzog(a)debian.org>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -751,10 +751,14 @@ static int ovl_dir_fsync(struct file *fi
struct dentry *dentry = file->f_path.dentry;
struct file *realfile = od->realfile;
+ /* Nothing to sync for lower */
+ if (!OVL_TYPE_UPPER(ovl_path_type(dentry)))
+ return 0;
+
/*
* Need to check if we started out being a lower dir, but got copied up
*/
- if (!od->is_upper && OVL_TYPE_UPPER(ovl_path_type(dentry))) {
+ if (!od->is_upper) {
struct inode *inode = file_inode(file);
realfile = READ_ONCE(od->upperfile);
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.14/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.14/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
objtool: Fix switch-table detection
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
objtool-fix-switch-table-detection.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 99ce7962d52d1948ad6f2785e308d48e76e0a6ef Mon Sep 17 00:00:00 2001
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Thu, 8 Feb 2018 14:02:32 +0100
Subject: objtool: Fix switch-table detection
From: Peter Zijlstra <peterz(a)infradead.org>
commit 99ce7962d52d1948ad6f2785e308d48e76e0a6ef upstream.
Linus reported that GCC-7.3 generated a switch-table construct that
confused objtool. It turns out that, in particular due to KASAN, it is
possible to have unrelated .rodata usage in between the .rodata setup
for the switch-table and the following indirect jump.
The simple linear reverse search from the indirect jump would hit upon
the KASAN .rodata usage first and fail to find a switch_table,
resulting in a spurious 'sibling call with modified stack frame'
warning.
Fix this by creating a 'jump-stack' which we can 'unwind' during
reversal, thereby skipping over much of the in-between code.
This is not fool proof by any means, but is sufficient to make the
known cases work. Future work would be to construct more comprehensive
flow analysis code.
Reported-and-tested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20180208130232.GF25235@hirez.programming.kicks-ass…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/objtool/check.c | 41 +++++++++++++++++++++++++++++++++++++++--
tools/objtool/check.h | 1 +
2 files changed, 40 insertions(+), 2 deletions(-)
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -851,8 +851,14 @@ static int add_switch_table(struct objto
* This is a fairly uncommon pattern which is new for GCC 6. As of this
* writing, there are 11 occurrences of it in the allmodconfig kernel.
*
+ * As of GCC 7 there are quite a few more of these and the 'in between' code
+ * is significant. Esp. with KASAN enabled some of the code between the mov
+ * and jmpq uses .rodata itself, which can confuse things.
+ *
* TODO: Once we have DWARF CFI and smarter instruction decoding logic,
* ensure the same register is used in the mov and jump instructions.
+ *
+ * NOTE: RETPOLINE made it harder still to decode dynamic jumps.
*/
static struct rela *find_switch_table(struct objtool_file *file,
struct symbol *func,
@@ -874,12 +880,25 @@ static struct rela *find_switch_table(st
text_rela->addend + 4);
if (!rodata_rela)
return NULL;
+
file->ignore_unreachables = true;
return rodata_rela;
}
/* case 3 */
- func_for_each_insn_continue_reverse(file, func, insn) {
+ /*
+ * Backward search using the @first_jump_src links, these help avoid
+ * much of the 'in between' code. Which avoids us getting confused by
+ * it.
+ */
+ for (insn = list_prev_entry(insn, list);
+
+ &insn->list != &file->insn_list &&
+ insn->sec == func->sec &&
+ insn->offset >= func->offset;
+
+ insn = insn->first_jump_src ?: list_prev_entry(insn, list)) {
+
if (insn->type == INSN_JUMP_DYNAMIC)
break;
@@ -909,14 +928,32 @@ static struct rela *find_switch_table(st
return NULL;
}
+
static int add_func_switch_tables(struct objtool_file *file,
struct symbol *func)
{
- struct instruction *insn, *prev_jump = NULL;
+ struct instruction *insn, *last = NULL, *prev_jump = NULL;
struct rela *rela, *prev_rela = NULL;
int ret;
func_for_each_insn(file, func, insn) {
+ if (!last)
+ last = insn;
+
+ /*
+ * Store back-pointers for unconditional forward jumps such
+ * that find_switch_table() can back-track using those and
+ * avoid some potentially confusing code.
+ */
+ if (insn->type == INSN_JUMP_UNCONDITIONAL && insn->jump_dest &&
+ insn->offset > last->offset &&
+ insn->jump_dest->offset > insn->offset &&
+ !insn->jump_dest->first_jump_src) {
+
+ insn->jump_dest->first_jump_src = insn;
+ last = insn->jump_dest;
+ }
+
if (insn->type != INSN_JUMP_DYNAMIC)
continue;
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -47,6 +47,7 @@ struct instruction {
bool alt_group, visited, dead_end, ignore, hint, save, restore, ignore_alts;
struct symbol *call_dest;
struct instruction *jump_dest;
+ struct instruction *first_jump_src;
struct list_head alts;
struct symbol *func;
struct stack_op stack_op;
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.14/clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
queue-4.14/objtool-fix-switch-table-detection.patch
queue-4.14/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.14/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
queue-4.14/sched-wait-fix-add_wait_queue-behavioral-change.patch
This is a note to let you know that I've just added the patch titled
mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 05:02:38 -0500
Subject: mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.
Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct. With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr. Which is very wrong.
So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <dhowells(a)redhat.com>
Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com>
Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mn10300/mm/misalignment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mn10300/mm/misalignment.c
+++ b/arch/mn10300/mm/misalignment.c
@@ -437,7 +437,7 @@ transfer_failed:
info.si_signo = SIGSEGV;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = SEGV_MAPERR;
info.si_addr = (void *) regs->pc;
force_sig_info(SIGSEGV, &info, current);
return;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.14/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.14/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-4.14/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
This is a note to let you know that I've just added the patch titled
ftrace: Remove incorrect setting of glob search field
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ftrace-remove-incorrect-setting-of-glob-search-field.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7b6586562708d2b3a04fe49f217ddbadbbbb0546 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Mon, 5 Feb 2018 22:05:31 -0500
Subject: ftrace: Remove incorrect setting of glob search field
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit 7b6586562708d2b3a04fe49f217ddbadbbbb0546 upstream.
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal to glob only if glob started with '!' or '*'. In the former case
we would've buggered off with -EINVAL (not = 1). In the latter we
would've set func_g.search equal to glob + 1, calculated the length of
that thing in func_g.len and proceeded to reset func_g.search back to
glob.
Suppose the glob is e.g. *foo*. We end up with
func_g.type = MATCH_MIDDLE_ONLY;
func_g.len = 3;
func_g.search = "*foo";
Feeding that to ftrace_match_record() will not do anything sane - we
will be looking for names containing "*foo" (->len is ignored for that
one).
Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
Reviewed-by: Dmitry Safonov <0x7f454c46(a)gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/ftrace.c | 1 -
1 file changed, 1 deletion(-)
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4488,7 +4488,6 @@ unregister_ftrace_function_probe_func(ch
func_g.type = filter_parse_regex(glob, strlen(glob),
&func_g.search, ¬);
func_g.len = strlen(func_g.search);
- func_g.search = glob;
/* we do not support '!' for function probes */
if (WARN_ON(not))
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.14/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.14/ftrace-remove-incorrect-setting-of-glob-search-field.patch
queue-4.14/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Avoid PPS HW/SW state mismatch due to rounding
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5643205c6340b565a3be0fe0e7305dc4aa551c74 Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Wed, 29 Nov 2017 19:51:37 +0200
Subject: drm/i915: Avoid PPS HW/SW state mismatch due to rounding
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Imre Deak <imre.deak(a)intel.com>
commit 5643205c6340b565a3be0fe0e7305dc4aa551c74 upstream.
We store a SW state of the t11_t12 timing in 100usec units but have to
program it in 100msec as required by HW. The rounding used during
programming means there will be a mismatch between the SW and HW states
of this value triggering a "PPS state mismatch" error. Avoid this by
storing the already rounded-up value in the SW state.
Note that we still calculate panel_power_cycle_delay with the finer
100usec granularity to avoid any needless waits using that version of
the delay.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
Cc: joks <joks(a)linux.pl>
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129175137.2889-1-imre.de…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5340,6 +5340,12 @@ intel_dp_init_panel_power_sequencer(stru
*/
final->t8 = 1;
final->t9 = 1;
+
+ /*
+ * HW has only a 100msec granularity for t11_t12 so round it up
+ * accordingly.
+ */
+ final->t11_t12 = roundup(final->t11_t12, 100 * 10);
}
static void
Patches currently in stable-queue which might be from imre.deak(a)intel.com are
queue-4.14/drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
This is a note to let you know that I've just added the patch titled
devpts: fix error handling in devpts_mntget()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
devpts-fix-error-handling-in-devpts_mntget.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c9cc8d01fb04117928830449388512a5047569c9 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 31 Jan 2018 00:49:18 -0800
Subject: devpts: fix error handling in devpts_mntget()
From: Eric Biggers <ebiggers(a)google.com>
commit c9cc8d01fb04117928830449388512a5047569c9 upstream.
If devpts_ptmx_path() returns an error code, then devpts_mntget()
dereferences an ERR_PTR():
BUG: unable to handle kernel paging request at fffffffffffffff5
IP: devpts_mntget+0x13f/0x280 fs/devpts/inode.c:173
Fix it by returning early in the error paths.
Reproducer:
#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <sys/ioctl.h>
#define TIOCGPTPEER _IO('T', 0x41)
int main()
{
for (;;) {
int fd = open("/dev/ptmx", 0);
unshare(CLONE_NEWNS);
ioctl(fd, TIOCGPTPEER, 0);
}
}
Fixes: 311fc65c9fb9 ("pty: Repair TIOCGPTPEER")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/devpts/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -168,11 +168,11 @@ struct vfsmount *devpts_mntget(struct fi
dput(path.dentry);
if (err) {
mntput(path.mnt);
- path.mnt = ERR_PTR(err);
+ return ERR_PTR(err);
}
if (DEVPTS_SB(path.mnt->mnt_sb) != fsi) {
mntput(path.mnt);
- path.mnt = ERR_PTR(-ENODEV);
+ return ERR_PTR(-ENODEV);
}
return path.mnt;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.14/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.14/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.14/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.14/ubifs-free-the-encrypted-symlink-target.patch
queue-4.14/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.14/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.14/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.14/crypto-poly1305-remove-setkey-method.patch
queue-4.14/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.14/devpts-fix-error-handling-in-devpts_mntget.patch
queue-4.14/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.14/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: marvell: add Ethernet aliases
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-dts-marvell-add-ethernet-aliases.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 474c5885582c4a79c21bcf01ed98f98c935f1f4a Mon Sep 17 00:00:00 2001
From: Yan Markman <ymarkman(a)marvell.com>
Date: Wed, 3 Jan 2018 16:18:52 +0100
Subject: arm64: dts: marvell: add Ethernet aliases
From: Yan Markman <ymarkman(a)marvell.com>
commit 474c5885582c4a79c21bcf01ed98f98c935f1f4a upstream.
This patch adds Ethernet aliases in the Marvell Armada 7040 DB, 8040 DB
and 8040 mcbin device trees so that the bootloader setup the MAC
addresses correctly.
Signed-off-by: Yan Markman <ymarkman(a)marvell.com>
[Antoine: commit message, small fixes]
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 6 ++++++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 7 +++++++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 6 ++++++
3 files changed, 19 insertions(+)
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -61,6 +61,12 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth1;
+ ethernet2 = &cpm_eth2;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "usb3h0-vbus";
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -61,6 +61,13 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth2;
+ ethernet2 = &cps_eth0;
+ ethernet3 = &cps_eth1;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "cpm-usb3h0-vbus";
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -62,6 +62,12 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cps_eth0;
+ ethernet2 = &cps_eth1;
+ };
+
/* Regulator labels correspond with schematics */
v_3_3: regulator-3-3v {
compatible = "regulator-fixed";
Patches currently in stable-queue which might be from ymarkman(a)marvell.com are
queue-4.14/arm64-dts-marvell-add-ethernet-aliases.patch
This is a note to let you know that I've just added the patch titled
acpi, nfit: fix register dimm error handling
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-nfit-fix-register-dimm-error-handling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 23fbd7c70aec7600e3227eb24259fc55bf6e4881 Mon Sep 17 00:00:00 2001
From: Toshi Kani <toshi.kani(a)hpe.com>
Date: Fri, 2 Feb 2018 14:00:36 -0700
Subject: acpi, nfit: fix register dimm error handling
From: Toshi Kani <toshi.kani(a)hpe.com>
commit 23fbd7c70aec7600e3227eb24259fc55bf6e4881 upstream.
A NULL pointer reference kernel bug was observed when
acpi_nfit_add_dimm() called in acpi_nfit_register_dimms() failed. This
error path does not set nfit_mem->nvdimm, but the 2nd
list_for_each_entry() loop in the function assumes it's always set. Add
a check to nfit_mem->nvdimm.
Fixes: ba9c8dd3c222 ("acpi, nfit: add dimm device notification support")
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/nfit/core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1618,6 +1618,9 @@ static int acpi_nfit_register_dimms(stru
struct kernfs_node *nfit_kernfs;
nvdimm = nfit_mem->nvdimm;
+ if (!nvdimm)
+ continue;
+
nfit_kernfs = sysfs_get_dirent(nvdimm_kobj(nvdimm)->sd, "nfit");
if (nfit_kernfs)
nfit_mem->flags_attr = sysfs_get_dirent(nfit_kernfs,
Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are
queue-4.14/acpi-nfit-fix-register-dimm-error-handling.patch
This is a note to let you know that I've just added the patch titled
mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 05:02:38 -0500
Subject: mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.
Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct. With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr. Which is very wrong.
So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <dhowells(a)redhat.com>
Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com>
Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mn10300/mm/misalignment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mn10300/mm/misalignment.c
+++ b/arch/mn10300/mm/misalignment.c
@@ -437,7 +437,7 @@ transfer_failed:
info.si_signo = SIGSEGV;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = SEGV_MAPERR;
info.si_addr = (void *) regs->pc;
force_sig_info(SIGSEGV, &info, current);
return;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-3.18/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-3.18/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-3.18/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
This is a note to let you know that I've just added the patch titled
ACPI: sbshc: remove raw pointer from printk() message
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-sbshc-remove-raw-pointer-from-printk-message.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 43cdd1b716b26f6af16da4e145b6578f98798bf6 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 19 Jan 2018 10:06:03 +0100
Subject: ACPI: sbshc: remove raw pointer from printk() message
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
commit 43cdd1b716b26f6af16da4e145b6578f98798bf6 upstream.
There's no need to be printing a raw kernel pointer to the kernel log at
every boot. So just remove it, and change the whole message to use the
correct dev_info() call at the same time.
Reported-by: Wang Qize <wang_qize(a)venustech.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/sbshc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -309,8 +309,8 @@ static int acpi_smbus_hc_add(struct acpi
device->driver_data = hc;
acpi_ec_add_query_handler(hc->ec, hc->query_bit, NULL, smbus_alarm, hc);
- printk(KERN_INFO PREFIX "SBS HC: EC = 0x%p, offset = 0x%0x, query_bit = 0x%0x\n",
- hc->ec, hc->offset, hc->query_bit);
+ dev_info(&device->dev, "SBS HC: offset = 0x%0x, query_bit = 0x%0x\n",
+ hc->offset, hc->query_bit);
return 0;
}
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-3.18/media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
queue-3.18/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch
queue-3.18/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
queue-3.18/r8169-fix-rtl8168ep-take-too-long-to-complete-driver-initialization.patch
queue-3.18/usbip-fix-stub_rx-harden-cmd_submit-path-to-handle-malicious-input.patch
queue-3.18/tcp-release-sk_frag.page-in-tcp_disconnect.patch
queue-3.18/crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
queue-3.18/pktcdvd-fix-pkt_setup_dev-error-path.patch
queue-3.18/net-igmp-add-a-missing-rcu-locking-section.patch
queue-3.18/usbip-vhci-stop-printing-kernel-pointer-addresses-in-messages.patch
queue-3.18/cifs-fix-missing-put_xid-in-cifs_file_strict_mmap.patch
queue-3.18/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-3.18/cifs-fix-autonegotiate-security-settings-mismatch.patch
queue-3.18/edac-octeon-fix-an-uninitialized-variable-warning.patch
queue-3.18/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-3.18/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-3.18/usbip-fix-potential-format-overflow-in-userspace-tools.patch
queue-3.18/posix-timer-properly-check-sigevent-sigev_notify.patch
queue-3.18/ip6mr-fix-stale-iterator.patch
queue-3.18/arm-exynos_defconfig-enable-nfsv4-client.patch
queue-3.18/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-3.18/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
queue-3.18/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch
queue-3.18/ipv4-map-neigh-lookup-keys-in-__ipv4_neigh_lookup_noref.patch
queue-3.18/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-3.18/vhost_net-stop-device-during-reset-owner.patch
queue-3.18/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
queue-3.18/arm-exynos_defconfig-enable-options-to-mount-a-rootfs-via-nfs.patch
queue-3.18/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-3.18/usbip-vhci-hcd-add-usb3-superspeed-support.patch
queue-3.18/cifs-zero-sensitive-data-when-freeing.patch
queue-3.18/qlcnic-fix-deadlock-bug.patch
queue-3.18/dccp-cve-2017-8824-use-after-free-in-dccp-code.patch
queue-3.18/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-3.18/usbip-prevent-leaking-socket-pointer-address-in-messages.patch
queue-3.18/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
queue-3.18/mtd-nand-fix-nand_do_read_oob-return-value.patch
queue-3.18/usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
queue-3.18/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-3.18/alpha-fix-reboot-on-avanti-platform.patch
queue-3.18/usbip-stub-stop-printing-kernel-pointer-addresses-in-messages.patch
queue-3.18/usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
queue-3.18/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
queue-3.18/acpi-sbshc-remove-raw-pointer-from-printk-message.patch
queue-3.18/usb-usbip-fix-possible-deadlocks-reported-by-lockdep.patch
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3bd6f43f5cb3714f70c591514f344389df593501 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Mon, 4 Dec 2017 10:06:23 -0800
Subject: [PATCH] scsi: core: Ensure that the SCSI error handler gets woken up
If scsi_eh_scmd_add() is called concurrently with
scsi_host_queue_ready() while shost->host_blocked > 0 then it can
happen that neither function wakes up the SCSI error handler. Fix
this by making every function that decreases the host_busy counter
wake up the error handler if necessary and by protecting the
host_failed checks with the SCSI host lock.
Reported-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
References: https://marc.info/?l=linux-kernel&m=150461610630736
Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Tested-by: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Konstantin Khorenko <khorenko(a)virtuozzo.com>
Cc: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index fe3a0da3ec97..57bf43e34863 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -318,6 +318,9 @@ static void scsi_host_dev_release(struct device *dev)
scsi_proc_hostdir_rm(shost->hostt);
+ /* Wait for functions invoked through call_rcu(&shost->rcu, ...) */
+ rcu_barrier();
+
if (shost->tmf_work_q)
destroy_workqueue(shost->tmf_work_q);
if (shost->ehandler)
@@ -325,6 +328,8 @@ static void scsi_host_dev_release(struct device *dev)
if (shost->work_q)
destroy_workqueue(shost->work_q);
+ destroy_rcu_head(&shost->rcu);
+
if (shost->shost_state == SHOST_CREATED) {
/*
* Free the shost_dev device name here if scsi_host_alloc()
@@ -399,6 +404,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
INIT_LIST_HEAD(&shost->starved_list);
init_waitqueue_head(&shost->host_wait);
mutex_init(&shost->scan_mutex);
+ init_rcu_head(&shost->rcu);
index = ida_simple_get(&host_index_ida, 0, 0, GFP_KERNEL);
if (index < 0)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 62b56de38ae8..3737c6d3b064 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -220,6 +220,17 @@ static void scsi_eh_reset(struct scsi_cmnd *scmd)
}
}
+static void scsi_eh_inc_host_failed(struct rcu_head *head)
+{
+ struct Scsi_Host *shost = container_of(head, typeof(*shost), rcu);
+ unsigned long flags;
+
+ spin_lock_irqsave(shost->host_lock, flags);
+ shost->host_failed++;
+ scsi_eh_wakeup(shost);
+ spin_unlock_irqrestore(shost->host_lock, flags);
+}
+
/**
* scsi_eh_scmd_add - add scsi cmd to error handling.
* @scmd: scmd to run eh on.
@@ -242,9 +253,12 @@ void scsi_eh_scmd_add(struct scsi_cmnd *scmd)
scsi_eh_reset(scmd);
list_add_tail(&scmd->eh_entry, &shost->eh_cmd_q);
- shost->host_failed++;
- scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
+ /*
+ * Ensure that all tasks observe the host state change before the
+ * host_failed change.
+ */
+ call_rcu(&shost->rcu, scsi_eh_inc_host_failed);
}
/**
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1cbc497e00bd..1827956b33c9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -318,22 +318,39 @@ static void scsi_init_cmd_errh(struct scsi_cmnd *cmd)
cmd->cmd_len = scsi_command_size(cmd->cmnd);
}
-void scsi_device_unbusy(struct scsi_device *sdev)
+/*
+ * Decrement the host_busy counter and wake up the error handler if necessary.
+ * Avoid as follows that the error handler is not woken up if shost->host_busy
+ * == shost->host_failed: use call_rcu() in scsi_eh_scmd_add() in combination
+ * with an RCU read lock in this function to ensure that this function in its
+ * entirety either finishes before scsi_eh_scmd_add() increases the
+ * host_failed counter or that it notices the shost state change made by
+ * scsi_eh_scmd_add().
+ */
+static void scsi_dec_host_busy(struct Scsi_Host *shost)
{
- struct Scsi_Host *shost = sdev->host;
- struct scsi_target *starget = scsi_target(sdev);
unsigned long flags;
+ rcu_read_lock();
atomic_dec(&shost->host_busy);
- if (starget->can_queue > 0)
- atomic_dec(&starget->target_busy);
-
- if (unlikely(scsi_host_in_recovery(shost) &&
- (shost->host_failed || shost->host_eh_scheduled))) {
+ if (unlikely(scsi_host_in_recovery(shost))) {
spin_lock_irqsave(shost->host_lock, flags);
- scsi_eh_wakeup(shost);
+ if (shost->host_failed || shost->host_eh_scheduled)
+ scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
}
+ rcu_read_unlock();
+}
+
+void scsi_device_unbusy(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev->host;
+ struct scsi_target *starget = scsi_target(sdev);
+
+ scsi_dec_host_busy(shost);
+
+ if (starget->can_queue > 0)
+ atomic_dec(&starget->target_busy);
atomic_dec(&sdev->device_busy);
}
@@ -1532,7 +1549,7 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
list_add_tail(&sdev->starved_entry, &shost->starved_list);
spin_unlock_irq(shost->host_lock);
out_dec:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
return 0;
}
@@ -2018,7 +2035,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
return BLK_STS_OK;
out_dec_host_busy:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
out_dec_target_busy:
if (scsi_target(sdev)->can_queue > 0)
atomic_dec(&scsi_target(sdev)->target_busy);
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index a8b7bf879ced..1a1df0d21ee3 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -571,6 +571,8 @@ struct Scsi_Host {
struct blk_mq_tag_set tag_set;
};
+ struct rcu_head rcu;
+
atomic_t host_busy; /* commands actually active on low-level */
atomic_t host_blocked;
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3bd6f43f5cb3714f70c591514f344389df593501 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Mon, 4 Dec 2017 10:06:23 -0800
Subject: [PATCH] scsi: core: Ensure that the SCSI error handler gets woken up
If scsi_eh_scmd_add() is called concurrently with
scsi_host_queue_ready() while shost->host_blocked > 0 then it can
happen that neither function wakes up the SCSI error handler. Fix
this by making every function that decreases the host_busy counter
wake up the error handler if necessary and by protecting the
host_failed checks with the SCSI host lock.
Reported-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
References: https://marc.info/?l=linux-kernel&m=150461610630736
Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Tested-by: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Konstantin Khorenko <khorenko(a)virtuozzo.com>
Cc: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index fe3a0da3ec97..57bf43e34863 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -318,6 +318,9 @@ static void scsi_host_dev_release(struct device *dev)
scsi_proc_hostdir_rm(shost->hostt);
+ /* Wait for functions invoked through call_rcu(&shost->rcu, ...) */
+ rcu_barrier();
+
if (shost->tmf_work_q)
destroy_workqueue(shost->tmf_work_q);
if (shost->ehandler)
@@ -325,6 +328,8 @@ static void scsi_host_dev_release(struct device *dev)
if (shost->work_q)
destroy_workqueue(shost->work_q);
+ destroy_rcu_head(&shost->rcu);
+
if (shost->shost_state == SHOST_CREATED) {
/*
* Free the shost_dev device name here if scsi_host_alloc()
@@ -399,6 +404,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
INIT_LIST_HEAD(&shost->starved_list);
init_waitqueue_head(&shost->host_wait);
mutex_init(&shost->scan_mutex);
+ init_rcu_head(&shost->rcu);
index = ida_simple_get(&host_index_ida, 0, 0, GFP_KERNEL);
if (index < 0)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 62b56de38ae8..3737c6d3b064 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -220,6 +220,17 @@ static void scsi_eh_reset(struct scsi_cmnd *scmd)
}
}
+static void scsi_eh_inc_host_failed(struct rcu_head *head)
+{
+ struct Scsi_Host *shost = container_of(head, typeof(*shost), rcu);
+ unsigned long flags;
+
+ spin_lock_irqsave(shost->host_lock, flags);
+ shost->host_failed++;
+ scsi_eh_wakeup(shost);
+ spin_unlock_irqrestore(shost->host_lock, flags);
+}
+
/**
* scsi_eh_scmd_add - add scsi cmd to error handling.
* @scmd: scmd to run eh on.
@@ -242,9 +253,12 @@ void scsi_eh_scmd_add(struct scsi_cmnd *scmd)
scsi_eh_reset(scmd);
list_add_tail(&scmd->eh_entry, &shost->eh_cmd_q);
- shost->host_failed++;
- scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
+ /*
+ * Ensure that all tasks observe the host state change before the
+ * host_failed change.
+ */
+ call_rcu(&shost->rcu, scsi_eh_inc_host_failed);
}
/**
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1cbc497e00bd..1827956b33c9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -318,22 +318,39 @@ static void scsi_init_cmd_errh(struct scsi_cmnd *cmd)
cmd->cmd_len = scsi_command_size(cmd->cmnd);
}
-void scsi_device_unbusy(struct scsi_device *sdev)
+/*
+ * Decrement the host_busy counter and wake up the error handler if necessary.
+ * Avoid as follows that the error handler is not woken up if shost->host_busy
+ * == shost->host_failed: use call_rcu() in scsi_eh_scmd_add() in combination
+ * with an RCU read lock in this function to ensure that this function in its
+ * entirety either finishes before scsi_eh_scmd_add() increases the
+ * host_failed counter or that it notices the shost state change made by
+ * scsi_eh_scmd_add().
+ */
+static void scsi_dec_host_busy(struct Scsi_Host *shost)
{
- struct Scsi_Host *shost = sdev->host;
- struct scsi_target *starget = scsi_target(sdev);
unsigned long flags;
+ rcu_read_lock();
atomic_dec(&shost->host_busy);
- if (starget->can_queue > 0)
- atomic_dec(&starget->target_busy);
-
- if (unlikely(scsi_host_in_recovery(shost) &&
- (shost->host_failed || shost->host_eh_scheduled))) {
+ if (unlikely(scsi_host_in_recovery(shost))) {
spin_lock_irqsave(shost->host_lock, flags);
- scsi_eh_wakeup(shost);
+ if (shost->host_failed || shost->host_eh_scheduled)
+ scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
}
+ rcu_read_unlock();
+}
+
+void scsi_device_unbusy(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev->host;
+ struct scsi_target *starget = scsi_target(sdev);
+
+ scsi_dec_host_busy(shost);
+
+ if (starget->can_queue > 0)
+ atomic_dec(&starget->target_busy);
atomic_dec(&sdev->device_busy);
}
@@ -1532,7 +1549,7 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
list_add_tail(&sdev->starved_entry, &shost->starved_list);
spin_unlock_irq(shost->host_lock);
out_dec:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
return 0;
}
@@ -2018,7 +2035,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
return BLK_STS_OK;
out_dec_host_busy:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
out_dec_target_busy:
if (scsi_target(sdev)->can_queue > 0)
atomic_dec(&scsi_target(sdev)->target_busy);
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index a8b7bf879ced..1a1df0d21ee3 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -571,6 +571,8 @@ struct Scsi_Host {
struct blk_mq_tag_set tag_set;
};
+ struct rcu_head rcu;
+
atomic_t host_busy; /* commands actually active on low-level */
atomic_t host_blocked;
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3bd6f43f5cb3714f70c591514f344389df593501 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Mon, 4 Dec 2017 10:06:23 -0800
Subject: [PATCH] scsi: core: Ensure that the SCSI error handler gets woken up
If scsi_eh_scmd_add() is called concurrently with
scsi_host_queue_ready() while shost->host_blocked > 0 then it can
happen that neither function wakes up the SCSI error handler. Fix
this by making every function that decreases the host_busy counter
wake up the error handler if necessary and by protecting the
host_failed checks with the SCSI host lock.
Reported-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
References: https://marc.info/?l=linux-kernel&m=150461610630736
Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Tested-by: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Konstantin Khorenko <khorenko(a)virtuozzo.com>
Cc: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index fe3a0da3ec97..57bf43e34863 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -318,6 +318,9 @@ static void scsi_host_dev_release(struct device *dev)
scsi_proc_hostdir_rm(shost->hostt);
+ /* Wait for functions invoked through call_rcu(&shost->rcu, ...) */
+ rcu_barrier();
+
if (shost->tmf_work_q)
destroy_workqueue(shost->tmf_work_q);
if (shost->ehandler)
@@ -325,6 +328,8 @@ static void scsi_host_dev_release(struct device *dev)
if (shost->work_q)
destroy_workqueue(shost->work_q);
+ destroy_rcu_head(&shost->rcu);
+
if (shost->shost_state == SHOST_CREATED) {
/*
* Free the shost_dev device name here if scsi_host_alloc()
@@ -399,6 +404,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
INIT_LIST_HEAD(&shost->starved_list);
init_waitqueue_head(&shost->host_wait);
mutex_init(&shost->scan_mutex);
+ init_rcu_head(&shost->rcu);
index = ida_simple_get(&host_index_ida, 0, 0, GFP_KERNEL);
if (index < 0)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 62b56de38ae8..3737c6d3b064 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -220,6 +220,17 @@ static void scsi_eh_reset(struct scsi_cmnd *scmd)
}
}
+static void scsi_eh_inc_host_failed(struct rcu_head *head)
+{
+ struct Scsi_Host *shost = container_of(head, typeof(*shost), rcu);
+ unsigned long flags;
+
+ spin_lock_irqsave(shost->host_lock, flags);
+ shost->host_failed++;
+ scsi_eh_wakeup(shost);
+ spin_unlock_irqrestore(shost->host_lock, flags);
+}
+
/**
* scsi_eh_scmd_add - add scsi cmd to error handling.
* @scmd: scmd to run eh on.
@@ -242,9 +253,12 @@ void scsi_eh_scmd_add(struct scsi_cmnd *scmd)
scsi_eh_reset(scmd);
list_add_tail(&scmd->eh_entry, &shost->eh_cmd_q);
- shost->host_failed++;
- scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
+ /*
+ * Ensure that all tasks observe the host state change before the
+ * host_failed change.
+ */
+ call_rcu(&shost->rcu, scsi_eh_inc_host_failed);
}
/**
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1cbc497e00bd..1827956b33c9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -318,22 +318,39 @@ static void scsi_init_cmd_errh(struct scsi_cmnd *cmd)
cmd->cmd_len = scsi_command_size(cmd->cmnd);
}
-void scsi_device_unbusy(struct scsi_device *sdev)
+/*
+ * Decrement the host_busy counter and wake up the error handler if necessary.
+ * Avoid as follows that the error handler is not woken up if shost->host_busy
+ * == shost->host_failed: use call_rcu() in scsi_eh_scmd_add() in combination
+ * with an RCU read lock in this function to ensure that this function in its
+ * entirety either finishes before scsi_eh_scmd_add() increases the
+ * host_failed counter or that it notices the shost state change made by
+ * scsi_eh_scmd_add().
+ */
+static void scsi_dec_host_busy(struct Scsi_Host *shost)
{
- struct Scsi_Host *shost = sdev->host;
- struct scsi_target *starget = scsi_target(sdev);
unsigned long flags;
+ rcu_read_lock();
atomic_dec(&shost->host_busy);
- if (starget->can_queue > 0)
- atomic_dec(&starget->target_busy);
-
- if (unlikely(scsi_host_in_recovery(shost) &&
- (shost->host_failed || shost->host_eh_scheduled))) {
+ if (unlikely(scsi_host_in_recovery(shost))) {
spin_lock_irqsave(shost->host_lock, flags);
- scsi_eh_wakeup(shost);
+ if (shost->host_failed || shost->host_eh_scheduled)
+ scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
}
+ rcu_read_unlock();
+}
+
+void scsi_device_unbusy(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev->host;
+ struct scsi_target *starget = scsi_target(sdev);
+
+ scsi_dec_host_busy(shost);
+
+ if (starget->can_queue > 0)
+ atomic_dec(&starget->target_busy);
atomic_dec(&sdev->device_busy);
}
@@ -1532,7 +1549,7 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
list_add_tail(&sdev->starved_entry, &shost->starved_list);
spin_unlock_irq(shost->host_lock);
out_dec:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
return 0;
}
@@ -2018,7 +2035,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
return BLK_STS_OK;
out_dec_host_busy:
- atomic_dec(&shost->host_busy);
+ scsi_dec_host_busy(shost);
out_dec_target_busy:
if (scsi_target(sdev)->can_queue > 0)
atomic_dec(&scsi_target(sdev)->target_busy);
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index a8b7bf879ced..1a1df0d21ee3 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -571,6 +571,8 @@ struct Scsi_Host {
struct blk_mq_tag_set tag_set;
};
+ struct rcu_head rcu;
+
atomic_t host_busy; /* commands actually active on low-level */
atomic_t host_blocked;
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 972d0093c2f7b1bd57e47a1780a552dde528fd16 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Tue, 19 Sep 2017 12:14:18 +0300
Subject: [PATCH] ovl: force r/o mount when index dir creation fails
When work dir creation fails, a warning is emitted and overlay is
mounted r/o. Trying to remount r/w will fail with no work dir.
When index dir creation fails, the same warning is emitted and overlay
is mounted r/o, but trying to remount r/w will succeed. This may cause
unintentional corruption of filesystem consistency.
Adjust the behavior of index dir creation failure to that of work dir
creation failure and do not allow to remount r/w. User needs to state
an explicitly intention to work without an index by mounting with
option 'index=off' to allow r/w mount with no index dir.
When mounting with option 'index=on' and no 'upperdir', index is
implicitly disabled, so do not warn about no file handle support.
The issue was introduced with inodes index feature in v4.13, but this
patch will not apply cleanly before ovl_fill_super() re-factoring in
v4.15.
Fixes: 02bcd1577400 ("ovl: introduce the inodes index dir feature")
Cc: <stable(a)vger.kernel.org> #v4.13
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index f3281f0b2388..9aa5d32af427 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -699,7 +699,8 @@ static int ovl_lower_dir(const char *name, struct path *path,
* The inodes index feature needs to encode and decode file
* handles, so it requires that all layers support them.
*/
- if (ofs->config.index && !ovl_can_decode_fh(path->dentry->d_sb)) {
+ if (ofs->config.index && ofs->config.upperdir &&
+ !ovl_can_decode_fh(path->dentry->d_sb)) {
ofs->config.index = false;
pr_warn("overlayfs: fs on '%s' does not support file handles, falling back to index=off.\n", name);
}
@@ -1268,11 +1269,16 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
if (err)
goto out_free_oe;
- if (!ofs->indexdir)
+ /* Force r/o mount with no index dir */
+ if (!ofs->indexdir) {
+ dput(ofs->workdir);
+ ofs->workdir = NULL;
sb->s_flags |= SB_RDONLY;
+ }
+
}
- /* Show index=off/on in /proc/mounts for any of the reasons above */
+ /* Show index=off in /proc/mounts for forced r/o mount */
if (!ofs->indexdir)
ofs->config.index = false;
This is a conceptual cherry-pick of commit
a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream.
Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.
Signed-off-by: Clay McClure <clay(a)daemons.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
(clay: massaged to apply to 4.9.y)
Signed-off-by: Clay McClure <clay(a)daemons.net>
---
Hello,
The race fixed by this upstream patch also occurs in 4.9, 4.4, and
at least as far back as 3.14 (where we originally found it). This
massaged patch applies cleanly to 4.9.y and 4.4.y and possibly to
earlier kernels.
Thanks,
Clay
---
drivers/mtd/ubi/vmt.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/ubi/vmt.c b/drivers/mtd/ubi/vmt.c
index 7ac78c13dd1c..1bcb25bc35ef 100644
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -265,6 +265,12 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
vol->last_eb_bytes = vol->usable_leb_size;
}
+ /* Make volume "available" before it becomes accessible via sysfs */
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = vol;
+ ubi->vol_count += 1;
+ spin_unlock(&ubi->volumes_lock);
+
/* Register character device for the volume */
cdev_init(&vol->cdev, &ubi_vol_cdev_operations);
vol->cdev.owner = THIS_MODULE;
@@ -304,11 +310,6 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
if (err)
goto out_sysfs;
- spin_lock(&ubi->volumes_lock);
- ubi->volumes[vol_id] = vol;
- ubi->vol_count += 1;
- spin_unlock(&ubi->volumes_lock);
-
ubi_volume_notify(ubi, vol, UBI_VOLUME_ADDED);
self_check_volumes(ubi);
return err;
@@ -328,6 +329,10 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
out_cdev:
cdev_del(&vol->cdev);
out_mapping:
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = NULL;
+ ubi->vol_count -= 1;
+ spin_unlock(&ubi->volumes_lock);
if (do_free)
ubi_eba_destroy_table(eba_tbl);
out_acc:
--
2.7.4
Stable team, please backport
commit 7c2e017e32e1bc12e56760458568a166e1f13353
Author: Imre Deak <imre.deak(a)intel.com>
Date: Wed Nov 29 19:51:37 2017 +0200
drm/i915: Avoid PPS HW/SW state mismatch due to rounding
to stable trees starting from v4.9 (it applies cleanly) to fix
https://bugs.freedesktop.org/show_bug.cgi?id=104704
Thanks,
Imre
This is a note to let you know that I've just added the patch titled
btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 5 Dec 2017 09:29:19 +0200
Subject: btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker
From: Nikolay Borisov <nborisov(a)suse.com>
commit f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb upstream.
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2063,8 +2063,15 @@ again:
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
out:
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.9/btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
This is a note to let you know that I've just added the patch titled
btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 5 Dec 2017 09:29:19 +0200
Subject: btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker
From: Nikolay Borisov <nborisov(a)suse.com>
commit f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb upstream.
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2015,7 +2015,15 @@ again:
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, &cached_state);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end,
+ &cached_state);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
out:
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.4/btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
This is a note to let you know that I've just added the patch titled
btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 5 Dec 2017 09:29:19 +0200
Subject: btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker
From: Nikolay Borisov <nborisov(a)suse.com>
commit f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb upstream.
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2101,8 +2101,15 @@ again:
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
out:
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-handle-btrfs_set_extent_delalloc-failure-in-fixup-worker.patch
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
---
Here is the 4.4 backport for upstream commit
f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb
fs/btrfs/inode.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index af1da85da509..86d209fc4992 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2015,7 +2015,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, &cached_state);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end,
+ &cached_state);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
out:
--
2.7.4
This is a note to let you know that I've just added the patch titled
lib/ubsan.c: s/missaligned/misaligned/
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
lib-ubsan.c-s-missaligned-misaligned.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b8fe1120b4ba342b4f156d24e952d6e686b20298 Mon Sep 17 00:00:00 2001
From: Andrew Morton <akpm(a)linux-foundation.org>
Date: Tue, 6 Feb 2018 15:40:38 -0800
Subject: lib/ubsan.c: s/missaligned/misaligned/
From: Andrew Morton <akpm(a)linux-foundation.org>
commit b8fe1120b4ba342b4f156d24e952d6e686b20298 upstream.
A vist from the spelling fairy.
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/ubsan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -281,7 +281,7 @@ static void handle_null_ptr_deref(struct
ubsan_epilogue(&flags);
}
-static void handle_missaligned_access(struct type_mismatch_data *data,
+static void handle_misaligned_access(struct type_mismatch_data *data,
unsigned long ptr)
{
unsigned long flags;
@@ -322,7 +322,7 @@ void __ubsan_handle_type_mismatch(struct
if (!ptr)
handle_null_ptr_deref(data);
else if (data->alignment && !IS_ALIGNED(ptr, data->alignment))
- handle_missaligned_access(data, ptr);
+ handle_misaligned_access(data, ptr);
else
handle_object_size_mismatch(data, ptr);
}
Patches currently in stable-queue which might be from akpm(a)linux-foundation.org are
queue-4.9/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
queue-4.9/lib-ubsan-add-type-mismatch-handler-for-new-gcc-clang.patch
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/lib-ubsan.c-s-missaligned-misaligned.patch
queue-4.9/nsfs-mark-dentry-with-dcache_rcuaccess.patch
queue-4.9/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.9/fs-proc-kcore.c-use-probe_kernel_read-instead-of-memcpy.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
queue-4.9/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
This is a note to let you know that I've just added the patch titled
lib/ubsan.c: s/missaligned/misaligned/
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
lib-ubsan.c-s-missaligned-misaligned.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b8fe1120b4ba342b4f156d24e952d6e686b20298 Mon Sep 17 00:00:00 2001
From: Andrew Morton <akpm(a)linux-foundation.org>
Date: Tue, 6 Feb 2018 15:40:38 -0800
Subject: lib/ubsan.c: s/missaligned/misaligned/
From: Andrew Morton <akpm(a)linux-foundation.org>
commit b8fe1120b4ba342b4f156d24e952d6e686b20298 upstream.
A vist from the spelling fairy.
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/ubsan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -281,7 +281,7 @@ static void handle_null_ptr_deref(struct
ubsan_epilogue(&flags);
}
-static void handle_missaligned_access(struct type_mismatch_data *data,
+static void handle_misaligned_access(struct type_mismatch_data *data,
unsigned long ptr)
{
unsigned long flags;
@@ -322,7 +322,7 @@ void __ubsan_handle_type_mismatch(struct
if (!ptr)
handle_null_ptr_deref(data);
else if (data->alignment && !IS_ALIGNED(ptr, data->alignment))
- handle_missaligned_access(data, ptr);
+ handle_misaligned_access(data, ptr);
else
handle_object_size_mismatch(data, ptr);
}
Patches currently in stable-queue which might be from akpm(a)linux-foundation.org are
queue-4.15/kasan-rework-kconfig-settings.patch
queue-4.15/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
queue-4.15/lib-ubsan-add-type-mismatch-handler-for-new-gcc-clang.patch
queue-4.15/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.15/lib-ubsan.c-s-missaligned-misaligned.patch
queue-4.15/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.15/kasan-don-t-emit-builtin-calls-when-sanitization-is-off.patch
queue-4.15/fs-proc-kcore.c-use-probe_kernel_read-instead-of-memcpy.patch
queue-4.15/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.15/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
queue-4.15/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
This is a note to let you know that I've just added the patch titled
lib/ubsan.c: s/missaligned/misaligned/
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
lib-ubsan.c-s-missaligned-misaligned.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b8fe1120b4ba342b4f156d24e952d6e686b20298 Mon Sep 17 00:00:00 2001
From: Andrew Morton <akpm(a)linux-foundation.org>
Date: Tue, 6 Feb 2018 15:40:38 -0800
Subject: lib/ubsan.c: s/missaligned/misaligned/
From: Andrew Morton <akpm(a)linux-foundation.org>
commit b8fe1120b4ba342b4f156d24e952d6e686b20298 upstream.
A vist from the spelling fairy.
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/ubsan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -281,7 +281,7 @@ static void handle_null_ptr_deref(struct
ubsan_epilogue(&flags);
}
-static void handle_missaligned_access(struct type_mismatch_data *data,
+static void handle_misaligned_access(struct type_mismatch_data *data,
unsigned long ptr)
{
unsigned long flags;
@@ -322,7 +322,7 @@ void __ubsan_handle_type_mismatch(struct
if (!ptr)
handle_null_ptr_deref(data);
else if (data->alignment && !IS_ALIGNED(ptr, data->alignment))
- handle_missaligned_access(data, ptr);
+ handle_misaligned_access(data, ptr);
else
handle_object_size_mismatch(data, ptr);
}
Patches currently in stable-queue which might be from akpm(a)linux-foundation.org are
queue-4.14/kasan-rework-kconfig-settings.patch
queue-4.14/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
queue-4.14/lib-ubsan-add-type-mismatch-handler-for-new-gcc-clang.patch
queue-4.14/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.14/lib-ubsan.c-s-missaligned-misaligned.patch
queue-4.14/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.14/kasan-don-t-emit-builtin-calls-when-sanitization-is-off.patch
queue-4.14/fs-proc-kcore.c-use-probe_kernel_read-instead-of-memcpy.patch
queue-4.14/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.14/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
queue-4.14/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Cc: stable(a)vger.kernel.org
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
---
Here is the 4.14 backport of upstream commit
f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb
fs/btrfs/inode.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index c71afd424900..5eaedff28a32 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2101,8 +2101,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
out:
--
2.7.4
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Cc: stable(a)vger.kernel.org
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
---
Here is the 4.9 backport of upstream commit
f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb
fs/btrfs/inode.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 894d56361ea9..a8a1fb40e258 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2063,8 +2063,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
out:
--
2.7.4
This is a note to let you know that I've just added the patch titled
xtensa: fix futex_atomic_cmpxchg_inatomic
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ca47480921587ae30417dd234a9f79af188e3666 Mon Sep 17 00:00:00 2001
From: Max Filippov <jcmvbkbc(a)gmail.com>
Date: Fri, 5 Jan 2018 14:27:58 -0800
Subject: xtensa: fix futex_atomic_cmpxchg_inatomic
From: Max Filippov <jcmvbkbc(a)gmail.com>
commit ca47480921587ae30417dd234a9f79af188e3666 upstream.
Return 0 if the operation was successful, not the userspace memory
value. Check that userspace value equals passed oldval, not itself.
Don't update *uval if the value wasn't read from userspace memory.
This fixes process hang due to infinite loop in futex_lock_pi.
It also fixes a bunch of glibc tests nptl/tst-mutexpi*.
Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/xtensa/include/asm/futex.h | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
--- a/arch/xtensa/include/asm/futex.h
+++ b/arch/xtensa/include/asm/futex.h
@@ -109,7 +109,6 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
u32 oldval, u32 newval)
{
int ret = 0;
- u32 prev;
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
@@ -120,26 +119,24 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
__asm__ __volatile__ (
" # futex_atomic_cmpxchg_inatomic\n"
- "1: l32i %1, %3, 0\n"
- " mov %0, %5\n"
- " wsr %1, scompare1\n"
- "2: s32c1i %0, %3, 0\n"
- "3:\n"
+ " wsr %5, scompare1\n"
+ "1: s32c1i %1, %4, 0\n"
+ " s32i %1, %6, 0\n"
+ "2:\n"
" .section .fixup,\"ax\"\n"
" .align 4\n"
- "4: .long 3b\n"
- "5: l32r %1, 4b\n"
- " movi %0, %6\n"
+ "3: .long 2b\n"
+ "4: l32r %1, 3b\n"
+ " movi %0, %7\n"
" jx %1\n"
" .previous\n"
" .section __ex_table,\"a\"\n"
- " .long 1b,5b,2b,5b\n"
+ " .long 1b,4b\n"
" .previous\n"
- : "+r" (ret), "=&r" (prev), "+m" (*uaddr)
- : "r" (uaddr), "r" (oldval), "r" (newval), "I" (-EFAULT)
+ : "+r" (ret), "+r" (newval), "+m" (*uaddr), "+m" (*uval)
+ : "r" (uaddr), "r" (oldval), "r" (uval), "I" (-EFAULT)
: "memory");
- *uval = prev;
return ret;
}
Patches currently in stable-queue which might be from jcmvbkbc(a)gmail.com are
queue-4.9/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
This is a note to let you know that I've just added the patch titled
signal/sh: Ensure si_signo is initialized in do_divide_error
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Mon, 24 Jul 2017 17:30:30 -0500
Subject: signal/sh: Ensure si_signo is initialized in do_divide_error
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream.
Set si_signo.
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Rich Felker <dalias(a)libc.org>
Cc: Paul Mundt <lethal(a)linux-sh.org>
Cc: linux-sh(a)vger.kernel.org
Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.")
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/kernel/traps_32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/sh/kernel/traps_32.c
+++ b/arch/sh/kernel/traps_32.c
@@ -607,7 +607,8 @@ asmlinkage void do_divide_error(unsigned
break;
}
- force_sig_info(SIGFPE, &info, current);
+ info.si_signo = SIGFPE;
+ force_sig_info(info.si_signo, &info, current);
}
#endif
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.9/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.9/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
watchdog: imx2_wdt: restore previous timeout after suspend+resume
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0be267255cef64e1c58475baa7b25568355a3816 Mon Sep 17 00:00:00 2001
From: Martin Kaiser <martin(a)kaiser.cx>
Date: Mon, 1 Jan 2018 18:26:47 +0100
Subject: watchdog: imx2_wdt: restore previous timeout after suspend+resume
From: Martin Kaiser <martin(a)kaiser.cx>
commit 0be267255cef64e1c58475baa7b25568355a3816 upstream.
When the watchdog device is suspended, its timeout is set to the maximum
value. During resume, the previously set timeout should be restored.
This does not work at the moment.
The suspend function calls
imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
and resume reverts this by calling
imx2_wdt_set_timeout(wdog, wdog->timeout);
However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore,
wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume
function.
Fix this by adding a new function __imx2_wdt_set_timeout() which
only updates the hardware settings. imx2_wdt_set_timeout() now calls
__imx2_wdt_set_timeout() and then saves the new timeout to
wdog->timeout.
During suspend, we call __imx2_wdt_set_timeout() directly so that
wdog->timeout won't be updated and we can restore the previous value
during resume. This approach makes wdog->timeout different from the
actual setting in the hardware which is usually not a good thing.
However, the two differ only while we're suspended and no kernel code is
running, so it should be ok in this case.
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/watchdog/imx2_wdt.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -169,15 +169,21 @@ static int imx2_wdt_ping(struct watchdog
return 0;
}
-static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
- unsigned int new_timeout)
+static void __imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
{
struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
- wdog->timeout = new_timeout;
-
regmap_update_bits(wdev->regmap, IMX2_WDT_WCR, IMX2_WDT_WCR_WT,
WDOG_SEC_TO_COUNT(new_timeout));
+}
+
+static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ __imx2_wdt_set_timeout(wdog, new_timeout);
+
+ wdog->timeout = new_timeout;
return 0;
}
@@ -371,7 +377,11 @@ static int imx2_wdt_suspend(struct devic
/* The watchdog IP block is running */
if (imx2_wdt_is_running(wdev)) {
- imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
+ /*
+ * Don't update wdog->timeout, we'll restore the current value
+ * during resume.
+ */
+ __imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
imx2_wdt_ping(wdog);
}
Patches currently in stable-queue which might be from martin(a)kaiser.cx are
queue-4.9/watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7d06d5895c159f64c46560dc258e553ad8670fe0 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Wed, 20 Dec 2017 19:00:07 +0800
Subject: Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 7d06d5895c159f64c46560dc258e553ad8670fe0 upstream.
This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56.
This commit causes a regression on some QCA ROME chips. The USB device
reset happens in btusb_open(), hence firmware loading gets interrupted.
Furthermore, this commit stops working after commit
("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to
enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in
btusb_suspend() when it's not a wakeup source.
If we really want to reset the USB device, we need to do it before
btusb_open(). Let's handle it in drivers/usb/core/quirks.c.
Cc: Leif Liddy <leif.linux(a)gmail.com>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Daniel Drake <drake(a)endlessm.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Reviewed-by: Brian Norris <briannorris(a)chromium.org>
Tested-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 6 ------
1 file changed, 6 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2925,12 +2925,6 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
-
- /* QCA Rome devices lose their updated firmware over suspend,
- * but the USB hub doesn't notice any status change.
- * Explicitly request a device reset on resume.
- */
- set_bit(BTUSB_RESET_RESUME, &data->flags);
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.9/revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
queue-4.9/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
signal/openrisc: Fix do_unaligned_access to send the proper signal
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 500d58300571b6602341b041f97c082a461ef994 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 04:16:47 -0500
Subject: signal/openrisc: Fix do_unaligned_access to send the proper signal
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 500d58300571b6602341b041f97c082a461ef994 upstream.
While reviewing the signal sending on openrisc the do_unaligned_access
function stood out because it is obviously wrong. A comment about an
si_code set above when actually si_code is never set. Leading to a
random si_code being sent to userspace in the event of an unaligned
access.
Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
si_code to send for an unaligned access. That is what other
architectures do and what is required by posix.
Given that do_unaligned_access is broken in a way that no one can be
relying on it on openrisc fix the code to just do the right thing.
Fixes: 769a8a96229e ("OpenRISC: Traps")
Cc: Jonas Bonn <jonas(a)southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi>
Cc: Stafford Horne <shorne(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: openrisc(a)lists.librecores.org
Acked-by: Stafford Horne <shorne(a)gmail.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/openrisc/kernel/traps.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -302,12 +302,12 @@ asmlinkage void do_unaligned_access(stru
siginfo_t info;
if (user_mode(regs)) {
- /* Send a SIGSEGV */
- info.si_signo = SIGSEGV;
+ /* Send a SIGBUS */
+ info.si_signo = SIGBUS;
info.si_errno = 0;
- /* info.si_code has been set above */
- info.si_addr = (void *)address;
- force_sig_info(SIGSEGV, &info, current);
+ info.si_code = BUS_ADRALN;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGBUS, &info, current);
} else {
printk("KERNEL: Unaligned Access 0x%.8lx\n", address);
show_registers(regs);
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.9/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.9/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
pktcdvd: Fix pkt_setup_dev() error path
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pktcdvd-fix-pkt_setup_dev-error-path.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 2 Jan 2018 11:39:47 -0800
Subject: pktcdvd: Fix pkt_setup_dev() error path
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.
Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
modified add_disk() and disk_release() but did not update any of the
error paths that trigger a put_disk() call after disk->queue has been
assigned. That introduced the following behavior in the pktcdvd driver
if pkt_new_dev() fails:
Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]
Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
error path.
Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/pktcdvd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2779,7 +2779,7 @@ static int pkt_setup_dev(dev_t dev, dev_
pd->pkt_dev = MKDEV(pktdev_major, idx);
ret = pkt_new_dev(pd, dev);
if (ret)
- goto out_new_dev;
+ goto out_mem2;
/* inherit events of the host device */
disk->events = pd->bdev->bd_disk->events;
@@ -2797,8 +2797,6 @@ static int pkt_setup_dev(dev_t dev, dev_
mutex_unlock(&ctl_mutex);
return 0;
-out_new_dev:
- blk_cleanup_queue(disk->queue);
out_mem2:
put_disk(disk);
out_mem:
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.9/pktcdvd-fix-pkt_setup_dev-error-path.patch
This is a note to let you know that I've just added the patch titled
pipe: actually allow root to exceed the pipe buffer limits
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 85c2dd5473b2718b4b63e74bfeb1ca876868e11f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 6 Feb 2018 15:41:53 -0800
Subject: pipe: actually allow root to exceed the pipe buffer limits
From: Eric Biggers <ebiggers(a)google.com>
commit 85c2dd5473b2718b4b63e74bfeb1ca876868e11f upstream.
pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
to unprivileged users, as documented in both Documentation/sysctl/fs.txt
and the pipe(7) man page.
However, the capabilities are actually only checked when increasing a
pipe's size using F_SETPIPE_SZ, not when creating a new pipe. Therefore,
if pipe-user-pages-hard has been set, the root user can run into it and be
unable to create pipes. Similarly, if pipe-user-pages-soft has been set,
the root user can run into it and have their pipes limited to 1 page each.
Fix this by allowing the privileged override in both cases.
Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com
Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org>
Cc: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/pipe.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -617,6 +617,11 @@ static bool too_many_pipe_buffers_hard(u
return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
}
+static bool is_unprivileged_user(void)
+{
+ return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN);
+}
+
struct pipe_inode_info *alloc_pipe_info(void)
{
struct pipe_inode_info *pipe;
@@ -633,12 +638,12 @@ struct pipe_inode_info *alloc_pipe_info(
user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
- if (too_many_pipe_buffers_soft(user_bufs)) {
+ if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) {
user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
pipe_bufs = 1;
}
- if (too_many_pipe_buffers_hard(user_bufs))
+ if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user())
goto out_revert_acct;
pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
@@ -1069,7 +1074,7 @@ static long pipe_set_size(struct pipe_in
if (nr_pages > pipe->buffers &&
(too_many_pipe_buffers_hard(user_bufs) ||
too_many_pipe_buffers_soft(user_bufs)) &&
- !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
+ is_unprivileged_user()) {
ret = -EPERM;
goto out_revert_acct;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
pipe: fix off-by-one error when checking buffer limits
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9903a91c763ecdae333a04a9d89d79d2b8966503 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 6 Feb 2018 15:41:56 -0800
Subject: pipe: fix off-by-one error when checking buffer limits
From: Eric Biggers <ebiggers(a)google.com>
commit 9903a91c763ecdae333a04a9d89d79d2b8966503 upstream.
With pipe-user-pages-hard set to 'N', users were actually only allowed up
to 'N - 1' buffers; and likewise for pipe-user-pages-soft.
Fix this to allow up to 'N' buffers, as would be expected.
Link: http://lkml.kernel.org/r/20180111052902.14409-5-ebiggers3@gmail.com
Fixes: b0b91d18e2e9 ("pipe: fix limit checking in pipe_set_size()")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Acked-by: Willy Tarreau <w(a)1wt.eu>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org>
Cc: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/pipe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -609,12 +609,12 @@ static unsigned long account_pipe_buffer
static bool too_many_pipe_buffers_soft(unsigned long user_bufs)
{
- return pipe_user_pages_soft && user_bufs >= pipe_user_pages_soft;
+ return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft;
}
static bool too_many_pipe_buffers_hard(unsigned long user_bufs)
{
- return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
+ return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard;
}
static bool is_unprivileged_user(void)
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
pinctrl: intel: Initialize GPIO properly when used through irqchip
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Wed, 29 Nov 2017 16:25:44 +0300
Subject: pinctrl: intel: Initialize GPIO properly when used through irqchip
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 upstream.
When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
switches the pin to GPIO mode and makes sure interrupts are routed to
the GPIO hardware instead of IOAPIC. However, if the GPIO is used
directly through irqchip, as is the case with many I2C-HID devices where
I2C core automatically configures interrupt for the device, the pin is
not initialized as GPIO. Instead we rely that the BIOS configures the
pin accordingly which seems not to be the case at least in Asus X540NA
SKU3 with Focaltech touchpad.
When the pin is not properly configured it might result weird behaviour
like interrupts suddenly stop firing completely and the touchpad stops
responding to user input.
Fix this by properly initializing the pin to GPIO mode also when it is
used directly through irqchip.
Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
Reported-by: Daniel Drake <drake(a)endlessm.com>
Reported-and-tested-by: Chris Chiu <chiu(a)endlessm.com>
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/intel/pinctrl-intel.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -368,6 +368,18 @@ static void __intel_gpio_set_direction(v
writel(value, padcfg0);
}
+static void intel_gpio_set_gpio_mode(void __iomem *padcfg0)
+{
+ u32 value;
+
+ /* Put the pad into GPIO mode */
+ value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
+ /* Disable SCI/SMI/NMI generation */
+ value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
+ value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
+ writel(value, padcfg0);
+}
+
static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin)
@@ -375,7 +387,6 @@ static int intel_gpio_request_enable(str
struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
void __iomem *padcfg0;
unsigned long flags;
- u32 value;
raw_spin_lock_irqsave(&pctrl->lock, flags);
@@ -385,13 +396,7 @@ static int intel_gpio_request_enable(str
}
padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
- /* Put the pad into GPIO mode */
- value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
- /* Disable SCI/SMI/NMI generation */
- value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
- value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
- writel(value, padcfg0);
-
+ intel_gpio_set_gpio_mode(padcfg0);
/* Disable TX buffer and enable RX (this will be input) */
__intel_gpio_set_direction(padcfg0, true);
@@ -770,6 +775,8 @@ static int intel_gpio_irq_type(struct ir
raw_spin_lock_irqsave(&pctrl->lock, flags);
+ intel_gpio_set_gpio_mode(reg);
+
value = readl(reg);
value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);
Patches currently in stable-queue which might be from mika.westerberg(a)linux.intel.com are
queue-4.9/pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch
queue-4.9/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
This is a note to let you know that I've just added the patch titled
media: ts2020: avoid integer overflows on 32 bit machines
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Date: Wed, 10 Jan 2018 07:20:39 -0500
Subject: media: ts2020: avoid integer overflows on 32 bit machines
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
commit 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 upstream.
Before this patch, when compiled for arm32, the signal strength
were reported as:
Lock (0x1f) Signal= 4294908.66dBm C/N= 12.79dB
Because of a 32 bit integer overflow. After it, it is properly
reported as:
Lock (0x1f) Signal= -58.64dBm C/N= 12.79dB
Fixes: 0f91c9d6bab9 ("[media] TS2020: Calculate tuner gain correctly")
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/dvb-frontends/ts2020.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -369,7 +369,7 @@ static int ts2020_read_tuner_gain(struct
gain2 = clamp_t(long, gain2, 0, 13);
v_agc = clamp_t(long, v_agc, 400, 1100);
- *_gain = -(gain1 * 2330 +
+ *_gain = -((__s64)gain1 * 2330 +
gain2 * 3500 +
v_agc * 24 / 10 * 10 +
10000);
@@ -387,7 +387,7 @@ static int ts2020_read_tuner_gain(struct
gain3 = clamp_t(long, gain3, 0, 6);
v_agc = clamp_t(long, v_agc, 600, 1600);
- *_gain = -(gain1 * 2650 +
+ *_gain = -((__s64)gain1 * 2650 +
gain2 * 3380 +
gain3 * 2850 +
v_agc * 176 / 100 * 10 -
Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are
queue-4.9/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.9/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.9/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.9/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.9/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch
queue-4.9/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.9/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.9/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.9/media-dvb-frontends-fix-i2c-access-helpers-for-kasan.patch
queue-4.9/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch
queue-4.9/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.9/media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
queue-4.9/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.9/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.9/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.9/media-v4l2-compat-ioctl32-copy-v4l2_window-global_alpha.patch
queue-4.9/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.9/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9893b905e743ded332575ca04486bd586c0772f7 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Date: Wed, 24 Jan 2018 06:01:57 -0500
Subject: media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.
The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.
That prevents filling the dmesg with lots of messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
Reported-by: Enrico Mioso <mrkiko.rs(a)gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/dvb-usb/cxusb.c | 2 ++
drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
2 files changed, 3 insertions(+)
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -820,6 +820,8 @@ static int dvico_bluebird_xc2028_callbac
case XC2028_RESET_CLK:
deb_info("%s: XC2028_RESET_CLK %d\n", __func__, arg);
break;
+ case XC2028_I2C_FLUSH:
+ break;
default:
deb_info("%s: unknown command %d, arg %d\n", __func__,
command, arg);
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -431,6 +431,7 @@ static int stk7700ph_xc3028_callback(voi
state->dib7000p_ops.set_gpio(adap->fe_adap[0].fe, 8, 0, 1);
break;
case XC2028_RESET_CLK:
+ case XC2028_I2C_FLUSH:
break;
default:
err("%s: unknown command %d, arg %d\n", __func__,
Patches currently in stable-queue which might be from mchehab(a)osg.samsung.com are
queue-4.9/media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6b6977117f50d60455ace86b2d256f6fb4f3de05 Mon Sep 17 00:00:00 2001
From: Liran Alon <liran.alon(a)oracle.com>
Date: Thu, 9 Nov 2017 20:27:20 +0200
Subject: KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Liran Alon <liran.alon(a)oracle.com>
commit 6b6977117f50d60455ace86b2d256f6fb4f3de05 upstream.
Consider the following scenario:
1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
to CPU B via virtual posted-interrupt mechanism.
2. CPU B is currently executing L2 guest.
3. vmx_deliver_nested_posted_interrupt() calls
kvm_vcpu_trigger_posted_interrupt() which will note that
vcpu->mode == IN_GUEST_MODE.
4. Assume that before CPU A sends the physical POSTED_INTR_NESTED_VECTOR
IPI, CPU B exits from L2 to L0 during event-delivery
(valid IDT-vectoring-info).
5. CPU A now sends the physical IPI. The IPI is received in host and
it's handler (smp_kvm_posted_intr_nested_ipi()) does nothing.
6. Assume that before CPU A sets pi_pending=true and KVM_REQ_EVENT,
CPU B continues to run in L0 and reach vcpu_enter_guest(). As
KVM_REQ_EVENT is not set yet, vcpu_enter_guest() will continue and resume
L2 guest.
7. At this point, CPU A sets pi_pending=true and KVM_REQ_EVENT but
it's too late! CPU B already entered L2 and KVM_REQ_EVENT will only be
consumed at next L2 entry!
Another scenario to consider:
1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
to CPU B via virtual posted-interrupt mechanism.
2. Assume that before CPU A calls kvm_vcpu_trigger_posted_interrupt(),
CPU B is at L0 and is about to resume into L2. Further assume that it is
in vcpu_enter_guest() after check for KVM_REQ_EVENT.
3. At this point, CPU A calls kvm_vcpu_trigger_posted_interrupt() which
will note that vcpu->mode != IN_GUEST_MODE. Therefore, do nothing and
return false. Then, will set pi_pending=true and KVM_REQ_EVENT.
4. Now CPU B continue and resumes into L2 guest without processing
the posted-interrupt until next L2 entry!
To fix both issues, we just need to change
vmx_deliver_nested_posted_interrupt() to set pi_pending=true and
KVM_REQ_EVENT before calling kvm_vcpu_trigger_posted_interrupt().
It will fix the first scenario by chaging step (6) to note that
KVM_REQ_EVENT and pi_pending=true and therefore process
nested posted-interrupt.
It will fix the second scenario by two possible ways:
1. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B has changed
vcpu->mode to IN_GUEST_MODE, physical IPI will be sent and will be received
when CPU resumes into L2.
2. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B hasn't yet
changed vcpu->mode to IN_GUEST_MODE, then after CPU B will change
vcpu->mode it will call kvm_request_pending() which will return true and
therefore force another round of vcpu_enter_guest() which will note that
KVM_REQ_EVENT and pi_pending=true and therefore process nested
posted-interrupt.
Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing")
Signed-off-by: Liran Alon <liran.alon(a)oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com>
[Add kvm_vcpu_kick to also handle the case where L1 doesn't intercept L2 HLT
and L2 executes HLT instruction. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4967,14 +4967,15 @@ static int vmx_deliver_nested_posted_int
if (is_guest_mode(vcpu) &&
vector == vmx->nested.posted_intr_nv) {
- /* the PIR and ON have been set by L1. */
- kvm_vcpu_trigger_posted_interrupt(vcpu);
/*
* If a posted intr is not recognized by hardware,
* we will accomplish it in the next vmentry.
*/
vmx->nested.pi_pending = true;
kvm_make_request(KVM_REQ_EVENT, vcpu);
+ /* the PIR and ON have been set by L1. */
+ if (!kvm_vcpu_trigger_posted_interrupt(vcpu))
+ kvm_vcpu_kick(vcpu);
return 0;
}
return -1;
Patches currently in stable-queue which might be from liran.alon(a)oracle.com are
queue-4.9/kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch
This is a note to let you know that I've just added the patch titled
kernel/relay.c: revert "kernel/relay.c: fix potential memory leak"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a1be1f3931bfe0a42b46fef77a04593c2b136e7f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 6 Feb 2018 15:40:24 -0800
Subject: kernel/relay.c: revert "kernel/relay.c: fix potential memory leak"
From: Eric Biggers <ebiggers(a)google.com>
commit a1be1f3931bfe0a42b46fef77a04593c2b136e7f upstream.
This reverts commit ba62bafe942b ("kernel/relay.c: fix potential memory leak").
This commit introduced a double free bug, because 'chan' is already
freed by the line:
kref_put(&chan->kref, relay_destroy_channel);
This bug was found by syzkaller, using the BLKTRACESETUP ioctl.
Link: http://lkml.kernel.org/r/20180127004759.101823-1-ebiggers3@gmail.com
Fixes: ba62bafe942b ("kernel/relay.c: fix potential memory leak")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Zhouyi Zhou <yizhouzhou(a)ict.ac.cn>
Cc: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/relay.c | 1 -
1 file changed, 1 deletion(-)
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -611,7 +611,6 @@ free_bufs:
kref_put(&chan->kref, relay_destroy_channel);
mutex_unlock(&relay_channels_mutex);
- kfree(chan);
return NULL;
}
EXPORT_SYMBOL_GPL(relay_open);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: Handle CPU_PM_ENTER_FAILED
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-arm-arm64-handle-cpu_pm_enter_failed.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58d6b15e9da5042a99c9c30ad725792e4569150e Mon Sep 17 00:00:00 2001
From: James Morse <james.morse(a)arm.com>
Date: Mon, 22 Jan 2018 18:19:06 +0000
Subject: KVM: arm/arm64: Handle CPU_PM_ENTER_FAILED
From: James Morse <james.morse(a)arm.com>
commit 58d6b15e9da5042a99c9c30ad725792e4569150e upstream.
cpu_pm_enter() calls the pm notifier chain with CPU_PM_ENTER, then if
there is a failure: CPU_PM_ENTER_FAILED.
When KVM receives CPU_PM_ENTER it calls cpu_hyp_reset() which will
return us to the hyp-stub. If we subsequently get a CPU_PM_ENTER_FAILED,
KVM does nothing, leaving the CPU running with the hyp-stub, at odds
with kvm_arm_hardware_enabled.
Add CPU_PM_ENTER_FAILED as a fallthrough for CPU_PM_EXIT, this reloads
KVM based on kvm_arm_hardware_enabled. This is safe even if CPU_PM_ENTER
never gets as far as KVM, as cpu_hyp_reinit() calls cpu_hyp_reset()
to make sure the hyp-stub is loaded before reloading KVM.
Fixes: 67f691976662 ("arm64: kvm: allows kvm cpu hotplug")
CC: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: James Morse <james.morse(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kvm/arm.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1165,6 +1165,7 @@ static int hyp_init_cpu_pm_notifier(stru
cpu_hyp_reset();
return NOTIFY_OK;
+ case CPU_PM_ENTER_FAILED:
case CPU_PM_EXIT:
if (__this_cpu_read(kvm_arm_hardware_enabled))
/* The hardware was enabled before suspend. */
Patches currently in stable-queue which might be from james.morse(a)arm.com are
queue-4.9/kvm-arm-arm64-handle-cpu_pm_enter_failed.patch
This is a note to let you know that I've just added the patch titled
kernel/async.c: revert "async: simplify lowest_in_progress()"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kernel-async.c-revert-async-simplify-lowest_in_progress.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4f7e988e63e336827f4150de48163bed05d653bd Mon Sep 17 00:00:00 2001
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Date: Tue, 6 Feb 2018 15:37:55 -0800
Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
commit 4f7e988e63e336827f4150de48163bed05d653bd upstream.
This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()")
which was simply wrong: In the case where domain is NULL, we now use the
wrong offsetof() in the list_first_entry macro, so we don't actually
fetch the ->cookie value, but rather the eight bytes located
sizeof(struct list_head) further into the struct async_entry.
On 64 bit, that's the data member, while on 32 bit, that's a u64 built
from func and data in some order.
I think the bug happens to be harmless in practice: It obviously only
affects callers which pass a NULL domain, and AFAICT the only such
caller is
async_synchronize_full() ->
async_synchronize_full_domain(NULL) ->
async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
the async_global_pending list to be empty - but it would break if
somebody happened to pass (void*)-1 as the data element to
async_schedule, and of course also if somebody ever does a
async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
Maybe the "harmless in practice" means this isn't -stable material. But
I'm not completely confident my quick git grep'ing is enough, and there
might be affected code in one of the earlier kernels that has since been
removed, so I'll leave the decision to the stable guys.
Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk
Fixes: 92266d6ef60c "async: simplify lowest_in_progress()"
Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Acked-by: Tejun Heo <tj(a)kernel.org>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: Adam Wallis <awallis(a)codeaurora.org>
Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/async.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -84,20 +84,24 @@ static atomic_t entry_count;
static async_cookie_t lowest_in_progress(struct async_domain *domain)
{
- struct list_head *pending;
+ struct async_entry *first = NULL;
async_cookie_t ret = ASYNC_COOKIE_MAX;
unsigned long flags;
spin_lock_irqsave(&async_lock, flags);
- if (domain)
- pending = &domain->pending;
- else
- pending = &async_global_pending;
+ if (domain) {
+ if (!list_empty(&domain->pending))
+ first = list_first_entry(&domain->pending,
+ struct async_entry, domain_list);
+ } else {
+ if (!list_empty(&async_global_pending))
+ first = list_first_entry(&async_global_pending,
+ struct async_entry, global_list);
+ }
- if (!list_empty(pending))
- ret = list_first_entry(pending, struct async_entry,
- domain_list)->cookie;
+ if (first)
+ ret = first->cookie;
spin_unlock_irqrestore(&async_lock, flags);
return ret;
Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are
queue-4.9/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
This is a note to let you know that I've just added the patch titled
HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From edfc3722cfef4217c7fe92b272cbe0288ba1ff57 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 17 Jan 2018 21:05:55 +0100
Subject: HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working
From: Hans de Goede <hdegoede(a)redhat.com>
commit edfc3722cfef4217c7fe92b272cbe0288ba1ff57 upstream.
The Toshiba Click Mini uses an i2c attached keyboard/touchpad combo
(single i2c_hid device for both) which has a vid:pid of 04F3:0401,
which is also used by a bunch of Elan touchpads which are handled by the
drivers/input/mouse/elan_i2c driver, but that driver deals with pure
touchpads and does not work for a combo device such as the one on the
Toshiba Click Mini.
The combo on the Mini has an ACPI id of ELAN0800, which is not claimed
by the elan_i2c driver, so check for that and if it is found do not ignore
the device. This fixes the keyboard/touchpad combo on the Mini not working
(although with the touchpad in mouse emulation mode).
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-core.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2365,7 +2365,6 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) },
- { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
@@ -2635,6 +2634,17 @@ bool hid_ignore(struct hid_device *hdev)
strncmp(hdev->name, "www.masterkit.ru MA901", 22) == 0)
return true;
break;
+ case USB_VENDOR_ID_ELAN:
+ /*
+ * Many Elan devices have a product id of 0x0401 and are handled
+ * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev
+ * is not (and cannot be) handled by that driver ->
+ * Ignore all 0x0401 devs except for the ELAN0800 dev.
+ */
+ if (hdev->product == 0x0401 &&
+ strncmp(hdev->name, "ELAN0800", 8) != 0)
+ return true;
+ break;
}
if (hdev->type == HID_TYPE_USBMOUSE &&
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.9/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.9/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.9/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.9/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
fs/proc/kcore.c: use probe_kernel_read() instead of memcpy()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fs-proc-kcore.c-use-probe_kernel_read-instead-of-memcpy.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d0290bc20d4739b7a900ae37eb5d4cc3be2b393f Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Tue, 6 Feb 2018 15:37:13 -0800
Subject: fs/proc/kcore.c: use probe_kernel_read() instead of memcpy()
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
commit d0290bc20d4739b7a900ae37eb5d4cc3be2b393f upstream.
Commit df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext
data") added a bounce buffer to avoid hardened usercopy checks. Copying
to the bounce buffer was implemented with a simple memcpy() assuming
that it is always valid to read from kernel memory iff the
kern_addr_valid() check passed.
A simple, but pointless, test case like "dd if=/proc/kcore of=/dev/null"
now can easily crash the kernel, since the former execption handling on
invalid kernel addresses now doesn't work anymore.
Also adding a kern_addr_valid() implementation wouldn't help here. Most
architectures simply return 1 here, while a couple implemented a page
table walk to figure out if something is mapped at the address in
question.
With DEBUG_PAGEALLOC active mappings are established and removed all the
time, so that relying on the result of kern_addr_valid() before
executing the memcpy() also doesn't work.
Therefore simply use probe_kernel_read() to copy to the bounce buffer.
This also allows to simplify read_kcore().
At least on s390 this fixes the observed crashes and doesn't introduce
warnings that were removed with df04abfd181a ("fs/proc/kcore.c: Add
bounce buffer for ktext data"), even though the generic
probe_kernel_read() implementation uses uaccess functions.
While looking into this I'm also wondering if kern_addr_valid() could be
completely removed...(?)
Link: http://lkml.kernel.org/r/20171202132739.99971-1-heiko.carstens@de.ibm.com
Fixes: df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
Fixes: f5509cc18daa ("mm: Hardened usercopy")
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Acked-by: Kees Cook <keescook(a)chromium.org>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/proc/kcore.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -507,23 +507,15 @@ read_kcore(struct file *file, char __use
return -EFAULT;
} else {
if (kern_addr_valid(start)) {
- unsigned long n;
-
/*
* Using bounce buffer to bypass the
* hardened user copy kernel text checks.
*/
- memcpy(buf, (char *) start, tsz);
- n = copy_to_user(buffer, buf, tsz);
- /*
- * We cannot distinguish between fault on source
- * and fault on destination. When this happens
- * we clear too and hope it will trigger the
- * EFAULT again.
- */
- if (n) {
- if (clear_user(buffer + tsz - n,
- n))
+ if (probe_kernel_read(buf, (void *) start, tsz)) {
+ if (clear_user(buffer, tsz))
+ return -EFAULT;
+ } else {
+ if (copy_to_user(buffer, buf, tsz))
return -EFAULT;
}
} else {
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-4.9/fs-proc-kcore.c-use-probe_kernel_read-instead-of-memcpy.patch
This is a note to let you know that I've just added the patch titled
EDAC, octeon: Fix an uninitialized variable warning
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
edac-octeon-fix-an-uninitialized-variable-warning.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 544e92581a2ac44607d7cc602c6b54d18656f56d Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Mon, 13 Nov 2017 16:12:06 +0000
Subject: EDAC, octeon: Fix an uninitialized variable warning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: James Hogan <jhogan(a)kernel.org>
commit 544e92581a2ac44607d7cc602c6b54d18656f56d upstream.
Fix an uninitialized variable warning in the Octeon EDAC driver, as seen
in MIPS cavium_octeon_defconfig builds since v4.14 with Codescape GNU
Tools 2016.05-03:
drivers/edac/octeon_edac-lmc.c In function ‘octeon_lmc_edac_poll_o2’:
drivers/edac/octeon_edac-lmc.c:87:24: warning: ‘((long unsigned int*)&int_reg)[1]’ may \
be used uninitialized in this function [-Wmaybe-uninitialized]
if (int_reg.s.sec_err || int_reg.s.ded_err) {
^
Iinitialise the whole int_reg variable to zero before the conditional
assignments in the error injection case.
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Acked-by: David Daney <david.daney(a)cavium.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Cc: linux-mips(a)linux-mips.org
Fixes: 1bc021e81565 ("EDAC: Octeon: Add error injection support")
Link: http://lkml.kernel.org/r/20171113161206.20990-1-james.hogan@mips.com
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/octeon_edac-lmc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/octeon_edac-lmc.c
+++ b/drivers/edac/octeon_edac-lmc.c
@@ -79,6 +79,7 @@ static void octeon_lmc_edac_poll_o2(stru
if (!pvt->inject)
int_reg.u64 = cvmx_read_csr(CVMX_LMCX_INT(mci->mc_idx));
else {
+ int_reg.u64 = 0;
if (pvt->error_type == 1)
int_reg.s.sec_err = 1;
if (pvt->error_type == 2)
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.9/edac-octeon-fix-an-uninitialized-variable-warning.patch
This is a note to let you know that I've just added the patch titled
crypto: sha512-mb - initialize pending lengths correctly
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-sha512-mb-initialize-pending-lengths-correctly.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From eff84b379089cd8b4e83599639c1f5f6e34ef7bf Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 24 Jan 2018 00:31:27 -0800
Subject: crypto: sha512-mb - initialize pending lengths correctly
From: Eric Biggers <ebiggers(a)google.com>
commit eff84b379089cd8b4e83599639c1f5f6e34ef7bf upstream.
The SHA-512 multibuffer code keeps track of the number of blocks pending
in each lane. The minimum of these values is used to identify the next
lane that will be completed. Unused lanes are set to a large number
(0xFFFFFFFF) so that they don't affect this calculation.
However, it was forgotten to set the lengths to this value in the
initial state, where all lanes are unused. As a result it was possible
for sha512_mb_mgr_get_comp_job_avx2() to select an unused lane, causing
a NULL pointer dereference. Specifically this could happen in the case
where ->update() was passed fewer than SHA512_BLOCK_SIZE bytes of data,
so it then called sha_complete_job() without having actually submitted
any blocks to the multi-buffer code. This hit a NULL pointer
dereference if another task happened to have submitted blocks
concurrently to the same CPU and the flush timer had not yet expired.
Fix this by initializing sha512_mb_mgr->lens correctly.
As usual, this bug was found by syzkaller.
Fixes: 45691e2d9b18 ("crypto: sha512-mb - submit/flush routines for AVX2")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c
+++ b/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c
@@ -57,10 +57,12 @@ void sha512_mb_mgr_init_avx2(struct sha5
{
unsigned int j;
- state->lens[0] = 0;
- state->lens[1] = 1;
- state->lens[2] = 2;
- state->lens[3] = 3;
+ /* initially all lanes are unused */
+ state->lens[0] = 0xFFFFFFFF00000000;
+ state->lens[1] = 0xFFFFFFFF00000001;
+ state->lens[2] = 0xFFFFFFFF00000002;
+ state->lens[3] = 0xFFFFFFFF00000003;
+
state->unused_lanes = 0xFF03020100;
for (j = 0; j < 4; j++)
state->ldata[j].job_in_lane = NULL;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
clocksource/drivers/stm32: Fix kernel panic with multiple timers
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e0aeca3d8cbaea514eb98df1149faa918f9ec42d Mon Sep 17 00:00:00 2001
From: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Date: Mon, 8 Jan 2018 14:28:50 +0100
Subject: clocksource/drivers/stm32: Fix kernel panic with multiple timers
From: Daniel Lezcano <daniel.lezcano(a)linaro.org>
commit e0aeca3d8cbaea514eb98df1149faa918f9ec42d upstream.
The current code hides a couple of bugs:
- The global variable 'clock_event_ddata' is overwritten each time the
init function is invoked.
This is fixed with a kmemdup() instead of assigning the global variable. That
prevents a memory corruption when several timers are defined in the DT.
- The clockevent's event_handler is NULL if the time framework does
not select the clockevent when registering it, this is fine but the init
code generates in any case an interrupt leading to dereference this
NULL pointer.
The stm32 timer works with shadow registers, a mechanism to cache the
registers. When a change is done in one buffered register, we need to
artificially generate an event to force the timer to copy the content
of the register to the shadowed register.
The auto-reload register (ARR) is one of the shadowed register as well as
the prescaler register (PSC), so in order to force the copy, we issue an
event which in turn leads to an interrupt and the NULL dereference.
This is fixed by inverting two lines where we clear the status register
before enabling the update event interrupt.
As this kernel crash is resulting from the combination of these two bugs,
the fixes are grouped into a single patch.
Tested-by: Benjamin Gaignard <benjamin.gaignard(a)st.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Acked-by: Benjamin Gaignard <benjamin.gaignard(a)st.com>
Cc: Alexandre Torgue <alexandre.torgue(a)st.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/1515418139-23276-11-git-send-email-daniel.lezcano@…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clocksource/timer-stm32.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -106,6 +106,10 @@ static int __init stm32_clockevent_init(
unsigned long rate, max_delta;
int irq, ret, bits, prescaler = 1;
+ data = kmemdup(&clock_event_ddata, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
clk = of_clk_get(np, 0);
if (IS_ERR(clk)) {
ret = PTR_ERR(clk);
@@ -156,8 +160,8 @@ static int __init stm32_clockevent_init(
writel_relaxed(prescaler - 1, data->base + TIM_PSC);
writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
- writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
writel_relaxed(0, data->base + TIM_SR);
+ writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
@@ -184,6 +188,7 @@ err_iomap:
err_clk_enable:
clk_put(clk);
err_clk_get:
+ kfree(data);
return ret;
}
Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are
queue-4.9/clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
This is a note to let you know that I've just added the patch titled
crypto: caam - fix endless loop when DECO acquire fails
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Horia=20Geant=C4=83?= <horia.geanta(a)nxp.com>
Date: Mon, 5 Feb 2018 11:15:52 +0200
Subject: crypto: caam - fix endless loop when DECO acquire fails
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Horia Geantă <horia.geanta(a)nxp.com>
commit 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 upstream.
In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails
with -ENODEV, caam_probe() enters an endless loop:
run_descriptor_deco0
ret -ENODEV
-> instantiate_rng
-ENODEV, overwritten by -EAGAIN
ret -EAGAIN
-> caam_probe
-EAGAIN results in endless loop
It turns out the error path in instantiate_rng() is incorrect,
the checks are done in the wrong order.
Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles")
Reported-by: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Suggested-by: Auer Lukas <lukas.auer(a)aisec.fraunhofer.de>
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/caam/ctrl.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -228,12 +228,16 @@ static int instantiate_rng(struct device
* without any error (HW optimizations for later
* CAAM eras), then try again.
*/
+ if (ret)
+ break;
+
rdsta_val = rd_reg32(&ctrl->r4tst[0].rdsta) & RDSTA_IFMASK;
if ((status && status != JRSTA_SSRC_JUMP_HALT_CC) ||
- !(rdsta_val & (1 << sh_idx)))
+ !(rdsta_val & (1 << sh_idx))) {
ret = -EAGAIN;
- if (ret)
break;
+ }
+
dev_info(ctrldev, "Instantiated RNG4 SH%d\n", sh_idx);
/* Clear the contents before recreating the descriptor */
memset(desc, 0x00, CAAM_CMD_SZ * 7);
Patches currently in stable-queue which might be from horia.geanta(a)nxp.com are
queue-4.9/crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 61f5acea8737d9b717fcc22bb6679924f3c82b98 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Mon, 8 Jan 2018 10:44:16 +0100
Subject: Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Hans de Goede <hdegoede(a)redhat.com>
commit 61f5acea8737d9b717fcc22bb6679924f3c82b98 upstream.
Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
has several issues (see the original commit message). An added advantage
of moving over to the USB-core reset-resume handling is that it also
disables autosuspend for these devices, which is similarly broken on these.
But there are 2 issues with this approach:
1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek
devices.
2) Sofar only 2 of the 10 QCA devices known to the btusb code have been
added to usb/core/quirks.c and if we fix the Realtek case the same way
we need to add an additional 14 entries. So in essence we need to
duplicate a large part of the usb_device_id table in btusb.c in
usb/core/quirks.c and manually keep them in sync.
This commit instead restores setting a reset-resume quirk for QCA devices
in the btusb.c code, avoiding the duplicate usb_device_id table problem.
This commit avoids the problems with the original DIY BTUSB_RESET_RESUME
code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the
usb_device.
This commit also moves the BTUSB_REALTEK case over to directly setting the
USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused
BTUSB_RESET_RESUME code.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Fixes: 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
Cc: Leif Liddy <leif.linux(a)gmail.com>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Daniel Drake <drake(a)endlessm.com>
Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -23,6 +23,7 @@
#include <linux/module.h>
#include <linux/usb.h>
+#include <linux/usb/quirks.h>
#include <linux/firmware.h>
#include <asm/unaligned.h>
@@ -369,8 +370,8 @@ static const struct usb_device_id blackl
#define BTUSB_FIRMWARE_LOADED 7
#define BTUSB_FIRMWARE_FAILED 8
#define BTUSB_BOOTING 9
-#define BTUSB_RESET_RESUME 10
-#define BTUSB_DIAG_RUNNING 11
+#define BTUSB_DIAG_RUNNING 10
+#define BTUSB_OOB_WAKE_ENABLED 11
struct btusb_data {
struct hci_dev *hdev;
@@ -2925,6 +2926,12 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
+
+ /* QCA Rome devices lose their updated firmware over suspend,
+ * but the USB hub doesn't notice any status change.
+ * explicitly request a device reset on resume.
+ */
+ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
@@ -2935,7 +2942,7 @@ static int btusb_probe(struct usb_interf
* but the USB hub doesn't notice any status change.
* Explicitly request a device reset on resume.
*/
- set_bit(BTUSB_RESET_RESUME, &data->flags);
+ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
}
#endif
@@ -3092,14 +3099,6 @@ static int btusb_suspend(struct usb_inte
btusb_stop_traffic(data);
usb_kill_anchored_urbs(&data->tx_anchor);
- /* Optionally request a device reset on resume, but only when
- * wakeups are disabled. If wakeups are enabled we assume the
- * device will stay powered up throughout suspend.
- */
- if (test_bit(BTUSB_RESET_RESUME, &data->flags) &&
- !device_may_wakeup(&data->udev->dev))
- data->udev->reset_resume = 1;
-
return 0;
}
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.9/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.9/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.9/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.9/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btsdio: Do not bind to non-removable BCM43341
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b4cdaba274247c9c841c6a682c08fa91fb3aa549 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 29 Nov 2017 20:29:07 +0100
Subject: Bluetooth: btsdio: Do not bind to non-removable BCM43341
From: Hans de Goede <hdegoede(a)redhat.com>
commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 upstream.
BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
use an UART connection for bluetooth. But they also advertise btsdio
support on their 3th sdio function, this causes 2 problems:
1) A non functioning BT HCI getting registered
2) Since the btsdio driver does not have suspend/resume callbacks,
mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
to react as if the SDIO-card is removed and since the slot is
marked as non-removable it will never get detected as inserted again.
Which results in wifi no longer working after a suspend/resume.
This commit fixes both by making btsdio ignore BCM43341 devices
when connected to a slot which is marked non-removable.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btsdio.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -31,6 +31,7 @@
#include <linux/errno.h>
#include <linux/skbuff.h>
+#include <linux/mmc/host.h>
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
@@ -291,6 +292,14 @@ static int btsdio_probe(struct sdio_func
tuple = tuple->next;
}
+ /* BCM43341 devices soldered onto the PCB (non-removable) use an
+ * uart connection for bluetooth, ignore the BT SDIO interface.
+ */
+ if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
+ func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
+ !mmc_card_is_removable(func->card->host))
+ return -ENODEV;
+
data = devm_kzalloc(&func->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.9/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.9/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.9/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.9/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
ASoC: skl: Fix kernel warning due to zero NHTL entry
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-skl-fix-kernel-warning-due-to-zero-nhtl-entry.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 20a1ea2222e7cbf96e9bf8579362e971491e6aea Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 3 Jan 2018 16:38:46 +0100
Subject: ASoC: skl: Fix kernel warning due to zero NHTL entry
From: Takashi Iwai <tiwai(a)suse.de>
commit 20a1ea2222e7cbf96e9bf8579362e971491e6aea upstream.
I got the following kernel warning when loading snd-soc-skl module on
Dell Latitude 7270 laptop:
memremap attempted on mixed range 0x0000000000000000 size: 0x0
WARNING: CPU: 0 PID: 484 at kernel/memremap.c:98 memremap+0x8a/0x180
Call Trace:
skl_nhlt_init+0x82/0xf0 [snd_soc_skl]
skl_probe+0x2ee/0x7c0 [snd_soc_skl]
....
It seems that the machine doesn't support the SKL DSP gives the empty
NHLT entry, and it triggers the warning. For avoiding it, let do the
zero check before calling memremap().
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/intel/skylake/skl-nhlt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/sound/soc/intel/skylake/skl-nhlt.c
+++ b/sound/soc/intel/skylake/skl-nhlt.c
@@ -41,7 +41,8 @@ struct nhlt_acpi_table *skl_nhlt_init(st
obj = acpi_evaluate_dsm(handle, OSC_UUID, 1, 1, NULL);
if (obj && obj->type == ACPI_TYPE_BUFFER) {
nhlt_ptr = (struct nhlt_resource_desc *)obj->buffer.pointer;
- nhlt_table = (struct nhlt_acpi_table *)
+ if (nhlt_ptr->length)
+ nhlt_table = (struct nhlt_acpi_table *)
memremap(nhlt_ptr->min_addr, nhlt_ptr->length,
MEMREMAP_WB);
ACPI_FREE(obj);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/asoc-skl-fix-kernel-warning-due-to-zero-nhtl-entry.patch
This is a note to let you know that I've just added the patch titled
ASoC: rockchip: i2s: fix playback after runtime resume
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-rockchip-i2s-fix-playback-after-runtime-resume.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c66234cfedfc3e6e3b62563a5f2c1562be09a35d Mon Sep 17 00:00:00 2001
From: John Keeping <john(a)metanate.com>
Date: Mon, 8 Jan 2018 16:01:04 +0000
Subject: ASoC: rockchip: i2s: fix playback after runtime resume
From: John Keeping <john(a)metanate.com>
commit c66234cfedfc3e6e3b62563a5f2c1562be09a35d upstream.
When restoring registers during runtime resume, we must not write to
I2S_TXDR which is the transmit FIFO as this queues up a sample to be
output and pushes all of the output channels down by one.
This can be demonstrated with the speaker-test utility:
for i in a b c; do speaker-test -c 2 -s 1; done
which should play a test through the left speaker three times but if the
I2S hardware starts runtime suspended the first sample will be played
through the right speaker.
Fix this by marking I2S_TXDR as volatile (which also requires marking it
as readble, even though it technically isn't). This seems to be the
most robust fix, the alternative of giving I2S_TXDR a default value is
more fragile since it does not prevent regcache writing to the register
in all circumstances.
While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
are not writable so they do not suffer from the same problem as I2S_TXDR
but reading from I2S_RXDR does suffer from a similar problem.
Fixes: f0447f6cbb20 ("ASoC: rockchip: i2s: restore register during runtime_suspend/resume cycle", 2016-09-07)
Signed-off-by: John Keeping <john(a)metanate.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/rockchip/rockchip_i2s.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -476,6 +476,7 @@ static bool rockchip_i2s_rd_reg(struct d
case I2S_INTCR:
case I2S_XFER:
case I2S_CLR:
+ case I2S_TXDR:
case I2S_RXDR:
case I2S_FIFOLR:
case I2S_INTSR:
@@ -490,6 +491,9 @@ static bool rockchip_i2s_volatile_reg(st
switch (reg) {
case I2S_INTSR:
case I2S_CLR:
+ case I2S_FIFOLR:
+ case I2S_TXDR:
+ case I2S_RXDR:
return true;
default:
return false;
@@ -499,6 +503,8 @@ static bool rockchip_i2s_volatile_reg(st
static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
+ case I2S_RXDR:
+ return true;
default:
return false;
}
Patches currently in stable-queue which might be from john(a)metanate.com are
queue-4.9/asoc-rockchip-i2s-fix-playback-after-runtime-resume.patch
This is a note to let you know that I've just added the patch titled
arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 6 Feb 2018 17:56:06 +0000
Subject: arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream.
KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.
Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.
Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kvm/handle_exit.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -38,7 +38,7 @@ static int handle_hvc(struct kvm_vcpu *v
ret = kvm_psci_call(vcpu);
if (ret < 0) {
- kvm_inject_undefined(vcpu);
+ vcpu_set_reg(vcpu, 0, ~0UL);
return 1;
}
@@ -47,7 +47,16 @@ static int handle_hvc(struct kvm_vcpu *v
static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
- kvm_inject_undefined(vcpu);
+ /*
+ * "If an SMC instruction executed at Non-secure EL1 is
+ * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a
+ * Trap exception, not a Secure Monitor Call exception [...]"
+ *
+ * We need to advance the PC after the trap, as it would
+ * otherwise return to the same address...
+ */
+ vcpu_set_reg(vcpu, 0, ~0UL);
+ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
return 1;
}
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.9/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
This is a note to let you know that I've just added the patch titled
alpha: fix reboot on Avanti platform
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alpha-fix-reboot-on-avanti-platform.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 55fc633c41a08ce9244ff5f528f420b16b1e04d6 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 13:59:54 -0500
Subject: alpha: fix reboot on Avanti platform
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream.
We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get
machine check exception when attempting to reboot the machine.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/pci_impl.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/pci_impl.h
+++ b/arch/alpha/kernel/pci_impl.h
@@ -143,7 +143,8 @@ struct pci_iommu_arena
};
#if defined(CONFIG_ALPHA_SRM) && \
- (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA))
+ (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA) || \
+ defined(CONFIG_ALPHA_AVANTI))
# define NEED_SRM_SAVE_RESTORE
#else
# undef NEED_SRM_SAVE_RESTORE
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.9/alpha-fix-formating-of-stack-content.patch
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
alpha: fix formating of stack content
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alpha-fix-formating-of-stack-content.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4b01abdb32fc36abe877503bfbd33019159fad71 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 14:00:32 -0500
Subject: alpha: fix formating of stack content
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 4b01abdb32fc36abe877503bfbd33019159fad71 upstream.
Since version 4.9, the kernel automatically breaks printk calls into
multiple newlines unless pr_cont is used. Fix the alpha stacktrace code,
so that it prints stack trace in four columns, as it was initially
intended.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/traps.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -158,11 +158,16 @@ void show_stack(struct task_struct *task
for(i=0; i < kstack_depth_to_print; i++) {
if (((long) stack & (THREAD_SIZE-1)) == 0)
break;
- if (i && ((i % 4) == 0))
- printk("\n ");
- printk("%016lx ", *stack++);
+ if ((i % 4) == 0) {
+ if (i)
+ pr_cont("\n");
+ printk(" ");
+ } else {
+ pr_cont(" ");
+ }
+ pr_cont("%016lx", *stack++);
}
- printk("\n");
+ pr_cont("\n");
dik_show_trace(sp);
}
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.9/alpha-fix-formating-of-stack-content.patch
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
alpha: fix crash if pthread_create races with signal delivery
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 21ffceda1c8b3807615c40d440d7815e0c85d366 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 14:01:34 -0500
Subject: alpha: fix crash if pthread_create races with signal delivery
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream.
On alpha, a process will crash if it attempts to start a thread and a
signal is delivered at the same time. The crash can be reproduced with
this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
The reason for the crash is this:
* we call the clone syscall
* we go to the function copy_process
* copy process calls copy_thread_tls, it is a wrapper around copy_thread
* copy_thread sets the tls pointer: childti->pcb.unique = regs->r20
* copy_thread sets regs->r20 to zero
* we go back to copy_process
* copy process checks "if (signal_pending(current))" and returns
-ERESTARTNOINTR
* the clone syscall is restarted, but this time, regs->r20 is zero, so
the new thread is created with zero tls pointer
* the new thread crashes in start_thread when attempting to access tls
The comment in the code says that setting the register r20 is some
compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so
we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug
by zeroing regs->r20 only if CLONE_SETTLS is not set.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -265,12 +265,13 @@ copy_thread(unsigned long clone_flags, u
application calling fork. */
if (clone_flags & CLONE_SETTLS)
childti->pcb.unique = regs->r20;
+ else
+ regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */
childti->pcb.usp = usp ?: rdusp();
*childregs = *regs;
childregs->r0 = 0;
childregs->r19 = 0;
childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */
- regs->r20 = 0;
stack = ((struct switch_stack *) regs) - 1;
*childstack = *stack;
childstack->r26 = (unsigned long) ret_from_fork;
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.9/alpha-fix-formating-of-stack-content.patch
queue-4.9/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.9/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.9/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.9/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
xtensa: fix futex_atomic_cmpxchg_inatomic
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ca47480921587ae30417dd234a9f79af188e3666 Mon Sep 17 00:00:00 2001
From: Max Filippov <jcmvbkbc(a)gmail.com>
Date: Fri, 5 Jan 2018 14:27:58 -0800
Subject: xtensa: fix futex_atomic_cmpxchg_inatomic
From: Max Filippov <jcmvbkbc(a)gmail.com>
commit ca47480921587ae30417dd234a9f79af188e3666 upstream.
Return 0 if the operation was successful, not the userspace memory
value. Check that userspace value equals passed oldval, not itself.
Don't update *uval if the value wasn't read from userspace memory.
This fixes process hang due to infinite loop in futex_lock_pi.
It also fixes a bunch of glibc tests nptl/tst-mutexpi*.
Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/xtensa/include/asm/futex.h | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
--- a/arch/xtensa/include/asm/futex.h
+++ b/arch/xtensa/include/asm/futex.h
@@ -109,7 +109,6 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
u32 oldval, u32 newval)
{
int ret = 0;
- u32 prev;
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
@@ -120,26 +119,24 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
__asm__ __volatile__ (
" # futex_atomic_cmpxchg_inatomic\n"
- "1: l32i %1, %3, 0\n"
- " mov %0, %5\n"
- " wsr %1, scompare1\n"
- "2: s32c1i %0, %3, 0\n"
- "3:\n"
+ " wsr %5, scompare1\n"
+ "1: s32c1i %1, %4, 0\n"
+ " s32i %1, %6, 0\n"
+ "2:\n"
" .section .fixup,\"ax\"\n"
" .align 4\n"
- "4: .long 3b\n"
- "5: l32r %1, 4b\n"
- " movi %0, %6\n"
+ "3: .long 2b\n"
+ "4: l32r %1, 3b\n"
+ " movi %0, %7\n"
" jx %1\n"
" .previous\n"
" .section __ex_table,\"a\"\n"
- " .long 1b,5b,2b,5b\n"
+ " .long 1b,4b\n"
" .previous\n"
- : "+r" (ret), "=&r" (prev), "+m" (*uaddr)
- : "r" (uaddr), "r" (oldval), "r" (newval), "I" (-EFAULT)
+ : "+r" (ret), "+r" (newval), "+m" (*uaddr), "+m" (*uval)
+ : "r" (uaddr), "r" (oldval), "r" (uval), "I" (-EFAULT)
: "memory");
- *uval = prev;
return ret;
}
Patches currently in stable-queue which might be from jcmvbkbc(a)gmail.com are
queue-4.4/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
This is a note to let you know that I've just added the patch titled
watchdog: imx2_wdt: restore previous timeout after suspend+resume
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0be267255cef64e1c58475baa7b25568355a3816 Mon Sep 17 00:00:00 2001
From: Martin Kaiser <martin(a)kaiser.cx>
Date: Mon, 1 Jan 2018 18:26:47 +0100
Subject: watchdog: imx2_wdt: restore previous timeout after suspend+resume
From: Martin Kaiser <martin(a)kaiser.cx>
commit 0be267255cef64e1c58475baa7b25568355a3816 upstream.
When the watchdog device is suspended, its timeout is set to the maximum
value. During resume, the previously set timeout should be restored.
This does not work at the moment.
The suspend function calls
imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
and resume reverts this by calling
imx2_wdt_set_timeout(wdog, wdog->timeout);
However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore,
wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume
function.
Fix this by adding a new function __imx2_wdt_set_timeout() which
only updates the hardware settings. imx2_wdt_set_timeout() now calls
__imx2_wdt_set_timeout() and then saves the new timeout to
wdog->timeout.
During suspend, we call __imx2_wdt_set_timeout() directly so that
wdog->timeout won't be updated and we can restore the previous value
during resume. This approach makes wdog->timeout different from the
actual setting in the hardware which is usually not a good thing.
However, the two differ only while we're suspended and no kernel code is
running, so it should be ok in this case.
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/watchdog/imx2_wdt.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -161,15 +161,21 @@ static void imx2_wdt_timer_ping(unsigned
mod_timer(&wdev->timer, jiffies + wdog->timeout * HZ / 2);
}
-static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
- unsigned int new_timeout)
+static void __imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
{
struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
- wdog->timeout = new_timeout;
-
regmap_update_bits(wdev->regmap, IMX2_WDT_WCR, IMX2_WDT_WCR_WT,
WDOG_SEC_TO_COUNT(new_timeout));
+}
+
+static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ __imx2_wdt_set_timeout(wdog, new_timeout);
+
+ wdog->timeout = new_timeout;
return 0;
}
@@ -353,7 +359,11 @@ static int imx2_wdt_suspend(struct devic
/* The watchdog IP block is running */
if (imx2_wdt_is_running(wdev)) {
- imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
+ /*
+ * Don't update wdog->timeout, we'll restore the current value
+ * during resume.
+ */
+ __imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
imx2_wdt_ping(wdog);
/* The watchdog is not active */
Patches currently in stable-queue which might be from martin(a)kaiser.cx are
queue-4.4/watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
From: Hans Verkuil <hans.verkuil(a)cisco.com>
This patch series fixes a number of bugs and culminates in the removal
of the set_fs(KERNEL_DS) call in v4l2-compat-ioctl32.c.
This was tested with a VM running 4.4, the vivid driver (since that
emulates almost all V4L2 ioctls that need to pass through v4l2-compat-ioctl32.c)
and a 32-bit v4l2-compliance utility since that exercises almost all ioctls
as well. Combined this gives good test coverage.
Most of the v4l2-compat-ioctl32.c do cleanups and fix subtle issues that
v4l2-compliance complained about. The purpose is to 1) make it easy to
verify that the final patch didn't introduce errors by first eliminating
errors caused by other known bugs, and 2) keep the final patch at least
somewhat readable.
Regards,
Hans
Daniel Mentz (2):
media: v4l2-compat-ioctl32: Copy v4l2_window->global_alpha
media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic
Hans Verkuil (11):
media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
media: v4l2-compat-ioctl32.c: fix the indentation
media: v4l2-compat-ioctl32.c: move 'helper' functions to
__get/put_v4l2_format32
media: v4l2-compat-ioctl32.c: avoid sizeof(type)
media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32
media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
media: v4l2-compat-ioctl32.c: don't copy back the result for certain
errors
Ricardo Ribalda Delgado (1):
vb2: V4L2_BUF_FLAG_DONE is set after DQBUF
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1023 +++++++++++++++----------
drivers/media/v4l2-core/v4l2-ioctl.c | 5 +-
drivers/media/v4l2-core/videobuf2-v4l2.c | 6 +
3 files changed, 624 insertions(+), 410 deletions(-)
--
2.15.1
This is a note to let you know that I've just added the patch titled
signal/sh: Ensure si_signo is initialized in do_divide_error
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Mon, 24 Jul 2017 17:30:30 -0500
Subject: signal/sh: Ensure si_signo is initialized in do_divide_error
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream.
Set si_signo.
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Rich Felker <dalias(a)libc.org>
Cc: Paul Mundt <lethal(a)linux-sh.org>
Cc: linux-sh(a)vger.kernel.org
Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.")
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/kernel/traps_32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/sh/kernel/traps_32.c
+++ b/arch/sh/kernel/traps_32.c
@@ -607,7 +607,8 @@ asmlinkage void do_divide_error(unsigned
break;
}
- force_sig_info(SIGFPE, &info, current);
+ info.si_signo = SIGFPE;
+ force_sig_info(info.si_signo, &info, current);
}
#endif
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.4/netfilter-nf_queue-make-the-queue_handler-pernet.patch
queue-4.4/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.4/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
signal/openrisc: Fix do_unaligned_access to send the proper signal
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 500d58300571b6602341b041f97c082a461ef994 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 04:16:47 -0500
Subject: signal/openrisc: Fix do_unaligned_access to send the proper signal
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 500d58300571b6602341b041f97c082a461ef994 upstream.
While reviewing the signal sending on openrisc the do_unaligned_access
function stood out because it is obviously wrong. A comment about an
si_code set above when actually si_code is never set. Leading to a
random si_code being sent to userspace in the event of an unaligned
access.
Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
si_code to send for an unaligned access. That is what other
architectures do and what is required by posix.
Given that do_unaligned_access is broken in a way that no one can be
relying on it on openrisc fix the code to just do the right thing.
Fixes: 769a8a96229e ("OpenRISC: Traps")
Cc: Jonas Bonn <jonas(a)southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi>
Cc: Stafford Horne <shorne(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: openrisc(a)lists.librecores.org
Acked-by: Stafford Horne <shorne(a)gmail.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/openrisc/kernel/traps.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -302,12 +302,12 @@ asmlinkage void do_unaligned_access(stru
siginfo_t info;
if (user_mode(regs)) {
- /* Send a SIGSEGV */
- info.si_signo = SIGSEGV;
+ /* Send a SIGBUS */
+ info.si_signo = SIGBUS;
info.si_errno = 0;
- /* info.si_code has been set above */
- info.si_addr = (void *)address;
- force_sig_info(SIGSEGV, &info, current);
+ info.si_code = BUS_ADRALN;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGBUS, &info, current);
} else {
printk("KERNEL: Unaligned Access 0x%.8lx\n", address);
show_registers(regs);
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.4/netfilter-nf_queue-make-the-queue_handler-pernet.patch
queue-4.4/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.4/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7d06d5895c159f64c46560dc258e553ad8670fe0 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Wed, 20 Dec 2017 19:00:07 +0800
Subject: Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 7d06d5895c159f64c46560dc258e553ad8670fe0 upstream.
This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56.
This commit causes a regression on some QCA ROME chips. The USB device
reset happens in btusb_open(), hence firmware loading gets interrupted.
Furthermore, this commit stops working after commit
("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to
enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in
btusb_suspend() when it's not a wakeup source.
If we really want to reset the USB device, we need to do it before
btusb_open(). Let's handle it in drivers/usb/core/quirks.c.
Cc: Leif Liddy <leif.linux(a)gmail.com>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Daniel Drake <drake(a)endlessm.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Reviewed-by: Brian Norris <briannorris(a)chromium.org>
Tested-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 6 ------
1 file changed, 6 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2969,12 +2969,6 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
-
- /* QCA Rome devices lose their updated firmware over suspend,
- * but the USB hub doesn't notice any status change.
- * Explicitly request a device reset on resume.
- */
- set_bit(BTUSB_RESET_RESUME, &data->flags);
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.4/revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
pktcdvd: Fix pkt_setup_dev() error path
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pktcdvd-fix-pkt_setup_dev-error-path.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 2 Jan 2018 11:39:47 -0800
Subject: pktcdvd: Fix pkt_setup_dev() error path
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.
Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
modified add_disk() and disk_release() but did not update any of the
error paths that trigger a put_disk() call after disk->queue has been
assigned. That introduced the following behavior in the pktcdvd driver
if pkt_new_dev() fails:
Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]
Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
error path.
Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/pktcdvd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2779,7 +2779,7 @@ static int pkt_setup_dev(dev_t dev, dev_
pd->pkt_dev = MKDEV(pktdev_major, idx);
ret = pkt_new_dev(pd, dev);
if (ret)
- goto out_new_dev;
+ goto out_mem2;
/* inherit events of the host device */
disk->events = pd->bdev->bd_disk->events;
@@ -2797,8 +2797,6 @@ static int pkt_setup_dev(dev_t dev, dev_
mutex_unlock(&ctl_mutex);
return 0;
-out_new_dev:
- blk_cleanup_queue(disk->queue);
out_mem2:
put_disk(disk);
out_mem:
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.4/pktcdvd-fix-pkt_setup_dev-error-path.patch
This is a note to let you know that I've just added the patch titled
media: ts2020: avoid integer overflows on 32 bit machines
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Date: Wed, 10 Jan 2018 07:20:39 -0500
Subject: media: ts2020: avoid integer overflows on 32 bit machines
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
commit 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 upstream.
Before this patch, when compiled for arm32, the signal strength
were reported as:
Lock (0x1f) Signal= 4294908.66dBm C/N= 12.79dB
Because of a 32 bit integer overflow. After it, it is properly
reported as:
Lock (0x1f) Signal= -58.64dBm C/N= 12.79dB
Fixes: 0f91c9d6bab9 ("[media] TS2020: Calculate tuner gain correctly")
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/dvb-frontends/ts2020.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -369,7 +369,7 @@ static int ts2020_read_tuner_gain(struct
gain2 = clamp_t(long, gain2, 0, 13);
v_agc = clamp_t(long, v_agc, 400, 1100);
- *_gain = -(gain1 * 2330 +
+ *_gain = -((__s64)gain1 * 2330 +
gain2 * 3500 +
v_agc * 24 / 10 * 10 +
10000);
@@ -387,7 +387,7 @@ static int ts2020_read_tuner_gain(struct
gain3 = clamp_t(long, gain3, 0, 6);
v_agc = clamp_t(long, v_agc, 600, 1600);
- *_gain = -(gain1 * 2650 +
+ *_gain = -((__s64)gain1 * 2650 +
gain2 * 3380 +
gain3 * 2850 +
v_agc * 176 / 100 * 10 -
Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are
queue-4.4/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.4/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.4/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.4/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.4/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch
queue-4.4/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.4/vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch
queue-4.4/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.4/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.4/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch
queue-4.4/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.4/media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
queue-4.4/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.4/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.4/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.4/media-v4l2-compat-ioctl32-copy-v4l2_window-global_alpha.patch
queue-4.4/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.4/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9893b905e743ded332575ca04486bd586c0772f7 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Date: Wed, 24 Jan 2018 06:01:57 -0500
Subject: media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.
The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.
That prevents filling the dmesg with lots of messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
Reported-by: Enrico Mioso <mrkiko.rs(a)gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/dvb-usb/cxusb.c | 2 ++
drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
2 files changed, 3 insertions(+)
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -818,6 +818,8 @@ static int dvico_bluebird_xc2028_callbac
case XC2028_RESET_CLK:
deb_info("%s: XC2028_RESET_CLK %d\n", __func__, arg);
break;
+ case XC2028_I2C_FLUSH:
+ break;
default:
deb_info("%s: unknown command %d, arg %d\n", __func__,
command, arg);
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -431,6 +431,7 @@ static int stk7700ph_xc3028_callback(voi
state->dib7000p_ops.set_gpio(adap->fe_adap[0].fe, 8, 0, 1);
break;
case XC2028_RESET_CLK:
+ case XC2028_I2C_FLUSH:
break;
default:
err("%s: unknown command %d, arg %d\n", __func__,
Patches currently in stable-queue which might be from mchehab(a)osg.samsung.com are
queue-4.4/media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6b6977117f50d60455ace86b2d256f6fb4f3de05 Mon Sep 17 00:00:00 2001
From: Liran Alon <liran.alon(a)oracle.com>
Date: Thu, 9 Nov 2017 20:27:20 +0200
Subject: KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Liran Alon <liran.alon(a)oracle.com>
commit 6b6977117f50d60455ace86b2d256f6fb4f3de05 upstream.
Consider the following scenario:
1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
to CPU B via virtual posted-interrupt mechanism.
2. CPU B is currently executing L2 guest.
3. vmx_deliver_nested_posted_interrupt() calls
kvm_vcpu_trigger_posted_interrupt() which will note that
vcpu->mode == IN_GUEST_MODE.
4. Assume that before CPU A sends the physical POSTED_INTR_NESTED_VECTOR
IPI, CPU B exits from L2 to L0 during event-delivery
(valid IDT-vectoring-info).
5. CPU A now sends the physical IPI. The IPI is received in host and
it's handler (smp_kvm_posted_intr_nested_ipi()) does nothing.
6. Assume that before CPU A sets pi_pending=true and KVM_REQ_EVENT,
CPU B continues to run in L0 and reach vcpu_enter_guest(). As
KVM_REQ_EVENT is not set yet, vcpu_enter_guest() will continue and resume
L2 guest.
7. At this point, CPU A sets pi_pending=true and KVM_REQ_EVENT but
it's too late! CPU B already entered L2 and KVM_REQ_EVENT will only be
consumed at next L2 entry!
Another scenario to consider:
1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
to CPU B via virtual posted-interrupt mechanism.
2. Assume that before CPU A calls kvm_vcpu_trigger_posted_interrupt(),
CPU B is at L0 and is about to resume into L2. Further assume that it is
in vcpu_enter_guest() after check for KVM_REQ_EVENT.
3. At this point, CPU A calls kvm_vcpu_trigger_posted_interrupt() which
will note that vcpu->mode != IN_GUEST_MODE. Therefore, do nothing and
return false. Then, will set pi_pending=true and KVM_REQ_EVENT.
4. Now CPU B continue and resumes into L2 guest without processing
the posted-interrupt until next L2 entry!
To fix both issues, we just need to change
vmx_deliver_nested_posted_interrupt() to set pi_pending=true and
KVM_REQ_EVENT before calling kvm_vcpu_trigger_posted_interrupt().
It will fix the first scenario by chaging step (6) to note that
KVM_REQ_EVENT and pi_pending=true and therefore process
nested posted-interrupt.
It will fix the second scenario by two possible ways:
1. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B has changed
vcpu->mode to IN_GUEST_MODE, physical IPI will be sent and will be received
when CPU resumes into L2.
2. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B hasn't yet
changed vcpu->mode to IN_GUEST_MODE, then after CPU B will change
vcpu->mode it will call kvm_request_pending() which will return true and
therefore force another round of vcpu_enter_guest() which will note that
KVM_REQ_EVENT and pi_pending=true and therefore process nested
posted-interrupt.
Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing")
Signed-off-by: Liran Alon <liran.alon(a)oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com>
[Add kvm_vcpu_kick to also handle the case where L1 doesn't intercept L2 HLT
and L2 executes HLT instruction. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4595,14 +4595,15 @@ static int vmx_deliver_nested_posted_int
if (is_guest_mode(vcpu) &&
vector == vmx->nested.posted_intr_nv) {
- /* the PIR and ON have been set by L1. */
- kvm_vcpu_trigger_posted_interrupt(vcpu);
/*
* If a posted intr is not recognized by hardware,
* we will accomplish it in the next vmentry.
*/
vmx->nested.pi_pending = true;
kvm_make_request(KVM_REQ_EVENT, vcpu);
+ /* the PIR and ON have been set by L1. */
+ if (!kvm_vcpu_trigger_posted_interrupt(vcpu))
+ kvm_vcpu_kick(vcpu);
return 0;
}
return -1;
Patches currently in stable-queue which might be from liran.alon(a)oracle.com are
queue-4.4/kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch
This is a note to let you know that I've just added the patch titled
kernel/async.c: revert "async: simplify lowest_in_progress()"
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kernel-async.c-revert-async-simplify-lowest_in_progress.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4f7e988e63e336827f4150de48163bed05d653bd Mon Sep 17 00:00:00 2001
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Date: Tue, 6 Feb 2018 15:37:55 -0800
Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
commit 4f7e988e63e336827f4150de48163bed05d653bd upstream.
This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()")
which was simply wrong: In the case where domain is NULL, we now use the
wrong offsetof() in the list_first_entry macro, so we don't actually
fetch the ->cookie value, but rather the eight bytes located
sizeof(struct list_head) further into the struct async_entry.
On 64 bit, that's the data member, while on 32 bit, that's a u64 built
from func and data in some order.
I think the bug happens to be harmless in practice: It obviously only
affects callers which pass a NULL domain, and AFAICT the only such
caller is
async_synchronize_full() ->
async_synchronize_full_domain(NULL) ->
async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
the async_global_pending list to be empty - but it would break if
somebody happened to pass (void*)-1 as the data element to
async_schedule, and of course also if somebody ever does a
async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
Maybe the "harmless in practice" means this isn't -stable material. But
I'm not completely confident my quick git grep'ing is enough, and there
might be affected code in one of the earlier kernels that has since been
removed, so I'll leave the decision to the stable guys.
Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk
Fixes: 92266d6ef60c "async: simplify lowest_in_progress()"
Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Acked-by: Tejun Heo <tj(a)kernel.org>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: Adam Wallis <awallis(a)codeaurora.org>
Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/async.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -84,20 +84,24 @@ static atomic_t entry_count;
static async_cookie_t lowest_in_progress(struct async_domain *domain)
{
- struct list_head *pending;
+ struct async_entry *first = NULL;
async_cookie_t ret = ASYNC_COOKIE_MAX;
unsigned long flags;
spin_lock_irqsave(&async_lock, flags);
- if (domain)
- pending = &domain->pending;
- else
- pending = &async_global_pending;
+ if (domain) {
+ if (!list_empty(&domain->pending))
+ first = list_first_entry(&domain->pending,
+ struct async_entry, domain_list);
+ } else {
+ if (!list_empty(&async_global_pending))
+ first = list_first_entry(&async_global_pending,
+ struct async_entry, global_list);
+ }
- if (!list_empty(pending))
- ret = list_first_entry(pending, struct async_entry,
- domain_list)->cookie;
+ if (first)
+ ret = first->cookie;
spin_unlock_irqrestore(&async_lock, flags);
return ret;
Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are
queue-4.4/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
This is a note to let you know that I've just added the patch titled
HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From edfc3722cfef4217c7fe92b272cbe0288ba1ff57 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 17 Jan 2018 21:05:55 +0100
Subject: HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working
From: Hans de Goede <hdegoede(a)redhat.com>
commit edfc3722cfef4217c7fe92b272cbe0288ba1ff57 upstream.
The Toshiba Click Mini uses an i2c attached keyboard/touchpad combo
(single i2c_hid device for both) which has a vid:pid of 04F3:0401,
which is also used by a bunch of Elan touchpads which are handled by the
drivers/input/mouse/elan_i2c driver, but that driver deals with pure
touchpads and does not work for a combo device such as the one on the
Toshiba Click Mini.
The combo on the Mini has an ACPI id of ELAN0800, which is not claimed
by the elan_i2c driver, so check for that and if it is found do not ignore
the device. This fixes the keyboard/touchpad combo on the Mini not working
(although with the touchpad in mouse emulation mode).
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-core.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2308,7 +2308,6 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) },
- { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
@@ -2578,6 +2577,17 @@ bool hid_ignore(struct hid_device *hdev)
strncmp(hdev->name, "www.masterkit.ru MA901", 22) == 0)
return true;
break;
+ case USB_VENDOR_ID_ELAN:
+ /*
+ * Many Elan devices have a product id of 0x0401 and are handled
+ * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev
+ * is not (and cannot be) handled by that driver ->
+ * Ignore all 0x0401 devs except for the ELAN0800 dev.
+ */
+ if (hdev->product == 0x0401 &&
+ strncmp(hdev->name, "ELAN0800", 8) != 0)
+ return true;
+ break;
}
if (hdev->type == HID_TYPE_USBMOUSE &&
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.4/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.4/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
EDAC, octeon: Fix an uninitialized variable warning
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
edac-octeon-fix-an-uninitialized-variable-warning.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 544e92581a2ac44607d7cc602c6b54d18656f56d Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Mon, 13 Nov 2017 16:12:06 +0000
Subject: EDAC, octeon: Fix an uninitialized variable warning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: James Hogan <jhogan(a)kernel.org>
commit 544e92581a2ac44607d7cc602c6b54d18656f56d upstream.
Fix an uninitialized variable warning in the Octeon EDAC driver, as seen
in MIPS cavium_octeon_defconfig builds since v4.14 with Codescape GNU
Tools 2016.05-03:
drivers/edac/octeon_edac-lmc.c In function ‘octeon_lmc_edac_poll_o2’:
drivers/edac/octeon_edac-lmc.c:87:24: warning: ‘((long unsigned int*)&int_reg)[1]’ may \
be used uninitialized in this function [-Wmaybe-uninitialized]
if (int_reg.s.sec_err || int_reg.s.ded_err) {
^
Iinitialise the whole int_reg variable to zero before the conditional
assignments in the error injection case.
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Acked-by: David Daney <david.daney(a)cavium.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Cc: linux-mips(a)linux-mips.org
Fixes: 1bc021e81565 ("EDAC: Octeon: Add error injection support")
Link: http://lkml.kernel.org/r/20171113161206.20990-1-james.hogan@mips.com
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/octeon_edac-lmc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/octeon_edac-lmc.c
+++ b/drivers/edac/octeon_edac-lmc.c
@@ -79,6 +79,7 @@ static void octeon_lmc_edac_poll_o2(stru
if (!pvt->inject)
int_reg.u64 = cvmx_read_csr(CVMX_LMCX_INT(mci->mc_idx));
else {
+ int_reg.u64 = 0;
if (pvt->error_type == 1)
int_reg.s.sec_err = 1;
if (pvt->error_type == 2)
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.4/edac-octeon-fix-an-uninitialized-variable-warning.patch
This is a note to let you know that I've just added the patch titled
crypto: caam - fix endless loop when DECO acquire fails
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Horia=20Geant=C4=83?= <horia.geanta(a)nxp.com>
Date: Mon, 5 Feb 2018 11:15:52 +0200
Subject: crypto: caam - fix endless loop when DECO acquire fails
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Horia Geantă <horia.geanta(a)nxp.com>
commit 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 upstream.
In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails
with -ENODEV, caam_probe() enters an endless loop:
run_descriptor_deco0
ret -ENODEV
-> instantiate_rng
-ENODEV, overwritten by -EAGAIN
ret -EAGAIN
-> caam_probe
-EAGAIN results in endless loop
It turns out the error path in instantiate_rng() is incorrect,
the checks are done in the wrong order.
Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles")
Reported-by: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Suggested-by: Auer Lukas <lukas.auer(a)aisec.fraunhofer.de>
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/caam/ctrl.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -224,12 +224,16 @@ static int instantiate_rng(struct device
* without any error (HW optimizations for later
* CAAM eras), then try again.
*/
+ if (ret)
+ break;
+
rdsta_val = rd_reg32(&ctrl->r4tst[0].rdsta) & RDSTA_IFMASK;
if ((status && status != JRSTA_SSRC_JUMP_HALT_CC) ||
- !(rdsta_val & (1 << sh_idx)))
+ !(rdsta_val & (1 << sh_idx))) {
ret = -EAGAIN;
- if (ret)
break;
+ }
+
dev_info(ctrldev, "Instantiated RNG4 SH%d\n", sh_idx);
/* Clear the contents before recreating the descriptor */
memset(desc, 0x00, CAAM_CMD_SZ * 7);
Patches currently in stable-queue which might be from horia.geanta(a)nxp.com are
queue-4.4/crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
queue-4.4/crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 61f5acea8737d9b717fcc22bb6679924f3c82b98 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Mon, 8 Jan 2018 10:44:16 +0100
Subject: Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Hans de Goede <hdegoede(a)redhat.com>
commit 61f5acea8737d9b717fcc22bb6679924f3c82b98 upstream.
Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
has several issues (see the original commit message). An added advantage
of moving over to the USB-core reset-resume handling is that it also
disables autosuspend for these devices, which is similarly broken on these.
But there are 2 issues with this approach:
1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek
devices.
2) Sofar only 2 of the 10 QCA devices known to the btusb code have been
added to usb/core/quirks.c and if we fix the Realtek case the same way
we need to add an additional 14 entries. So in essence we need to
duplicate a large part of the usb_device_id table in btusb.c in
usb/core/quirks.c and manually keep them in sync.
This commit instead restores setting a reset-resume quirk for QCA devices
in the btusb.c code, avoiding the duplicate usb_device_id table problem.
This commit avoids the problems with the original DIY BTUSB_RESET_RESUME
code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the
usb_device.
This commit also moves the BTUSB_REALTEK case over to directly setting the
USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused
BTUSB_RESET_RESUME code.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Fixes: 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
Cc: Leif Liddy <leif.linux(a)gmail.com>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Daniel Drake <drake(a)endlessm.com>
Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -23,6 +23,7 @@
#include <linux/module.h>
#include <linux/usb.h>
+#include <linux/usb/quirks.h>
#include <linux/firmware.h>
#include <asm/unaligned.h>
@@ -360,8 +361,8 @@ static const struct usb_device_id blackl
#define BTUSB_FIRMWARE_LOADED 7
#define BTUSB_FIRMWARE_FAILED 8
#define BTUSB_BOOTING 9
-#define BTUSB_RESET_RESUME 10
-#define BTUSB_DIAG_RUNNING 11
+#define BTUSB_DIAG_RUNNING 10
+#define BTUSB_OOB_WAKE_ENABLED 11
struct btusb_data {
struct hci_dev *hdev;
@@ -2969,6 +2970,12 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
+
+ /* QCA Rome devices lose their updated firmware over suspend,
+ * but the USB hub doesn't notice any status change.
+ * explicitly request a device reset on resume.
+ */
+ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
@@ -2979,7 +2986,7 @@ static int btusb_probe(struct usb_interf
* but the USB hub doesn't notice any status change.
* Explicitly request a device reset on resume.
*/
- set_bit(BTUSB_RESET_RESUME, &data->flags);
+ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
}
#endif
@@ -3136,14 +3143,6 @@ static int btusb_suspend(struct usb_inte
btusb_stop_traffic(data);
usb_kill_anchored_urbs(&data->tx_anchor);
- /* Optionally request a device reset on resume, but only when
- * wakeups are disabled. If wakeups are enabled we assume the
- * device will stay powered up throughout suspend.
- */
- if (test_bit(BTUSB_RESET_RESUME, &data->flags) &&
- !device_may_wakeup(&data->udev->dev))
- data->udev->reset_resume = 1;
-
return 0;
}
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.4/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.4/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btsdio: Do not bind to non-removable BCM43341
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b4cdaba274247c9c841c6a682c08fa91fb3aa549 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 29 Nov 2017 20:29:07 +0100
Subject: Bluetooth: btsdio: Do not bind to non-removable BCM43341
From: Hans de Goede <hdegoede(a)redhat.com>
commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 upstream.
BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
use an UART connection for bluetooth. But they also advertise btsdio
support on their 3th sdio function, this causes 2 problems:
1) A non functioning BT HCI getting registered
2) Since the btsdio driver does not have suspend/resume callbacks,
mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
to react as if the SDIO-card is removed and since the slot is
marked as non-removable it will never get detected as inserted again.
Which results in wifi no longer working after a suspend/resume.
This commit fixes both by making btsdio ignore BCM43341 devices
when connected to a slot which is marked non-removable.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btsdio.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -31,6 +31,7 @@
#include <linux/errno.h>
#include <linux/skbuff.h>
+#include <linux/mmc/host.h>
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
@@ -291,6 +292,14 @@ static int btsdio_probe(struct sdio_func
tuple = tuple->next;
}
+ /* BCM43341 devices soldered onto the PCB (non-removable) use an
+ * uart connection for bluetooth, ignore the BT SDIO interface.
+ */
+ if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
+ func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
+ !mmc_card_is_removable(func->card->host))
+ return -ENODEV;
+
data = devm_kzalloc(&func->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.4/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.4/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 6 Feb 2018 17:56:06 +0000
Subject: arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream.
KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.
Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.
Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kvm/handle_exit.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -45,7 +45,7 @@ static int handle_hvc(struct kvm_vcpu *v
ret = kvm_psci_call(vcpu);
if (ret < 0) {
- kvm_inject_undefined(vcpu);
+ vcpu_set_reg(vcpu, 0, ~0UL);
return 1;
}
@@ -54,7 +54,16 @@ static int handle_hvc(struct kvm_vcpu *v
static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
- kvm_inject_undefined(vcpu);
+ /*
+ * "If an SMC instruction executed at Non-secure EL1 is
+ * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a
+ * Trap exception, not a Secure Monitor Call exception [...]"
+ *
+ * We need to advance the PC after the trap, as it would
+ * otherwise return to the same address...
+ */
+ vcpu_set_reg(vcpu, 0, ~0UL);
+ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
return 1;
}
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.4/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
This is a note to let you know that I've just added the patch titled
alpha: fix crash if pthread_create races with signal delivery
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 21ffceda1c8b3807615c40d440d7815e0c85d366 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 14:01:34 -0500
Subject: alpha: fix crash if pthread_create races with signal delivery
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream.
On alpha, a process will crash if it attempts to start a thread and a
signal is delivered at the same time. The crash can be reproduced with
this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
The reason for the crash is this:
* we call the clone syscall
* we go to the function copy_process
* copy process calls copy_thread_tls, it is a wrapper around copy_thread
* copy_thread sets the tls pointer: childti->pcb.unique = regs->r20
* copy_thread sets regs->r20 to zero
* we go back to copy_process
* copy process checks "if (signal_pending(current))" and returns
-ERESTARTNOINTR
* the clone syscall is restarted, but this time, regs->r20 is zero, so
the new thread is created with zero tls pointer
* the new thread crashes in start_thread when attempting to access tls
The comment in the code says that setting the register r20 is some
compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so
we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug
by zeroing regs->r20 only if CLONE_SETTLS is not set.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -273,12 +273,13 @@ copy_thread(unsigned long clone_flags, u
application calling fork. */
if (clone_flags & CLONE_SETTLS)
childti->pcb.unique = regs->r20;
+ else
+ regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */
childti->pcb.usp = usp ?: rdusp();
*childregs = *regs;
childregs->r0 = 0;
childregs->r19 = 0;
childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */
- regs->r20 = 0;
stack = ((struct switch_stack *) regs) - 1;
*childstack = *stack;
childstack->r26 = (unsigned long) ret_from_fork;
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.4/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.4/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
alpha: fix reboot on Avanti platform
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alpha-fix-reboot-on-avanti-platform.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 55fc633c41a08ce9244ff5f528f420b16b1e04d6 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 13:59:54 -0500
Subject: alpha: fix reboot on Avanti platform
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream.
We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get
machine check exception when attempting to reboot the machine.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/pci_impl.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/pci_impl.h
+++ b/arch/alpha/kernel/pci_impl.h
@@ -143,7 +143,8 @@ struct pci_iommu_arena
};
#if defined(CONFIG_ALPHA_SRM) && \
- (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA))
+ (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA) || \
+ defined(CONFIG_ALPHA_AVANTI))
# define NEED_SRM_SAVE_RESTORE
#else
# undef NEED_SRM_SAVE_RESTORE
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.4/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.4/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
xtensa: fix futex_atomic_cmpxchg_inatomic
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ca47480921587ae30417dd234a9f79af188e3666 Mon Sep 17 00:00:00 2001
From: Max Filippov <jcmvbkbc(a)gmail.com>
Date: Fri, 5 Jan 2018 14:27:58 -0800
Subject: xtensa: fix futex_atomic_cmpxchg_inatomic
From: Max Filippov <jcmvbkbc(a)gmail.com>
commit ca47480921587ae30417dd234a9f79af188e3666 upstream.
Return 0 if the operation was successful, not the userspace memory
value. Check that userspace value equals passed oldval, not itself.
Don't update *uval if the value wasn't read from userspace memory.
This fixes process hang due to infinite loop in futex_lock_pi.
It also fixes a bunch of glibc tests nptl/tst-mutexpi*.
Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/xtensa/include/asm/futex.h | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
--- a/arch/xtensa/include/asm/futex.h
+++ b/arch/xtensa/include/asm/futex.h
@@ -92,7 +92,6 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
u32 oldval, u32 newval)
{
int ret = 0;
- u32 prev;
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
@@ -103,26 +102,24 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
__asm__ __volatile__ (
" # futex_atomic_cmpxchg_inatomic\n"
- "1: l32i %1, %3, 0\n"
- " mov %0, %5\n"
- " wsr %1, scompare1\n"
- "2: s32c1i %0, %3, 0\n"
- "3:\n"
+ " wsr %5, scompare1\n"
+ "1: s32c1i %1, %4, 0\n"
+ " s32i %1, %6, 0\n"
+ "2:\n"
" .section .fixup,\"ax\"\n"
" .align 4\n"
- "4: .long 3b\n"
- "5: l32r %1, 4b\n"
- " movi %0, %6\n"
+ "3: .long 2b\n"
+ "4: l32r %1, 3b\n"
+ " movi %0, %7\n"
" jx %1\n"
" .previous\n"
" .section __ex_table,\"a\"\n"
- " .long 1b,5b,2b,5b\n"
+ " .long 1b,4b\n"
" .previous\n"
- : "+r" (ret), "=&r" (prev), "+m" (*uaddr)
- : "r" (uaddr), "r" (oldval), "r" (newval), "I" (-EFAULT)
+ : "+r" (ret), "+r" (newval), "+m" (*uaddr), "+m" (*uval)
+ : "r" (uaddr), "r" (oldval), "r" (uval), "I" (-EFAULT)
: "memory");
- *uval = prev;
return ret;
}
Patches currently in stable-queue which might be from jcmvbkbc(a)gmail.com are
queue-4.15/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
This is a note to let you know that I've just added the patch titled
watchdog: imx2_wdt: restore previous timeout after suspend+resume
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0be267255cef64e1c58475baa7b25568355a3816 Mon Sep 17 00:00:00 2001
From: Martin Kaiser <martin(a)kaiser.cx>
Date: Mon, 1 Jan 2018 18:26:47 +0100
Subject: watchdog: imx2_wdt: restore previous timeout after suspend+resume
From: Martin Kaiser <martin(a)kaiser.cx>
commit 0be267255cef64e1c58475baa7b25568355a3816 upstream.
When the watchdog device is suspended, its timeout is set to the maximum
value. During resume, the previously set timeout should be restored.
This does not work at the moment.
The suspend function calls
imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
and resume reverts this by calling
imx2_wdt_set_timeout(wdog, wdog->timeout);
However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore,
wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume
function.
Fix this by adding a new function __imx2_wdt_set_timeout() which
only updates the hardware settings. imx2_wdt_set_timeout() now calls
__imx2_wdt_set_timeout() and then saves the new timeout to
wdog->timeout.
During suspend, we call __imx2_wdt_set_timeout() directly so that
wdog->timeout won't be updated and we can restore the previous value
during resume. This approach makes wdog->timeout different from the
actual setting in the hardware which is usually not a good thing.
However, the two differ only while we're suspended and no kernel code is
running, so it should be ok in this case.
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/watchdog/imx2_wdt.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -169,15 +169,21 @@ static int imx2_wdt_ping(struct watchdog
return 0;
}
-static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
- unsigned int new_timeout)
+static void __imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
{
struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
- wdog->timeout = new_timeout;
-
regmap_update_bits(wdev->regmap, IMX2_WDT_WCR, IMX2_WDT_WCR_WT,
WDOG_SEC_TO_COUNT(new_timeout));
+}
+
+static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ __imx2_wdt_set_timeout(wdog, new_timeout);
+
+ wdog->timeout = new_timeout;
return 0;
}
@@ -371,7 +377,11 @@ static int imx2_wdt_suspend(struct devic
/* The watchdog IP block is running */
if (imx2_wdt_is_running(wdev)) {
- imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
+ /*
+ * Don't update wdog->timeout, we'll restore the current value
+ * during resume.
+ */
+ __imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
imx2_wdt_ping(wdog);
}
Patches currently in stable-queue which might be from martin(a)kaiser.cx are
queue-4.15/watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
signal/sh: Ensure si_signo is initialized in do_divide_error
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Mon, 24 Jul 2017 17:30:30 -0500
Subject: signal/sh: Ensure si_signo is initialized in do_divide_error
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream.
Set si_signo.
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Rich Felker <dalias(a)libc.org>
Cc: Paul Mundt <lethal(a)linux-sh.org>
Cc: linux-sh(a)vger.kernel.org
Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.")
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/kernel/traps_32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/sh/kernel/traps_32.c
+++ b/arch/sh/kernel/traps_32.c
@@ -609,7 +609,8 @@ asmlinkage void do_divide_error(unsigned
break;
}
- force_sig_info(SIGFPE, &info, current);
+ info.si_signo = SIGFPE;
+ force_sig_info(info.si_signo, &info, current);
}
#endif
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.15/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.15/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
signal/openrisc: Fix do_unaligned_access to send the proper signal
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 500d58300571b6602341b041f97c082a461ef994 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 04:16:47 -0500
Subject: signal/openrisc: Fix do_unaligned_access to send the proper signal
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 500d58300571b6602341b041f97c082a461ef994 upstream.
While reviewing the signal sending on openrisc the do_unaligned_access
function stood out because it is obviously wrong. A comment about an
si_code set above when actually si_code is never set. Leading to a
random si_code being sent to userspace in the event of an unaligned
access.
Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
si_code to send for an unaligned access. That is what other
architectures do and what is required by posix.
Given that do_unaligned_access is broken in a way that no one can be
relying on it on openrisc fix the code to just do the right thing.
Fixes: 769a8a96229e ("OpenRISC: Traps")
Cc: Jonas Bonn <jonas(a)southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi>
Cc: Stafford Horne <shorne(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: openrisc(a)lists.librecores.org
Acked-by: Stafford Horne <shorne(a)gmail.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/openrisc/kernel/traps.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -266,12 +266,12 @@ asmlinkage void do_unaligned_access(stru
siginfo_t info;
if (user_mode(regs)) {
- /* Send a SIGSEGV */
- info.si_signo = SIGSEGV;
+ /* Send a SIGBUS */
+ info.si_signo = SIGBUS;
info.si_errno = 0;
- /* info.si_code has been set above */
- info.si_addr = (void *)address;
- force_sig_info(SIGSEGV, &info, current);
+ info.si_code = BUS_ADRALN;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGBUS, &info, current);
} else {
printk("KERNEL: Unaligned Access 0x%.8lx\n", address);
show_registers(regs);
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.15/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.15/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7d06d5895c159f64c46560dc258e553ad8670fe0 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Wed, 20 Dec 2017 19:00:07 +0800
Subject: Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 7d06d5895c159f64c46560dc258e553ad8670fe0 upstream.
This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56.
This commit causes a regression on some QCA ROME chips. The USB device
reset happens in btusb_open(), hence firmware loading gets interrupted.
Furthermore, this commit stops working after commit
("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to
enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in
btusb_suspend() when it's not a wakeup source.
If we really want to reset the USB device, we need to do it before
btusb_open(). Let's handle it in drivers/usb/core/quirks.c.
Cc: Leif Liddy <leif.linux(a)gmail.com>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Daniel Drake <drake(a)endlessm.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Reviewed-by: Brian Norris <briannorris(a)chromium.org>
Tested-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 6 ------
1 file changed, 6 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3117,12 +3117,6 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
-
- /* QCA Rome devices lose their updated firmware over suspend,
- * but the USB hub doesn't notice any status change.
- * Explicitly request a device reset on resume.
- */
- set_bit(BTUSB_RESET_RESUME, &data->flags);
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.15/revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
queue-4.15/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
pktcdvd: Fix pkt_setup_dev() error path
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pktcdvd-fix-pkt_setup_dev-error-path.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 2 Jan 2018 11:39:47 -0800
Subject: pktcdvd: Fix pkt_setup_dev() error path
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.
Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
modified add_disk() and disk_release() but did not update any of the
error paths that trigger a put_disk() call after disk->queue has been
assigned. That introduced the following behavior in the pktcdvd driver
if pkt_new_dev() fails:
Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]
Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
error path.
Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/pktcdvd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2745,7 +2745,7 @@ static int pkt_setup_dev(dev_t dev, dev_
pd->pkt_dev = MKDEV(pktdev_major, idx);
ret = pkt_new_dev(pd, dev);
if (ret)
- goto out_new_dev;
+ goto out_mem2;
/* inherit events of the host device */
disk->events = pd->bdev->bd_disk->events;
@@ -2763,8 +2763,6 @@ static int pkt_setup_dev(dev_t dev, dev_
mutex_unlock(&ctl_mutex);
return 0;
-out_new_dev:
- blk_cleanup_queue(disk->queue);
out_mem2:
put_disk(disk);
out_mem:
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.15/pktcdvd-fix-pkt_setup_dev-error-path.patch
queue-4.15/pktcdvd-fix-a-recently-introduced-null-pointer-dereference.patch