This is a note to let you know that I've just added the patch titled
rtc: m41t80: fix SQW dividers override when setting a date
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:
rtc-m41t80-fix-sqw-dividers-override-when-setting-a-date.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Gary Bisson <gary.bisson(a)boundarydevices.com>
Date: Tue, 25 Apr 2017 16:45:15 +0200
Subject: rtc: m41t80: fix SQW dividers override when setting a date
From: Gary Bisson <gary.bisson(a)boundarydevices.com>
[ Upstream commit 0f546b058b86ea2f661cc7a6e931cee5a29959ef ]
This patch is only relevant for RTC with the SQ_ALT feature which
means the clock output frequency divider is stored in the weekday
register.
Current implementation discards the previous dividers value and clear
them as soon as the time is set.
Signed-off-by: Gary Bisson <gary.bisson(a)boundarydevices.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-m41t80.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/rtc/rtc-m41t80.c
+++ b/drivers/rtc/rtc-m41t80.c
@@ -168,6 +168,7 @@ static int m41t80_get_datetime(struct i2
/* Sets the given date and time to the real time clock. */
static int m41t80_set_datetime(struct i2c_client *client, struct rtc_time *tm)
{
+ struct m41t80_data *clientdata = i2c_get_clientdata(client);
unsigned char buf[8];
int err, flags;
@@ -183,6 +184,17 @@ static int m41t80_set_datetime(struct i2
buf[M41T80_REG_YEAR] = bin2bcd(tm->tm_year - 100);
buf[M41T80_REG_WDAY] = tm->tm_wday;
+ /* If the square wave output is controlled in the weekday register */
+ if (clientdata->features & M41T80_FEATURE_SQ_ALT) {
+ int val;
+
+ val = i2c_smbus_read_byte_data(client, M41T80_REG_WDAY);
+ if (val < 0)
+ return val;
+
+ buf[M41T80_REG_WDAY] |= (val & 0xf0);
+ }
+
err = i2c_smbus_write_i2c_block_data(client, M41T80_REG_SSEC,
sizeof(buf), buf);
if (err < 0) {
Patches currently in stable-queue which might be from gary.bisson(a)boundarydevices.com are
queue-4.9/rtc-m41t80-fix-sqw-dividers-override-when-setting-a-date.patch
This is a note to let you know that I've just added the patch titled
rt2x00: do not pause queue unconditionally on 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:
rt2x00-do-not-pause-queue-unconditionally-on-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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Stanislaw Gruszka <sgruszka(a)redhat.com>
Date: Tue, 19 Dec 2017 12:33:56 +0100
Subject: rt2x00: do not pause queue unconditionally on error path
From: Stanislaw Gruszka <sgruszka(a)redhat.com>
[ Upstream commit 6dd80efd75ce7c2dbd9f117cf585ee2b33a42ee1 ]
Pausing queue without checking threshold is racy with txdone path.
Moreover we do not need pause queue on any error, but only if queue
is full - in case when we send RTS frame ( other cases of almost full
queue are already handled in rt2x00queue_write_tx_frame() ).
Patch fixes of theoretically possible problem of pausing empty
queue.
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
Tested-by: Enrico Mioso <mrkiko.rs(a)gmail.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
@@ -142,15 +142,25 @@ void rt2x00mac_tx(struct ieee80211_hw *h
if (!rt2x00dev->ops->hw->set_rts_threshold &&
(tx_info->control.rates[0].flags & (IEEE80211_TX_RC_USE_RTS_CTS |
IEEE80211_TX_RC_USE_CTS_PROTECT))) {
- if (rt2x00queue_available(queue) <= 1)
- goto exit_fail;
+ if (rt2x00queue_available(queue) <= 1) {
+ /*
+ * Recheck for full queue under lock to avoid race
+ * conditions with rt2x00lib_txdone().
+ */
+ spin_lock(&queue->tx_lock);
+ if (rt2x00queue_threshold(queue))
+ rt2x00queue_pause_queue(queue);
+ spin_unlock(&queue->tx_lock);
+
+ goto exit_free_skb;
+ }
if (rt2x00mac_tx_rts_cts(rt2x00dev, queue, skb))
- goto exit_fail;
+ goto exit_free_skb;
}
if (unlikely(rt2x00queue_write_tx_frame(queue, skb, control->sta, false)))
- goto exit_fail;
+ goto exit_free_skb;
/*
* Pausing queue has to be serialized with rt2x00lib_txdone(). Note
@@ -164,10 +174,6 @@ void rt2x00mac_tx(struct ieee80211_hw *h
return;
- exit_fail:
- spin_lock(&queue->tx_lock);
- rt2x00queue_pause_queue(queue);
- spin_unlock(&queue->tx_lock);
exit_free_skb:
ieee80211_free_txskb(hw, skb);
}
Patches currently in stable-queue which might be from sgruszka(a)redhat.com are
queue-4.9/rt2x00-do-not-pause-queue-unconditionally-on-error-path.patch
This is a note to let you know that I've just added the patch titled
rds; Reset rs->rs_bound_addr in rds_add_bound() failure 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:
rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Date: Fri, 22 Dec 2017 09:38:59 -0800
Subject: rds; Reset rs->rs_bound_addr in rds_add_bound() failure path
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
[ Upstream commit 7ae0c649c47f1c5d2db8cee6dd75855970af1669 ]
If the rds_sock is not added to the bind_hash_table, we must
reset rs_bound_addr so that rds_remove_bound will not trip on
this rds_sock.
rds_add_bound() does a rds_sock_put() in this failure path, so
failing to reset rs_bound_addr will result in a socket refcount
bug, and will trigger a WARN_ON with the stack shown below when
the application subsequently tries to close the PF_RDS socket.
WARNING: CPU: 20 PID: 19499 at net/rds/af_rds.c:496 \
rds_sock_destruct+0x15/0x30 [rds]
:
__sk_destruct+0x21/0x190
rds_remove_bound.part.13+0xb6/0x140 [rds]
rds_release+0x71/0x120 [rds]
sock_release+0x1a/0x70
sock_close+0xe/0x20
__fput+0xd5/0x210
task_work_run+0x82/0xa0
do_exit+0x2ce/0xb30
? syscall_trace_enter+0x1cc/0x2b0
do_group_exit+0x39/0xa0
SyS_exit_group+0x10/0x10
do_syscall_64+0x61/0x1a0
Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/rds/bind.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -114,6 +114,7 @@ static int rds_add_bound(struct rds_sock
rs, &addr, (int)ntohs(*port));
break;
} else {
+ rs->rs_bound_addr = 0;
rds_sock_put(rs);
ret = -ENOMEM;
break;
Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are
queue-4.9/rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch
This is a note to let you know that I've just added the patch titled
RDMA/iw_cxgb4: Avoid touch after free error in ARP failure handlers
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:
rdma-iw_cxgb4-avoid-touch-after-free-error-in-arp-failure-handlers.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Raju Rangoju <rajur(a)chelsio.com>
Date: Mon, 15 May 2017 06:40:39 +0000
Subject: RDMA/iw_cxgb4: Avoid touch after free error in ARP failure handlers
From: Raju Rangoju <rajur(a)chelsio.com>
[ Upstream commit 1dad0ebeea1cd890b8892523f736916e245b0aef ]
The patch 761e19a504af (RDMA/iw_cxgb4: Handle return value of
c4iw_ofld_send() in abort_arp_failure()) from May 6, 2016
leads to the following static checker warning:
drivers/infiniband/hw/cxgb4/cm.c:575 abort_arp_failure()
warn: passing freed memory 'skb'
Also fixes skb leak when l2t resolution fails
Fixes: 761e19a504afa55 (RDMA/iw_cxgb4: Handle return value of
c4iw_ofld_send() in abort_arp_failure())
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Raju Rangoju <rajur(a)chelsio.com>
Reviewed-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/cm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -488,6 +488,7 @@ static int _put_ep_safe(struct c4iw_dev
ep = *((struct c4iw_ep **)(skb->cb + 2 * sizeof(void *)));
release_ep_resources(ep);
+ kfree_skb(skb);
return 0;
}
@@ -498,6 +499,7 @@ static int _put_pass_ep_safe(struct c4iw
ep = *((struct c4iw_ep **)(skb->cb + 2 * sizeof(void *)));
c4iw_put_ep(&ep->parent_ep->com);
release_ep_resources(ep);
+ kfree_skb(skb);
return 0;
}
@@ -569,11 +571,13 @@ static void abort_arp_failure(void *hand
PDBG("%s rdev %p\n", __func__, rdev);
req->cmd = CPL_ABORT_NO_RST;
+ skb_get(skb);
ret = c4iw_ofld_send(rdev, skb);
if (ret) {
__state_set(&ep->com, DEAD);
queue_arp_failure_cpl(ep, skb, FAKE_CPL_PUT_EP_SAFE);
- }
+ } else
+ kfree_skb(skb);
}
static int send_flowc(struct c4iw_ep *ep)
Patches currently in stable-queue which might be from rajur(a)chelsio.com are
queue-4.9/rdma-iw_cxgb4-avoid-touch-after-free-error-in-arp-failure-handlers.patch
This is a note to let you know that I've just added the patch titled
ray_cs: Avoid reading past end of buffer
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:
ray_cs-avoid-reading-past-end-of-buffer.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Kees Cook <keescook(a)chromium.org>
Date: Fri, 5 May 2017 15:38:41 -0700
Subject: ray_cs: Avoid reading past end of buffer
From: Kees Cook <keescook(a)chromium.org>
[ Upstream commit e48d661eb13f2f83861428f001c567fdb3f317e8 ]
Using memcpy() from a buffer that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. In this case, the source was made longer, since it did not
match the destination structure size. Additionally removes a needless cast.
This was found with the future CONFIG_FORTIFY_SOURCE feature.
Cc: Daniel Micay <danielmicay(a)gmail.com>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ray_cs.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -247,7 +247,10 @@ static const UCHAR b4_default_startup_pa
0x04, 0x08, /* Noise gain, limit offset */
0x28, 0x28, /* det rssi, med busy offsets */
7, /* det sync thresh */
- 0, 2, 2 /* test mode, min, max */
+ 0, 2, 2, /* test mode, min, max */
+ 0, /* rx/tx delay */
+ 0, 0, 0, 0, 0, 0, /* current BSS id */
+ 0 /* hop set */
};
/*===========================================================================*/
@@ -598,7 +601,7 @@ static void init_startup_params(ray_dev_
* a_beacon_period = hops a_beacon_period = KuS
*//* 64ms = 010000 */
if (local->fw_ver == 0x55) {
- memcpy((UCHAR *) &local->sparm.b4, b4_default_startup_parms,
+ memcpy(&local->sparm.b4, b4_default_startup_parms,
sizeof(struct b4_startup_params));
/* Translate sane kus input values to old build 4/5 format */
/* i = hop time in uS truncated to 3 bytes */
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.9/qlge-avoid-reading-past-end-of-buffer.patch
queue-4.9/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch
queue-4.9/x86-mm-kaslr-use-the-_asm_mul-macro-for-multiplication-to-work-around-clang-incompatibility.patch
queue-4.9/ray_cs-avoid-reading-past-end-of-buffer.patch
queue-4.9/x86-boot-declare-error-as-noreturn.patch
queue-4.9/selftests-kselftest_harness-fix-compile-warning.patch
queue-4.9/bna-avoid-reading-past-end-of-buffer.patch
This is a note to let you know that I've just added the patch titled
RDMA/hfi1: fix array termination by appending NULL to attr array
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:
rdma-hfi1-fix-array-termination-by-appending-null-to-attr-array.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: "Steven L. Roberts" <robers97(a)gmail.com>
Date: Wed, 10 May 2017 10:54:12 -0500
Subject: RDMA/hfi1: fix array termination by appending NULL to attr array
From: "Steven L. Roberts" <robers97(a)gmail.com>
[ Upstream commit c4dd4b69f55abcc8dd079f8de55d9d8c2ddbefce ]
This fixes a kernel panic when loading the hfi driver as a dynamic module.
Signed-off-by: Steven L Roberts <robers97(a)gmail.com>
Reviewed-by: Leon Romanovsky <leon(a)kernel.org>
Acked-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/hw/hfi1/sysfs.c
+++ b/drivers/infiniband/hw/hfi1/sysfs.c
@@ -196,7 +196,8 @@ static const struct sysfs_ops port_cc_sy
};
static struct attribute *port_cc_default_attributes[] = {
- &cc_prescan_attr.attr
+ &cc_prescan_attr.attr,
+ NULL
};
static struct kobj_type port_cc_ktype = {
Patches currently in stable-queue which might be from robers97(a)gmail.com are
queue-4.9/rdma-hfi1-fix-array-termination-by-appending-null-to-attr-array.patch
This is a note to let you know that I've just added the patch titled
qlge: Avoid reading past end of buffer
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:
qlge-avoid-reading-past-end-of-buffer.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Kees Cook <keescook(a)chromium.org>
Date: Fri, 5 May 2017 15:34:34 -0700
Subject: qlge: Avoid reading past end of buffer
From: Kees Cook <keescook(a)chromium.org>
[ Upstream commit df5303a8aa9a0a6934f4cea7427f1edf771f21c2 ]
Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. Instead, use strncpy() which will fill the trailing bytes
with zeros.
This was found with the future CONFIG_FORTIFY_SOURCE feature.
Cc: Daniel Micay <danielmicay(a)gmail.com>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/qlogic/qlge/qlge_dbg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
@@ -765,7 +765,7 @@ int ql_core_dump(struct ql_adapter *qdev
sizeof(struct mpi_coredump_global_header);
mpi_coredump->mpi_global_header.imageSize =
sizeof(struct ql_mpi_coredump);
- memcpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump",
+ strncpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump",
sizeof(mpi_coredump->mpi_global_header.idString));
/* Get generic NIC reg dump */
@@ -1255,7 +1255,7 @@ static void ql_gen_reg_dump(struct ql_ad
sizeof(struct mpi_coredump_global_header);
mpi_coredump->mpi_global_header.imageSize =
sizeof(struct ql_reg_dump);
- memcpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump",
+ strncpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump",
sizeof(mpi_coredump->mpi_global_header.idString));
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.9/qlge-avoid-reading-past-end-of-buffer.patch
queue-4.9/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch
queue-4.9/x86-mm-kaslr-use-the-_asm_mul-macro-for-multiplication-to-work-around-clang-incompatibility.patch
queue-4.9/ray_cs-avoid-reading-past-end-of-buffer.patch
queue-4.9/x86-boot-declare-error-as-noreturn.patch
queue-4.9/selftests-kselftest_harness-fix-compile-warning.patch
queue-4.9/bna-avoid-reading-past-end-of-buffer.patch
This is a note to let you know that I've just added the patch titled
qlcnic: Fix a sleep-in-atomic bug in qlcnic_82xx_hw_write_wx_2M and qlcnic_82xx_hw_read_wx_2M
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:
qlcnic-fix-a-sleep-in-atomic-bug-in-qlcnic_82xx_hw_write_wx_2m-and-qlcnic_82xx_hw_read_wx_2m.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Jia-Ju Bai <baijiaju1990(a)163.com>
Date: Thu, 1 Jun 2017 16:18:10 +0800
Subject: qlcnic: Fix a sleep-in-atomic bug in qlcnic_82xx_hw_write_wx_2M and qlcnic_82xx_hw_read_wx_2M
From: Jia-Ju Bai <baijiaju1990(a)163.com>
[ Upstream commit 5ea6d691aac6c93b790f0905e3460d44cc4c449b ]
The driver may sleep under a write spin lock, and the function
call path is:
qlcnic_82xx_hw_write_wx_2M (acquire the lock by write_lock_irqsave)
crb_win_lock
qlcnic_pcie_sem_lock
usleep_range
qlcnic_82xx_hw_read_wx_2M (acquire the lock by write_lock_irqsave)
crb_win_lock
qlcnic_pcie_sem_lock
usleep_range
To fix it, the usleep_range is replaced with udelay.
Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
@@ -341,7 +341,7 @@ qlcnic_pcie_sem_lock(struct qlcnic_adapt
}
return -EIO;
}
- usleep_range(1000, 1500);
+ udelay(1200);
}
if (id_reg)
Patches currently in stable-queue which might be from baijiaju1990(a)163.com are
queue-4.9/misdn-fix-a-sleep-in-atomic-bug.patch
queue-4.9/qlcnic-fix-a-sleep-in-atomic-bug-in-qlcnic_82xx_hw_write_wx_2m-and-qlcnic_82xx_hw_read_wx_2m.patch
This is a note to let you know that I've just added the patch titled
qed: Fix overriding of supported autoneg value.
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:
qed-fix-overriding-of-supported-autoneg-value.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: "sudarsana.kalluru(a)cavium.com" <sudarsana.kalluru(a)cavium.com>
Date: Thu, 4 May 2017 08:15:04 -0700
Subject: qed: Fix overriding of supported autoneg value.
From: "sudarsana.kalluru(a)cavium.com" <sudarsana.kalluru(a)cavium.com>
[ Upstream commit 34f9199ce7b7e5c641b96e928bd60e086bf7f278 ]
Driver currently uses advertised-autoneg value to populate the
supported-autoneg field. When advertised field is updated, user gets
the same value for supported field. Supported-autoneg value need to be
populated from the link capabilities value returned by the MFW.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru(a)cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++
drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++-
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -1628,6 +1628,9 @@ static int qed_hw_get_nvm_info(struct qe
DP_NOTICE(p_hwfn, "Unknown Speed in 0x%08x\n", link_temp);
}
+ p_hwfn->mcp_info->link_capabilities.default_speed_autoneg =
+ link->speed.autoneg;
+
link_temp &= NVM_CFG1_PORT_DRV_FLOW_CONTROL_MASK;
link_temp >>= NVM_CFG1_PORT_DRV_FLOW_CONTROL_OFFSET;
link->pause.autoneg = !!(link_temp &
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1240,7 +1240,7 @@ static void qed_fill_link(struct qed_hwf
/* TODO - at the moment assume supported and advertised speed equal */
if_link->supported_caps = QED_LM_FIBRE_BIT;
- if (params.speed.autoneg)
+ if (link_caps.default_speed_autoneg)
if_link->supported_caps |= QED_LM_Autoneg_BIT;
if (params.pause.autoneg ||
(params.pause.forced_rx && params.pause.forced_tx))
@@ -1250,6 +1250,10 @@ static void qed_fill_link(struct qed_hwf
if_link->supported_caps |= QED_LM_Pause_BIT;
if_link->advertised_caps = if_link->supported_caps;
+ if (params.speed.autoneg)
+ if_link->advertised_caps |= QED_LM_Autoneg_BIT;
+ else
+ if_link->advertised_caps &= ~QED_LM_Autoneg_BIT;
if (params.speed.advertised_speeds &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G)
if_link->advertised_caps |= QED_LM_1000baseT_Half_BIT |
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
@@ -35,6 +35,7 @@ struct qed_mcp_link_params {
struct qed_mcp_link_capabilities {
u32 speed_capabilities;
+ bool default_speed_autoneg;
};
struct qed_mcp_link_state {
Patches currently in stable-queue which might be from sudarsana.kalluru(a)cavium.com are
queue-4.9/qed-fix-overriding-of-supported-autoneg-value.patch
This is a note to let you know that I've just added the patch titled
qed: Correct doorbell configuration for !4Kb pages
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:
qed-correct-doorbell-configuration-for-4kb-pages.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Ram Amrani <Ram.Amrani(a)cavium.com>
Date: Tue, 9 May 2017 15:07:50 +0300
Subject: qed: Correct doorbell configuration for !4Kb pages
From: Ram Amrani <Ram.Amrani(a)cavium.com>
[ Upstream commit a82dadbce47395747824971db08a128130786fdc ]
When configuring the doorbell DPI address, driver aligns the start
address to 4KB [HW-pages] instead of host PAGE_SIZE.
As a result, RoCE applications might receive addresses which are
unaligned to pages [when PAGE_SIZE > 4KB], which is a security risk.
Fixes: 51ff17251c9c ("qed: Add support for RoCE hw init")
Signed-off-by: Ram Amrani <Ram.Amrani(a)cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -850,7 +850,7 @@ qed_hw_init_pf_doorbell_bar(struct qed_h
NULL) +
qed_cxt_get_proto_cid_count(p_hwfn, PROTOCOLID_ETH,
NULL);
- norm_regsize = roundup(QED_PF_DEMS_SIZE * non_pwm_conn, 4096);
+ norm_regsize = roundup(QED_PF_DEMS_SIZE * non_pwm_conn, PAGE_SIZE);
min_addr_reg1 = norm_regsize / 4096;
pwm_regsize = db_bar_size - norm_regsize;
Patches currently in stable-queue which might be from Ram.Amrani(a)cavium.com are
queue-4.9/qed-correct-doorbell-configuration-for-4kb-pages.patch
This is a note to let you know that I've just added the patch titled
[media] pxa_camera: fix module remove codepath for v4l2 clock
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:
pxa_camera-fix-module-remove-codepath-for-v4l2-clock.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Petr Cvek <petr.cvek(a)tul.cz>
Date: Mon, 24 Apr 2017 22:51:58 -0300
Subject: [media] pxa_camera: fix module remove codepath for v4l2 clock
From: Petr Cvek <petr.cvek(a)tul.cz>
[ Upstream commit e3b4d10cc057522353c4a02f2f90dca6a52e006f ]
The conversion from soc_camera omitted a correct handling of the clock
gating for a sensor. When the pxa_camera driver module was removed it
tried to unregister clk, but this caused a similar warning:
WARNING: CPU: 0 PID: 6740 at drivers/media/v4l2-core/v4l2-clk.c:278
v4l2_clk_unregister(): Refusing to unregister ref-counted 0-0030 clock!
The clock was at time still refcounted by the sensor driver. Before
the removing of the pxa_camera the clock must be dropped by the sensor
driver. This should be triggered by v4l2_async_notifier_unregister() call
which removes sensor driver module too, calls unbind() function and then
tries to probe sensor driver again. Inside unbind() we can safely
unregister the v4l2 clock as the sensor driver got removed. The original
v4l2_clk_unregister() should be put inside test as the clock can be
already unregistered from unbind(). If there was not any bound sensor
the clock is still present.
The codepath is practically a copy from the old soc_camera. The bug was
tested with a pxa_camera+ov9640 combination during the conversion
of the ov9640 from the soc_camera.
Signed-off-by: Petr Cvek <petr.cvek(a)tul.cz>
Tested-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/pxa_camera.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -2169,6 +2169,12 @@ static void pxa_camera_sensor_unbind(str
pxa_dma_stop_channels(pcdev);
pxa_camera_destroy_formats(pcdev);
+
+ if (pcdev->mclk_clk) {
+ v4l2_clk_unregister(pcdev->mclk_clk);
+ pcdev->mclk_clk = NULL;
+ }
+
video_unregister_device(&pcdev->vdev);
pcdev->sensor = NULL;
@@ -2495,7 +2501,13 @@ static int pxa_camera_remove(struct plat
dma_release_channel(pcdev->dma_chans[1]);
dma_release_channel(pcdev->dma_chans[2]);
- v4l2_clk_unregister(pcdev->mclk_clk);
+ v4l2_async_notifier_unregister(&pcdev->notifier);
+
+ if (pcdev->mclk_clk) {
+ v4l2_clk_unregister(pcdev->mclk_clk);
+ pcdev->mclk_clk = NULL;
+ }
+
v4l2_device_unregister(&pcdev->v4l2_dev);
dev_info(&pdev->dev, "PXA Camera driver unloaded\n");
Patches currently in stable-queue which might be from petr.cvek(a)tul.cz are
queue-4.9/pxa_camera-fix-module-remove-codepath-for-v4l2-clock.patch
This is a note to let you know that I've just added the patch titled
powerpc/spufs: Fix coredump of SPU contexts
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-spufs-fix-coredump-of-spu-contexts.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Michael Ellerman <mpe(a)ellerman.id.au>
Date: Mon, 29 May 2017 20:26:07 +1000
Subject: powerpc/spufs: Fix coredump of SPU contexts
From: Michael Ellerman <mpe(a)ellerman.id.au>
[ Upstream commit 99acc9bede06bbb2662aafff51f5b9e529fa845e ]
If a process dumps core while it has SPU contexts active then we have
code to also dump information about the SPU contexts.
Unfortunately it's been broken for 3 1/2 years, and we didn't notice. In
commit 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers") the nread
variable was removed and rc used instead. That means when the loop exits
successfully, rc has the number of bytes read, but it's then used as the
return value for the function, which should return 0 on success.
So fix it by setting rc = 0 before returning in the success case.
Fixes: 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers")
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Acked-by: Jeremy Kerr <jk(a)ozlabs.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/cell/spufs/coredump.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -175,6 +175,8 @@ static int spufs_arch_write_note(struct
skip = roundup(cprm->pos - total + sz, 4) - cprm->pos;
if (!dump_skip(cprm, skip))
goto Eio;
+
+ rc = 0;
out:
free_page((unsigned long)buf);
return rc;
Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are
queue-4.9/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch
queue-4.9/powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch
queue-4.9/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch
queue-4.9/powerpc-spufs-fix-coredump-of-spu-contexts.patch
queue-4.9/cxl-unlock-on-error-in-probe.patch
queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch
queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch
queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch
This is a note to let you know that I've just added the patch titled
powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash
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-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Michael Ellerman <mpe(a)ellerman.id.au>
Date: Thu, 18 May 2017 20:37:31 +1000
Subject: powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash
From: Michael Ellerman <mpe(a)ellerman.id.au>
[ Upstream commit e41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34 ]
virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on
an address. What this means in practice is that it should only return true for
addresses in the linear mapping which are backed by a valid PFN.
We are failing to properly check that the address is in the linear mapping,
because virt_to_pfn() will return a valid looking PFN for more or less any
address. That bug is actually caused by __pa(), used in virt_to_pfn().
eg: __pa(0xc000000000010000) = 0x10000 # Good
__pa(0xd000000000010000) = 0x10000 # Bad!
__pa(0x0000000000010000) = 0x10000 # Bad!
This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc
miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition
of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from
the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give
you something bogus back.
Until we can verify if that GCC bug is no longer an issue, or come up with
another solution, this commit does the minimal fix to make virt_addr_valid()
work, by explicitly checking that the address is in the linear mapping region.
Fixes: bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit")
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Reviewed-by: Paul Mackerras <paulus(a)ozlabs.org>
Reviewed-by: Balbir Singh <bsingharora(a)gmail.com>
Tested-by: Breno Leitao <breno.leitao(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/page.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -132,7 +132,19 @@ extern long long virt_phys_offset;
#define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT)
#define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
+
+#ifdef CONFIG_PPC_BOOK3S_64
+/*
+ * On hash the vmalloc and other regions alias to the kernel region when passed
+ * through __pa(), which virt_to_pfn() uses. That means virt_addr_valid() can
+ * return true for some vmalloc addresses, which is incorrect. So explicitly
+ * check that the address is in the kernel region.
+ */
+#define virt_addr_valid(kaddr) (REGION_ID(kaddr) == KERNEL_REGION_ID && \
+ pfn_valid(virt_to_pfn(kaddr)))
+#else
#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
+#endif
/*
* On Book-E parts we need __va to parse the device tree and we can't
Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are
queue-4.9/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch
queue-4.9/powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch
queue-4.9/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch
queue-4.9/powerpc-spufs-fix-coredump-of-spu-contexts.patch
queue-4.9/cxl-unlock-on-error-in-probe.patch
queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch
queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch
queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch
This is a note to let you know that I've just added the patch titled
powerpc/modules: If mprofile-kernel is enabled add it to vermagic
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-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Michael Ellerman <mpe(a)ellerman.id.au>
Date: Wed, 10 May 2017 16:57:49 +1000
Subject: powerpc/modules: If mprofile-kernel is enabled add it to vermagic
From: Michael Ellerman <mpe(a)ellerman.id.au>
[ Upstream commit 43e24e82f35291d4c1ca78877ce1b20d3aeb78f1 ]
On powerpc we can build the kernel with two different ABIs for mcount(), which
is used by ftrace. Kernels built with one ABI do not know how to load modules
built with the other ABI. The new style ABI is called "mprofile-kernel", for
want of a better name.
Currently if we build a module using the old style ABI, and the kernel with
mprofile-kernel, when we load the module we'll oops something like:
# insmod autofs4-no-mprofile-kernel.ko
ftrace-powerpc: Unexpected instruction f8810028 around bl _mcount
------------[ cut here ]------------
WARNING: CPU: 6 PID: 3759 at ../kernel/trace/ftrace.c:2024 ftrace_bug+0x2b8/0x3c0
CPU: 6 PID: 3759 Comm: insmod Not tainted 4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 #11
...
NIP [c0000000001eaa48] ftrace_bug+0x2b8/0x3c0
LR [c0000000001eaff8] ftrace_process_locs+0x4a8/0x590
Call Trace:
alloc_pages_current+0xc4/0x1d0 (unreliable)
ftrace_process_locs+0x4a8/0x590
load_module+0x1c8c/0x28f0
SyS_finit_module+0x110/0x140
system_call+0x38/0xfc
...
ftrace failed to modify
[<d000000002a31024>] 0xd000000002a31024
actual: 35:65:00:48
We can avoid this by including in the vermagic whether the kernel/module was
built with mprofile-kernel. Which results in:
# insmod autofs4-pg.ko
autofs4: version magic
'4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 SMP mod_unload modversions '
should be
'4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269-dirty SMP mod_unload modversions mprofile-kernel'
insmod: ERROR: could not insert module autofs4-pg.ko: Invalid module format
Fixes: 8c50b72a3b4f ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel")
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Acked-by: Balbir Singh <bsingharora(a)gmail.com>
Acked-by: Jessica Yu <jeyu(a)redhat.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/module.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -14,6 +14,10 @@
#include <asm-generic/module.h>
+#ifdef CC_USING_MPROFILE_KERNEL
+#define MODULE_ARCH_VERMAGIC "mprofile-kernel"
+#endif
+
#ifndef __powerpc64__
/*
* Thanks to Paul M for explaining this.
Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are
queue-4.9/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch
queue-4.9/powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch
queue-4.9/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch
queue-4.9/powerpc-spufs-fix-coredump-of-spu-contexts.patch
queue-4.9/cxl-unlock-on-error-in-probe.patch
queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch
queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch
queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch
This is a note to let you know that I've just added the patch titled
powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE]
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-don-t-clobber-tcr-when-setting-tcr.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Ivan Mikhaylov <ivan(a)de.ibm.com>
Date: Fri, 19 May 2017 18:47:05 +0300
Subject: powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE]
From: Ivan Mikhaylov <ivan(a)de.ibm.com>
[ Upstream commit 6e2f03e292ef46eed2b31b0a344a91d514f9cd81 ]
Prevent a kernel panic caused by unintentionally clearing TCR watchdog
bits. At this point in the kernel boot, the watchdog may have already
been enabled by u-boot. The original code's attempt to write to the TCR
register results in an inadvertent clearing of the watchdog
configuration bits, causing the 476 to reset.
Signed-off-by: Ivan Mikhaylov <ivan(a)de.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/time.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -719,12 +719,20 @@ static int __init get_freq(char *name, i
static void start_cpu_decrementer(void)
{
#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+ unsigned int tcr;
+
/* Clear any pending timer interrupts */
mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
- /* Enable decrementer interrupt */
- mtspr(SPRN_TCR, TCR_DIE);
-#endif /* defined(CONFIG_BOOKE) || defined(CONFIG_40x) */
+ tcr = mfspr(SPRN_TCR);
+ /*
+ * The watchdog may have already been enabled by u-boot. So leave
+ * TRC[WP] (Watchdog Period) alone.
+ */
+ tcr &= TCR_WP_MASK; /* Clear all bits except for TCR[WP] */
+ tcr |= TCR_DIE; /* Enable decrementer */
+ mtspr(SPRN_TCR, tcr);
+#endif
}
void __init generic_calibrate_decr(void)
Patches currently in stable-queue which might be from ivan(a)de.ibm.com are
queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch
This is a note to let you know that I've just added the patch titled
powerpc/8xx: fix mpc8xx_get_irq() return on no irq
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-8xx-fix-mpc8xx_get_irq-return-on-no-irq.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Fri, 10 Mar 2017 11:37:01 +0100
Subject: powerpc/8xx: fix mpc8xx_get_irq() return on no irq
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
[ Upstream commit 3c29b6038828c1f4c9ecbfec14d4fc5e25f1c947 ]
IRQ 0 is a valid HW interrupt. So get_irq() shall return 0 when
there is no irq, instead of returning irq_linear_revmap(... ,0)
Fixes: f2a0bd3753dad ("[POWERPC] 8xx: powerpc port of core CPM PIC")
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/sysdev/mpc8xx_pic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -79,7 +79,7 @@ unsigned int mpc8xx_get_irq(void)
irq = in_be32(&siu_reg->sc_sivec) >> 26;
if (irq == PIC_VEC_SPURRIOUS)
- irq = 0;
+ return 0;
return irq_linear_revmap(mpc8xx_pic_host, irq);
Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are
queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch
This is a note to let you know that I've just added the patch titled
PowerCap: Fix an error code in powercap_register_zone()
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:
powercap-fix-an-error-code-in-powercap_register_zone.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 10 May 2017 22:40:06 +0300
Subject: PowerCap: Fix an error code in powercap_register_zone()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 216c4e9db4c9d1d2a382b42880442dc632cd47d9 ]
In the current code we accidentally return the successful result from
idr_alloc() instead of a negative error pointer. The caller is looking
for an error pointer and so it treats the returned value as a valid
pointer.
This one might be a bit serious because if it lets people get around the
kernel's protection for remapping NULL. I'm not sure.
Fixes: 75d2364ea0ca (PowerCap: Add class driver)
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/powercap/powercap_sys.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/powercap/powercap_sys.c
+++ b/drivers/powercap/powercap_sys.c
@@ -538,6 +538,7 @@ struct powercap_zone *powercap_register_
power_zone->id = result;
idr_init(&power_zone->idr);
+ result = -ENOMEM;
power_zone->name = kstrdup(name, GFP_KERNEL);
if (!power_zone->name)
goto err_name_alloc;
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/block-fix-an-error-code-in-add_partition.patch
queue-4.9/x.509-fix-error-code-in-x509_cert_parse.patch
queue-4.9/rdma-iw_cxgb4-avoid-touch-after-free-error-in-arp-failure-handlers.patch
queue-4.9/drm-amdkfd-null-dereference-involving-create_process.patch
queue-4.9/pnfs-flexfiles-missing-error-code-in-ff_layout_alloc_lseg.patch
queue-4.9/drivers-misc-vmw_vmci-vmci_queue_pair.c-fix-a-couple-integer-overflow-tests.patch
queue-4.9/cxl-unlock-on-error-in-probe.patch
queue-4.9/md-cluster-fix-potential-lock-issue-in-add_new_disk.patch
queue-4.9/ipmi_ssif-unlock-on-allocation-failure.patch
queue-4.9/powercap-fix-an-error-code-in-powercap_register_zone.patch
queue-4.9/perf-core-fix-error-handling-in-perf_event_alloc.patch
queue-4.9/libceph-null-deref-on-crush_decode-error-path.patch
This is a note to let you know that I've just added the patch titled
pNFS/flexfiles: missing error code in ff_layout_alloc_lseg()
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:
pnfs-flexfiles-missing-error-code-in-ff_layout_alloc_lseg.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 20 May 2017 00:31:12 +0300
Subject: pNFS/flexfiles: missing error code in ff_layout_alloc_lseg()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 662f9a105b4322b8559d448f86110e6ec24b8738 ]
If xdr_inline_decode() fails then we end up returning ERR_PTR(0). The
caller treats NULL returns as -ENOMEM so it doesn't really hurt runtime,
but obviously we intended to set an error code here.
Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/flexfilelayout/flexfilelayout.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -475,6 +475,7 @@ ff_layout_alloc_lseg(struct pnfs_layout_
goto out_err_free;
/* fh */
+ rc = -EIO;
p = xdr_inline_decode(&stream, 4);
if (!p)
goto out_err_free;
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/block-fix-an-error-code-in-add_partition.patch
queue-4.9/x.509-fix-error-code-in-x509_cert_parse.patch
queue-4.9/rdma-iw_cxgb4-avoid-touch-after-free-error-in-arp-failure-handlers.patch
queue-4.9/drm-amdkfd-null-dereference-involving-create_process.patch
queue-4.9/pnfs-flexfiles-missing-error-code-in-ff_layout_alloc_lseg.patch
queue-4.9/drivers-misc-vmw_vmci-vmci_queue_pair.c-fix-a-couple-integer-overflow-tests.patch
queue-4.9/cxl-unlock-on-error-in-probe.patch
queue-4.9/md-cluster-fix-potential-lock-issue-in-add_new_disk.patch
queue-4.9/ipmi_ssif-unlock-on-allocation-failure.patch
queue-4.9/powercap-fix-an-error-code-in-powercap_register_zone.patch
queue-4.9/perf-core-fix-error-handling-in-perf_event_alloc.patch
queue-4.9/libceph-null-deref-on-crush_decode-error-path.patch
This is a note to let you know that I've just added the patch titled
PM / devfreq: Fix potential NULL pointer dereference in governor_store
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:
pm-devfreq-fix-potential-null-pointer-dereference-in-governor_store.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Wed, 6 Dec 2017 14:20:15 -0600
Subject: PM / devfreq: Fix potential NULL pointer dereference in governor_store
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit 63f1e05f7fe9ca509c60154d6a833abf96eecdc9 ]
df->governor is being dereferenced before it is null checked,
hence there is a potential null pointer dereference.
Notice that df->governor is being null checked at line 1004:
if (df->governor) {, which implies it might be null.
Fix this by null checking df->governor before dereferencing it.
Addresses-Coverity-ID: 1401988 ("Dereference before null check")
Fixes: bcf23c79c4e4 ("PM / devfreq: Fix available_governor sysfs")
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Reviewed-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/devfreq/devfreq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -943,7 +943,8 @@ static ssize_t governor_store(struct dev
if (df->governor == governor) {
ret = 0;
goto out;
- } else if (df->governor->immutable || governor->immutable) {
+ } else if ((df->governor && df->governor->immutable) ||
+ governor->immutable) {
ret = -EINVAL;
goto out;
}
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.9/pm-devfreq-fix-potential-null-pointer-dereference-in-governor_store.patch
queue-4.9/net-freescale-fix-potential-null-pointer-dereference.patch
This is a note to let you know that I've just added the patch titled
pinctrl: meson-gxbb: remove non-existing pin GPIOX_22
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-meson-gxbb-remove-non-existing-pin-gpiox_22.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Heiner Kallweit <hkallweit1(a)gmail.com>
Date: Wed, 7 Jun 2017 07:44:20 +0200
Subject: pinctrl: meson-gxbb: remove non-existing pin GPIOX_22
From: Heiner Kallweit <hkallweit1(a)gmail.com>
[ Upstream commit 4c8127cb523982e0a474ad80b14b665dc2f37b3b ]
After commit 34e61801a3b9 "pinctrl: meson-gxbb: Add missing GPIODV_18
pin entry" I started to get the following warning:
"meson-pinctrl c8834000.periphs:pinctrl@4b0: names 119 do not match
number of GPIOs 120"
It turned out that not the mentioned commit has a problem, it just
revealed another problem which had existed before.
There is no PIN GPIOX_22 on Meson GXBB.
Fixes: 468c234f9ed7 ("pinctrl: amlogic: Add support for Amlogic Meson GXBB SoC")
Signed-off-by: Heiner Kallweit <hkallweit1(a)gmail.com>
Reviewed-by: Neil Armstrong <narmstrong(a)baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -138,7 +138,6 @@ static const struct pinctrl_pin_desc mes
MESON_PIN(GPIOX_19, EE_OFF),
MESON_PIN(GPIOX_20, EE_OFF),
MESON_PIN(GPIOX_21, EE_OFF),
- MESON_PIN(GPIOX_22, EE_OFF),
MESON_PIN(GPIOCLK_0, EE_OFF),
MESON_PIN(GPIOCLK_1, EE_OFF),
Patches currently in stable-queue which might be from hkallweit1(a)gmail.com are
queue-4.9/pinctrl-meson-gxbb-remove-non-existing-pin-gpiox_22.patch
This is a note to let you know that I've just added the patch titled
pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts
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-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Mon, 1 Jan 2018 13:23:57 +0100
Subject: pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 9291c65b01d1c67ebd56644cb19317ad665c44b3 ]
On some systems, some PCB traces attached to GpioInts are routed in such
a way that they pick up enough interference to constantly (many times per
second) trigger.
Enabling glitch-filtering fixes this.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/intel/pinctrl-baytrail.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
+++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
@@ -46,6 +46,9 @@
#define BYT_TRIG_POS BIT(25)
#define BYT_TRIG_LVL BIT(24)
#define BYT_DEBOUNCE_EN BIT(20)
+#define BYT_GLITCH_FILTER_EN BIT(19)
+#define BYT_GLITCH_F_SLOW_CLK BIT(17)
+#define BYT_GLITCH_F_FAST_CLK BIT(16)
#define BYT_PULL_STR_SHIFT 9
#define BYT_PULL_STR_MASK (3 << BYT_PULL_STR_SHIFT)
#define BYT_PULL_STR_2K (0 << BYT_PULL_STR_SHIFT)
@@ -1579,6 +1582,9 @@ static int byt_irq_type(struct irq_data
*/
value &= ~(BYT_DIRECT_IRQ_EN | BYT_TRIG_POS | BYT_TRIG_NEG |
BYT_TRIG_LVL);
+ /* Enable glitch filtering */
+ value |= BYT_GLITCH_FILTER_EN | BYT_GLITCH_F_SLOW_CLK |
+ BYT_GLITCH_F_FAST_CLK;
writel(value, reg);
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/gpio-crystalcove-do-not-write-regular-gpio-registers-for-virtual-gpios.patch
queue-4.9/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch
queue-4.9/hid-i2c-call-acpi_device_fix_up_power-for-acpi-enumerated-devices.patch
queue-4.9/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch
queue-4.9/input-goodix-disable-irqs-while-suspended.patch
queue-4.9/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch
queue-4.9/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch
This is a note to let you know that I've just added the patch titled
pidns: disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid()
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:
pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Kirill Tkhai <ktkhai(a)virtuozzo.com>
Date: Mon, 8 May 2017 15:56:34 -0700
Subject: pidns: disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid()
From: Kirill Tkhai <ktkhai(a)virtuozzo.com>
[ Upstream commit 8896c23d2ef803f1883fea73117a435925c2b4c4 ]
alloc_pidmap() advances pid_namespace::last_pid. When first pid
allocation fails, then next created process will have pid 2 and
pid_ns_prepare_proc() won't be called. So, pid_namespace::proc_mnt will
never be initialized (not to mention that there won't be a child
reaper).
I saw crash stack of such case on kernel 3.10:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: proc_flush_task+0x8f/0x1b0
Call Trace:
release_task+0x3f/0x490
wait_consider_task.part.10+0x7ff/0xb00
do_wait+0x11f/0x280
SyS_wait4+0x7d/0x110
We may fix this by restore of last_pid in 0 or by prohibiting of futher
allocations. Since there was a similar issue in Oleg Nesterov's commit
314a8ad0f18a ("pidns: fix free_pid() to handle the first fork failure").
and it was fixed via prohibiting allocation, let's follow this way, and
do the same.
Link: http://lkml.kernel.org/r/149201021004.4863.6762095011554287922.stgit@localh…
Signed-off-by: Kirill Tkhai <ktkhai(a)virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov(a)openvz.org>
Cc: Andrei Vagin <avagin(a)virtuozzo.com>
Cc: Andreas Gruenbacher <agruenba(a)redhat.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Michael Kerrisk <mtk.manpages(a)googlemail.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Paul Moore <paul(a)paul-moore.com>
Cc: Eric Biederman <ebiederm(a)xmission.com>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Serge Hallyn <serge(a)hallyn.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/pid.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -322,8 +322,10 @@ struct pid *alloc_pid(struct pid_namespa
}
if (unlikely(is_child_reaper(pid))) {
- if (pid_ns_prepare_proc(ns))
+ if (pid_ns_prepare_proc(ns)) {
+ disable_pid_allocation(ns);
goto out_free;
+ }
}
get_pid_ns(ns);
Patches currently in stable-queue which might be from ktkhai(a)virtuozzo.com are
queue-4.9/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch
This is a note to let you know that I've just added the patch titled
perf trace: Add mmap alias for s390
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:
perf-trace-add-mmap-alias-for-s390.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Jiri Olsa <jolsa(a)kernel.org>
Date: Wed, 31 May 2017 13:35:57 +0200
Subject: perf trace: Add mmap alias for s390
From: Jiri Olsa <jolsa(a)kernel.org>
[ Upstream commit 54265664c15a68905d8d67d19205e9a767636434 ]
The s390 architecture maps sys_mmap (nr 90) into sys_old_mmap. For this
reason perf trace can't find the proper syscall event to get args format
from and displays it wrongly as 'continued'.
To fix that fill the "alias" field with "old_mmap" for trace's mmap record
to get the correct translation.
Before:
0.042 ( 0.011 ms): vest/43052 fstat(statbuf: 0x3ffff89fd90 ) = 0
0.042 ( 0.028 ms): vest/43052 ... [continued]: mmap()) = 0x3fffd6e2000
0.072 ( 0.025 ms): vest/43052 read(buf: 0x3fffd6e2000, count: 4096 ) = 6
After:
0.045 ( 0.011 ms): fstat(statbuf: 0x3ffff8a0930 ) = 0
0.057 ( 0.018 ms): mmap(arg: 0x3ffff8a0858 ) = 0x3fffd14a000
0.076 ( 0.025 ms): read(buf: 0x3fffd14a000, count: 4096 ) = 6
Signed-off-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
Link: http://lkml.kernel.org/r/20170531113557.19175-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/builtin-trace.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -679,6 +679,10 @@ static struct syscall_fmt {
{ .name = "mlockall", .errmsg = true,
.arg_scnprintf = { [0] = SCA_HEX, /* addr */ }, },
{ .name = "mmap", .hexret = true,
+/* The standard mmap maps to old_mmap on s390x */
+#if defined(__s390x__)
+ .alias = "old_mmap",
+#endif
.arg_scnprintf = { [0] = SCA_HEX, /* addr */
[2] = SCA_MMAP_PROT, /* prot */
[3] = SCA_MMAP_FLAGS, /* flags */ }, },
Patches currently in stable-queue which might be from jolsa(a)kernel.org are
queue-4.9/perf-report-fix-off-by-one-for-non-activation-frames.patch
queue-4.9/perf-trace-add-mmap-alias-for-s390.patch
queue-4.9/perf-tools-fix-copyfile_offset-update-of-output-offset.patch
queue-4.9/perf-core-correct-event-creation-with-perf_format_group.patch
queue-4.9/perf-tools-decompress-kernel-module-when-reading-dso-data.patch
queue-4.9/perf-tests-decompress-kernel-module-before-objdump.patch
queue-4.9/perf-header-set-proper-module-name-when-build-id-event-found.patch
This is a note to let you know that I've just added the patch titled
perf tools: Decompress kernel module when reading DSO data
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:
perf-tools-decompress-kernel-module-when-reading-dso-data.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Namhyung Kim <namhyung(a)kernel.org>
Date: Thu, 8 Jun 2017 16:31:05 +0900
Subject: perf tools: Decompress kernel module when reading DSO data
From: Namhyung Kim <namhyung(a)kernel.org>
[ Upstream commit 1d6b3c9ba756a5134fd7ad1959acac776d17404b ]
Currently perf decompresses kernel modules when loading the symbol table
but it missed to do it when reading raw data.
Signed-off-by: Namhyung Kim <namhyung(a)kernel.org>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
Cc: Wang Nan <wangnan0(a)huawei.com>
Cc: kernel-team(a)lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-6-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/dso.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -366,7 +366,23 @@ static int __open_dso(struct dso *dso, s
if (!is_regular_file(name))
return -EINVAL;
+ if (dso__needs_decompress(dso)) {
+ char newpath[KMOD_DECOMP_LEN];
+ size_t len = sizeof(newpath);
+
+ if (dso__decompress_kmodule_path(dso, name, newpath, len) < 0) {
+ free(name);
+ return -dso->load_errno;
+ }
+
+ strcpy(name, newpath);
+ }
+
fd = do_open(name);
+
+ if (dso__needs_decompress(dso))
+ unlink(name);
+
free(name);
return fd;
}
Patches currently in stable-queue which might be from namhyung(a)kernel.org are
queue-4.9/perf-report-fix-off-by-one-for-non-activation-frames.patch
queue-4.9/perf-trace-add-mmap-alias-for-s390.patch
queue-4.9/perf-report-ensure-the-perf-dso-mapping-matches-what-libdw-sees.patch
queue-4.9/perf-tools-fix-copyfile_offset-update-of-output-offset.patch
queue-4.9/perf-tools-decompress-kernel-module-when-reading-dso-data.patch
queue-4.9/perf-tests-decompress-kernel-module-before-objdump.patch
queue-4.9/perf-header-set-proper-module-name-when-build-id-event-found.patch
This is a note to let you know that I've just added the patch titled
perf tools: Fix copyfile_offset update of output offset
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:
perf-tools-fix-copyfile_offset-update-of-output-offset.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 foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Jiri Olsa <jolsa(a)kernel.org>
Date: Tue, 9 Jan 2018 14:39:23 +0100
Subject: perf tools: Fix copyfile_offset update of output offset
From: Jiri Olsa <jolsa(a)kernel.org>
[ Upstream commit fa1195ccc0af2d121abe0fe266a1caee8c265eea ]
We need to increase output offset in each iteration, not decrease it as
we currently do.
I guess we were lucky to finish in most cases in first iteration, so the
bug never showed. However it shows a lot when working with big (~4GB)
size data.
Signed-off-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Fixes: 9c9f5a2f1944 ("perf tools: Introduce copyfile_offset() function")
Link: http://lkml.kernel.org/r/20180109133923.25406-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -207,7 +207,7 @@ int copyfile_offset(int ifd, loff_t off_
size -= ret;
off_in += ret;
- off_out -= ret;
+ off_out += ret;
}
munmap(ptr, off_in + size);
Patches currently in stable-queue which might be from jolsa(a)kernel.org are
queue-4.9/perf-report-fix-off-by-one-for-non-activation-frames.patch
queue-4.9/perf-trace-add-mmap-alias-for-s390.patch
queue-4.9/perf-tools-fix-copyfile_offset-update-of-output-offset.patch
queue-4.9/perf-core-correct-event-creation-with-perf_format_group.patch
queue-4.9/perf-tools-decompress-kernel-module-when-reading-dso-data.patch
queue-4.9/perf-tests-decompress-kernel-module-before-objdump.patch
queue-4.9/perf-header-set-proper-module-name-when-build-id-event-found.patch