* [PATCH 4.9 001/104] drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 002/104] drm: bridge: add DT bindings for TI ths8135 Greg Kroah-Hartman
` (100 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kristian H. Kristensen,
Daniel Vetter, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Kristian H. Kristensen" <hoegsberg@gmail.com>
[ Upstream commit af913418261d6d3e7a29f06cf35f04610ead667c ]
We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code()
macro to work correctly.
Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsberg@google.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -154,6 +154,7 @@ extern "C" {
/* Vendor Ids: */
#define DRM_FORMAT_MOD_NONE 0
+#define DRM_FORMAT_MOD_VENDOR_NONE 0
#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
#define DRM_FORMAT_MOD_VENDOR_NV 0x03
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 002/104] drm: bridge: add DT bindings for TI ths8135
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 001/104] drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 003/104] GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next Greg Kroah-Hartman
` (99 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski,
Laurent Pinchart, Rob Herring, Archit Taneja, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[ Upstream commit 2e644be30fcc08c736f66b60f4898d274d4873ab ]
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszewski@baylibre.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,46 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 003/104] GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 001/104] drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 002/104] drm: bridge: add DT bindings for TI ths8135 Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 005/104] ARM: dts: exynos: Add CPU OPPs for Exynos4412 Prime Greg Kroah-Hartman
` (98 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Bob Peterson, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 14d37564fa3dc4e5d4c6828afcd26ac14e6796c5 ]
This patch fixes a place where function gfs2_glock_iter_next can
reference an invalid error pointer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/gfs2/glock.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1820,16 +1820,18 @@ void gfs2_glock_exit(void)
static void gfs2_glock_iter_next(struct gfs2_glock_iter *gi)
{
- do {
- gi->gl = rhashtable_walk_next(&gi->hti);
+ while ((gi->gl = rhashtable_walk_next(&gi->hti))) {
if (IS_ERR(gi->gl)) {
if (PTR_ERR(gi->gl) == -EAGAIN)
continue;
gi->gl = NULL;
+ return;
}
- /* Skip entries for other sb and dead entries */
- } while ((gi->gl) && ((gi->sdp != gi->gl->gl_name.ln_sbd) ||
- __lockref_is_dead(&gi->gl->gl_lockref)));
+ /* Skip entries for other sb and dead entries */
+ if (gi->sdp == gi->gl->gl_name.ln_sbd &&
+ !__lockref_is_dead(&gi->gl->gl_lockref))
+ return;
+ }
}
static void *gfs2_glock_seq_start(struct seq_file *seq, loff_t *pos)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 005/104] ARM: dts: exynos: Add CPU OPPs for Exynos4412 Prime
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 003/104] GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 006/104] clk: sunxi-ng: fix PLL_CPUX adjusting on H3 Greg Kroah-Hartman
` (97 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Doug Anderson, Andreas Faerber,
Thomas Abraham, Tobias Jakobi, Ben Gamari,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
[ Upstream commit 80b7a2e2498bcffb1a79980dfbeb7a1275577b28 ]
Add CPU operating points for Exynos4412 Prime (it supports
additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
a regular non-turbo OPP on this SoC). Also update relevant
cooling maps to account for new OPPs.
ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
update their board files accordingly.
Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +-
arch/arm/boot/dts/exynos4412-odroidx2.dts | 1
arch/arm/boot/dts/exynos4412-prime.dtsi | 41 ++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 2 -
5 files changed, 48 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -97,11 +97,11 @@
thermal-zones {
cpu_thermal: cpu-thermal {
cooling-maps {
- map0 {
+ cooling_map0: map0 {
/* Corresponds to 800MHz at freq_table */
cooling-device = <&cpu0 7 7>;
};
- map1 {
+ cooling_map1: map1 {
/* Corresponds to 200MHz at freq_table */
cooling-device = <&cpu0 13 13>;
};
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -13,6 +13,7 @@
/dts-v1/;
#include "exynos4412-odroid-common.dtsi"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-U3 board based on Exynos4412";
@@ -47,11 +48,11 @@
cooling-maps {
map0 {
trip = <&cpu_alert1>;
- cooling-device = <&cpu0 7 7>;
+ cooling-device = <&cpu0 9 9>;
};
map1 {
trip = <&cpu_alert2>;
- cooling-device = <&cpu0 13 13>;
+ cooling-device = <&cpu0 15 15>;
};
map2 {
trip = <&cpu_alert0>;
--- a/arch/arm/boot/dts/exynos4412-odroidx2.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx2.dts
@@ -12,6 +12,7 @@
*/
#include "exynos4412-odroidx.dts"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-X2 board based on Exynos4412";
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-prime.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Samsung's Exynos4412 Prime SoC device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Exynos4412 Prime SoC revision supports higher CPU frequencies than
+ * non-Prime version. Therefore we need to update OPPs table and
+ * thermal maps accordingly.
+ */
+
+&cpu0_opp_1500 {
+ /delete-property/turbo-mode;
+};
+
+&cpu0_opp_table {
+ opp@1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+ opp@1704000000 {
+ opp-hz = /bits/ 64 <1704000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+};
+
+&cooling_map0 {
+ cooling-device = <&cpu0 9 9>;
+};
+
+&cooling_map1 {
+ cooling-device = <&cpu0 15 15>;
+};
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -130,7 +130,7 @@
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
- opp@1500000000 {
+ cpu0_opp_1500: opp@1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 006/104] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 005/104] ARM: dts: exynos: Add CPU OPPs for Exynos4412 Prime Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 007/104] RDS: RDMA: Fix the composite message user notification Greg Kroah-Hartman
` (96 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ondrej Jirman, Lutz Sammer,
Chen-Yu Tsai, Maxime Ripard, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ondrej Jirman <megous@megous.com>
[ Upstream commit a43c96427e713bea94e9ef50e8be1f493afc0691 ]
When adjusting PLL_CPUX on H3, the PLL is temporarily driven
too high, and the system becomes unstable (oopses or hangs).
Add a notifier to avoid this situation by temporarily switching
to a known stable 24 MHz oscillator.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Tested-by: Lutz Sammer <johns98@gmx.net>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -803,6 +803,13 @@ static const struct sunxi_ccu_desc sun8i
.num_resets = ARRAY_SIZE(sun8i_h3_ccu_resets),
};
+static struct ccu_mux_nb sun8i_h3_cpu_nb = {
+ .common = &cpux_clk.common,
+ .cm = &cpux_clk.mux,
+ .delay_us = 1, /* > 8 clock cycles at 24 MHz */
+ .bypass_index = 1, /* index of 24 MHz oscillator */
+};
+
static void __init sun8i_h3_ccu_setup(struct device_node *node)
{
void __iomem *reg;
@@ -821,6 +828,9 @@ static void __init sun8i_h3_ccu_setup(st
writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
sunxi_ccu_probe(node, reg, &sun8i_h3_ccu_desc);
+
+ ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ &sun8i_h3_cpu_nb);
}
CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
sun8i_h3_ccu_setup);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 007/104] RDS: RDMA: Fix the composite message user notification
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 006/104] clk: sunxi-ng: fix PLL_CPUX adjusting on H3 Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 008/104] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes Greg Kroah-Hartman
` (95 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Venkat Venkatsubra,
Santosh Shilimkar, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
[ Upstream commit 941f8d55f6d613a460a5e080d25a38509f45eb75 ]
When application sends an RDS RDMA composite message consist of
RDMA transfer to be followed up by non RDMA payload, it expect to
be notified *only* when the full message gets delivered. RDS RDMA
notification doesn't behave this way though.
Thanks to Venkat for debug and root casuing the issue
where only first part of the message(RDMA) was
successfully delivered but remainder payload delivery failed.
In that case, application should not be notified with
a false positive of message delivery success.
Fix this case by making sure the user gets notified only after
the full message delivery.
Reviewed-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rds/ib_send.c | 25 +++++++++++++++----------
net/rds/rdma.c | 10 ++++++++++
net/rds/rds.h | 1 +
net/rds/send.c | 4 +++-
4 files changed, 29 insertions(+), 11 deletions(-)
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -69,16 +69,6 @@ static void rds_ib_send_complete(struct
complete(rm, notify_status);
}
-static void rds_ib_send_unmap_data(struct rds_ib_connection *ic,
- struct rm_data_op *op,
- int wc_status)
-{
- if (op->op_nents)
- ib_dma_unmap_sg(ic->i_cm_id->device,
- op->op_sg, op->op_nents,
- DMA_TO_DEVICE);
-}
-
static void rds_ib_send_unmap_rdma(struct rds_ib_connection *ic,
struct rm_rdma_op *op,
int wc_status)
@@ -139,6 +129,21 @@ static void rds_ib_send_unmap_atomic(str
rds_ib_stats_inc(s_ib_atomic_fadd);
}
+static void rds_ib_send_unmap_data(struct rds_ib_connection *ic,
+ struct rm_data_op *op,
+ int wc_status)
+{
+ struct rds_message *rm = container_of(op, struct rds_message, data);
+
+ if (op->op_nents)
+ ib_dma_unmap_sg(ic->i_cm_id->device,
+ op->op_sg, op->op_nents,
+ DMA_TO_DEVICE);
+
+ if (rm->rdma.op_active && rm->data.op_notify)
+ rds_ib_send_unmap_rdma(ic, &rm->rdma, wc_status);
+}
+
/*
* Unmap the resources associated with a struct send_work.
*
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -626,6 +626,16 @@ int rds_cmsg_rdma_args(struct rds_sock *
}
op->op_notifier->n_user_token = args->user_token;
op->op_notifier->n_status = RDS_RDMA_SUCCESS;
+
+ /* Enable rmda notification on data operation for composite
+ * rds messages and make sure notification is enabled only
+ * for the data operation which follows it so that application
+ * gets notified only after full message gets delivered.
+ */
+ if (rm->data.op_sg) {
+ rm->rdma.op_notify = 0;
+ rm->data.op_notify = !!(args->flags & RDS_RDMA_NOTIFY_ME);
+ }
}
/* The cookie contains the R_Key of the remote memory region, and
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -414,6 +414,7 @@ struct rds_message {
} rdma;
struct rm_data_op {
unsigned int op_active:1;
+ unsigned int op_notify:1;
unsigned int op_nents;
unsigned int op_count;
unsigned int op_dmasg;
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -475,12 +475,14 @@ void rds_rdma_send_complete(struct rds_m
struct rm_rdma_op *ro;
struct rds_notifier *notifier;
unsigned long flags;
+ unsigned int notify = 0;
spin_lock_irqsave(&rm->m_rs_lock, flags);
+ notify = rm->rdma.op_notify | rm->data.op_notify;
ro = &rm->rdma;
if (test_bit(RDS_MSG_ON_SOCK, &rm->m_flags) &&
- ro->op_active && ro->op_notify && ro->op_notifier) {
+ ro->op_active && notify && ro->op_notifier) {
notifier = ro->op_notifier;
rs = rm->m_rs;
sock_hold(rds_rs_to_sk(rs));
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 008/104] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 007/104] RDS: RDMA: Fix the composite message user notification Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 009/104] MIPS: Ensure bss section ends on a long-aligned address Greg Kroah-Hartman
` (94 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Simon Horman, Geert Uytterhoeven,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Horman <horms+renesas@verge.net.au>
[ Upstream commit 654450baf2afba86cf328e1849ccac61ec4630af ]
Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/r8a7790.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1493,7 +1493,8 @@
};
msiof0: spi@e6e20000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e20000 0 0x0064>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7790_CLK_MSIOF0>;
@@ -1507,7 +1508,8 @@
};
msiof1: spi@e6e10000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e10000 0 0x0064>;
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF1>;
@@ -1521,7 +1523,8 @@
};
msiof2: spi@e6e00000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e00000 0 0x0064>;
interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF2>;
@@ -1535,7 +1538,8 @@
};
msiof3: spi@e6c90000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6c90000 0 0x0064>;
interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF3>;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 009/104] MIPS: Ensure bss section ends on a long-aligned address
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 008/104] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing Greg Kroah-Hartman
` (93 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Burton, linux-mips,
Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <paul.burton@imgtec.com>
[ Upstream commit 3f00f4d8f083bc61005d0a1ef592b149f5c88bbd ]
When clearing the .bss section in kernel_entry we do so using LONG_S
instructions, and branch whilst the current write address doesn't equal
the end of the .bss section minus the size of a long integer. The .bss
section always begins at a long-aligned address and we always increment
the write pointer by the size of a long integer - we therefore rely upon
the .bss section ending at a long-aligned address. If this is not the
case then the long-aligned write address can never be equal to the
non-long-aligned end address & we will continue to increment past the
end of the .bss section, attempting to zero the rest of memory.
Despite this requirement that .bss end at a long-aligned address we pass
0 as the end alignment requirement to the BSS_SECTION macro and thus
don't guarantee any particular alignment, allowing us to hit the error
condition described above.
Fix this by instead passing 8 bytes as the end alignment argument to
the BSS_SECTION macro, ensuring that the end of the .bss section is
always at least long-aligned.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14526/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -182,7 +182,7 @@ SECTIONS
* Force .bss to 64K alignment so that .bss..swapper_pg_dir
* gets that alignment. .sbss should be empty, so there will be
* no holes after __init_end. */
- BSS_SECTION(0, 0x10000, 0)
+ BSS_SECTION(0, 0x10000, 8)
_end = . ;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 009/104] MIPS: Ensure bss section ends on a long-aligned address Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 9:10 ` Mathieu Malaterre
2017-10-06 8:50 ` [PATCH 4.9 011/104] MIPS: kexec: Do not reserve invalid crashkernel memory on boot Greg Kroah-Hartman
` (92 subsequent siblings)
101 siblings, 1 reply; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marcin Nowakowski, linux-mips,
Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
[ Upstream commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ]
When a memory offset is specified through the commandline, add the
memory in range PHYS_OFFSET:Y as reserved memory area.
Otherwise the bootmem allocator is initialised with low page equal to
min_low_pfn = PHYS_OFFSET, and in free_all_bootmem will process pages
starting from min_low_pfn instead of PFN(Y).
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14613/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/setup.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -589,6 +589,10 @@ static int __init early_parse_mem(char *
start = memparse(p + 1, &p);
add_memory_region(start, size, BOOT_MEM_RAM);
+
+ if (start && start > PHYS_OFFSET)
+ add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
+ BOOT_MEM_RESERVED);
return 0;
}
early_param("mem", early_parse_mem);
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing
2017-10-06 8:50 ` [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing Greg Kroah-Hartman
@ 2017-10-06 9:10 ` Mathieu Malaterre
2017-10-06 9:18 ` Greg Kroah-Hartman
0 siblings, 1 reply; 144+ messages in thread
From: Mathieu Malaterre @ 2017-10-06 9:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Marcin Nowakowski, linux-mips,
Ralf Baechle, Sasha Levin
Hi Greg,
Please do not apply to stable.
See: https://patchwork.linux-mips.org/patch/17235/
Thanks
On Fri, Oct 6, 2017 at 10:50 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
>
>
> [ Upstream commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ]
>
> When a memory offset is specified through the commandline, add the
> memory in range PHYS_OFFSET:Y as reserved memory area.
> Otherwise the bootmem allocator is initialised with low page equal to
> min_low_pfn = PHYS_OFFSET, and in free_all_bootmem will process pages
> starting from min_low_pfn instead of PFN(Y).
>
> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
> Cc: linux-mips@linux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/14613/
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> arch/mips/kernel/setup.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -589,6 +589,10 @@ static int __init early_parse_mem(char *
> start = memparse(p + 1, &p);
>
> add_memory_region(start, size, BOOT_MEM_RAM);
> +
> + if (start && start > PHYS_OFFSET)
> + add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
> + BOOT_MEM_RESERVED);
> return 0;
> }
> early_param("mem", early_parse_mem);
>
>
>
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing
2017-10-06 9:10 ` Mathieu Malaterre
@ 2017-10-06 9:18 ` Greg Kroah-Hartman
2017-10-06 9:21 ` Mathieu Malaterre
0 siblings, 1 reply; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 9:18 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: linux-kernel, stable, Marcin Nowakowski, linux-mips,
Ralf Baechle, Sasha Levin
On Fri, Oct 06, 2017 at 11:10:11AM +0200, Mathieu Malaterre wrote:
> Hi Greg,
>
> Please do not apply to stable.
>
> See: https://patchwork.linux-mips.org/patch/17235/
Ah, so will you send this and that one for 4.9 when it hits Linus's
tree?
I'll go drop this one now, thanks.
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing
2017-10-06 9:18 ` Greg Kroah-Hartman
@ 2017-10-06 9:21 ` Mathieu Malaterre
0 siblings, 0 replies; 144+ messages in thread
From: Mathieu Malaterre @ 2017-10-06 9:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Marcin Nowakowski, linux-mips,
Ralf Baechle, Sasha Levin
On Fri, Oct 6, 2017 at 11:18 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Oct 06, 2017 at 11:10:11AM +0200, Mathieu Malaterre wrote:
>> Hi Greg,
>>
>> Please do not apply to stable.
>>
>> See: https://patchwork.linux-mips.org/patch/17235/
>
> Ah, so will you send this and that one for 4.9 when it hits Linus's
> tree?
>
> I'll go drop this one now, thanks.
Sorry I meant to say do not apply to '4.9 stable branch'. For the
other stable branches, I suspect this is just a matter of days before
Ralf sends the updated fix.
-M
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH 4.9 011/104] MIPS: kexec: Do not reserve invalid crashkernel memory on boot
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 012/104] MIPS: ralink: Fix a typo in the pinmux setup Greg Kroah-Hartman
` (91 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marcin Nowakowski, linux-mips,
Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
[ Upstream commit a8f108d70c74d83574c157648383eb2e4285a190 ]
Do not reserve memory for the crashkernel if the commandline argument
points to a wrong location. This can happen if the location is specified
wrong or if the same commandline is reused when starting the crashkernel
- in the latter case the reserved memory would point to the location
from which the crashkernel is executing.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14612/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/setup.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -668,6 +668,11 @@ static void __init mips_parse_crashkerne
if (ret != 0 || crash_size <= 0)
return;
+ if (!memory_region_available(crash_base, crash_size)) {
+ pr_warn("Invalid memory region reserved for crash kernel\n");
+ return;
+ }
+
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 012/104] MIPS: ralink: Fix a typo in the pinmux setup.
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 011/104] MIPS: kexec: Do not reserve invalid crashkernel memory on boot Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 013/104] MIPS: ralink: Fix incorrect assignment on ralink_soc Greg Kroah-Hartman
` (90 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, John Crispin, linux-mips,
Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Crispin <john@phrozen.org>
[ Upstream commit 58181a117d353427127a2e7afc7cf1ab44759828 ]
There is a typo inside the pinmux setup code. The function is really
called utif and not util. This was recently discovered when people were
trying to make the UTIF interface work.
Signed-off-by: John Crispin <john@phrozen.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14899/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/ralink/mt7620.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/arch/mips/ralink/mt7620.c
+++ b/arch/mips/ralink/mt7620.c
@@ -176,7 +176,7 @@ static struct rt2880_pmx_func spi_cs1_gr
static struct rt2880_pmx_func spis_grp_mt7628[] = {
FUNC("pwm_uart2", 3, 14, 4),
- FUNC("util", 2, 14, 4),
+ FUNC("utif", 2, 14, 4),
FUNC("gpio", 1, 14, 4),
FUNC("spis", 0, 14, 4),
};
@@ -190,28 +190,28 @@ static struct rt2880_pmx_func gpio_grp_m
static struct rt2880_pmx_func p4led_kn_grp_mt7628[] = {
FUNC("jtag", 3, 30, 1),
- FUNC("util", 2, 30, 1),
+ FUNC("utif", 2, 30, 1),
FUNC("gpio", 1, 30, 1),
FUNC("p4led_kn", 0, 30, 1),
};
static struct rt2880_pmx_func p3led_kn_grp_mt7628[] = {
FUNC("jtag", 3, 31, 1),
- FUNC("util", 2, 31, 1),
+ FUNC("utif", 2, 31, 1),
FUNC("gpio", 1, 31, 1),
FUNC("p3led_kn", 0, 31, 1),
};
static struct rt2880_pmx_func p2led_kn_grp_mt7628[] = {
FUNC("jtag", 3, 32, 1),
- FUNC("util", 2, 32, 1),
+ FUNC("utif", 2, 32, 1),
FUNC("gpio", 1, 32, 1),
FUNC("p2led_kn", 0, 32, 1),
};
static struct rt2880_pmx_func p1led_kn_grp_mt7628[] = {
FUNC("jtag", 3, 33, 1),
- FUNC("util", 2, 33, 1),
+ FUNC("utif", 2, 33, 1),
FUNC("gpio", 1, 33, 1),
FUNC("p1led_kn", 0, 33, 1),
};
@@ -232,28 +232,28 @@ static struct rt2880_pmx_func wled_kn_gr
static struct rt2880_pmx_func p4led_an_grp_mt7628[] = {
FUNC("jtag", 3, 39, 1),
- FUNC("util", 2, 39, 1),
+ FUNC("utif", 2, 39, 1),
FUNC("gpio", 1, 39, 1),
FUNC("p4led_an", 0, 39, 1),
};
static struct rt2880_pmx_func p3led_an_grp_mt7628[] = {
FUNC("jtag", 3, 40, 1),
- FUNC("util", 2, 40, 1),
+ FUNC("utif", 2, 40, 1),
FUNC("gpio", 1, 40, 1),
FUNC("p3led_an", 0, 40, 1),
};
static struct rt2880_pmx_func p2led_an_grp_mt7628[] = {
FUNC("jtag", 3, 41, 1),
- FUNC("util", 2, 41, 1),
+ FUNC("utif", 2, 41, 1),
FUNC("gpio", 1, 41, 1),
FUNC("p2led_an", 0, 41, 1),
};
static struct rt2880_pmx_func p1led_an_grp_mt7628[] = {
FUNC("jtag", 3, 42, 1),
- FUNC("util", 2, 42, 1),
+ FUNC("utif", 2, 42, 1),
FUNC("gpio", 1, 42, 1),
FUNC("p1led_an", 0, 42, 1),
};
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 013/104] MIPS: ralink: Fix incorrect assignment on ralink_soc
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 012/104] MIPS: ralink: Fix a typo in the pinmux setup Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 014/104] power: supply: axp288_fuel_gauge: Fix fuel_gauge_reg_readb return on error Greg Kroah-Hartman
` (89 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Colin Ian King, John Crispin,
linux-mips, Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <colin.king@canonical.com>
[ Upstream commit 08d90c81b714482dceb5323d14f6617bcf55ee61 ]
ralink_soc sould be assigned to RT3883_SOC, replace incorrect
comparision with assignment.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Fixes: 418d29c87061 ("MIPS: ralink: Unify SoC id handling")
Cc: John Crispin <john@phrozen.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14903/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/ralink/rt3883.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/ralink/rt3883.c
+++ b/arch/mips/ralink/rt3883.c
@@ -145,5 +145,5 @@ void prom_soc_init(struct ralink_soc_inf
rt2880_pinmux_data = rt3883_pinmux_data;
- ralink_soc == RT3883_SOC;
+ ralink_soc = RT3883_SOC;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 014/104] power: supply: axp288_fuel_gauge: Fix fuel_gauge_reg_readb return on error
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 013/104] MIPS: ralink: Fix incorrect assignment on ralink_soc Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 015/104] scsi: be2iscsi: Add checks to validate CID alloc/free Greg Kroah-Hartman
` (88 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Sebastian Reichel,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 6f074bc878dc9b00c0df0bf3a8cb1d9e294cd881 ]
If reading the register fails, return the actual error code, instead
of the uninitialized val variable;
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/power/supply/axp288_fuel_gauge.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -169,8 +169,10 @@ static int fuel_gauge_reg_readb(struct a
break;
}
- if (ret < 0)
+ if (ret < 0) {
dev_err(&info->pdev->dev, "axp288 reg read err:%d\n", ret);
+ return ret;
+ }
return val;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 015/104] scsi: be2iscsi: Add checks to validate CID alloc/free
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 014/104] power: supply: axp288_fuel_gauge: Fix fuel_gauge_reg_readb return on error Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 016/104] ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event Greg Kroah-Hartman
` (87 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jitendra Bhivare, Hannes Reinecke,
Martin K. Petersen, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
[ Upstream commit 413f365657a8b9669bd0ba3628e9fde9ce63604e ]
Set CID slot to 0xffff to indicate empty.
Check if connection already exists in conn_table before binding.
Check if endpoint already NULL before putting back CID.
Break ep->conn link in free_ep to ignore completions after freeing.
Signed-off-by: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/be2iscsi/be_iscsi.c | 163 +++++++++++++++++++--------------------
drivers/scsi/be2iscsi/be_main.c | 7 -
drivers/scsi/be2iscsi/be_main.h | 1
3 files changed, 87 insertions(+), 84 deletions(-)
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -166,33 +166,6 @@ beiscsi_conn_create(struct iscsi_cls_ses
}
/**
- * beiscsi_bindconn_cid - Bind the beiscsi_conn with phba connection table
- * @beiscsi_conn: The pointer to beiscsi_conn structure
- * @phba: The phba instance
- * @cid: The cid to free
- */
-static int beiscsi_bindconn_cid(struct beiscsi_hba *phba,
- struct beiscsi_conn *beiscsi_conn,
- unsigned int cid)
-{
- uint16_t cri_index = BE_GET_CRI_FROM_CID(cid);
-
- if (phba->conn_table[cri_index]) {
- beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG,
- "BS_%d : Connection table already occupied. Detected clash\n");
-
- return -EINVAL;
- } else {
- beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
- "BS_%d : phba->conn_table[%d]=%p(beiscsi_conn)\n",
- cri_index, beiscsi_conn);
-
- phba->conn_table[cri_index] = beiscsi_conn;
- }
- return 0;
-}
-
-/**
* beiscsi_conn_bind - Binds iscsi session/connection with TCP connection
* @cls_session: pointer to iscsi cls session
* @cls_conn: pointer to iscsi cls conn
@@ -212,6 +185,7 @@ int beiscsi_conn_bind(struct iscsi_cls_s
struct hwi_wrb_context *pwrb_context;
struct beiscsi_endpoint *beiscsi_ep;
struct iscsi_endpoint *ep;
+ uint16_t cri_index;
ep = iscsi_lookup_endpoint(transport_fd);
if (!ep)
@@ -229,20 +203,34 @@ int beiscsi_conn_bind(struct iscsi_cls_s
return -EEXIST;
}
-
- pwrb_context = &phwi_ctrlr->wrb_context[BE_GET_CRI_FROM_CID(
- beiscsi_ep->ep_cid)];
+ cri_index = BE_GET_CRI_FROM_CID(beiscsi_ep->ep_cid);
+ if (phba->conn_table[cri_index]) {
+ if (beiscsi_conn != phba->conn_table[cri_index] ||
+ beiscsi_ep != phba->conn_table[cri_index]->ep) {
+ __beiscsi_log(phba, KERN_ERR,
+ "BS_%d : conn_table not empty at %u: cid %u conn %p:%p\n",
+ cri_index,
+ beiscsi_ep->ep_cid,
+ beiscsi_conn,
+ phba->conn_table[cri_index]);
+ return -EINVAL;
+ }
+ }
beiscsi_conn->beiscsi_conn_cid = beiscsi_ep->ep_cid;
beiscsi_conn->ep = beiscsi_ep;
beiscsi_ep->conn = beiscsi_conn;
+ /**
+ * Each connection is associated with a WRBQ kept in wrb_context.
+ * Store doorbell offset for transmit path.
+ */
+ pwrb_context = &phwi_ctrlr->wrb_context[cri_index];
beiscsi_conn->doorbell_offset = pwrb_context->doorbell_offset;
-
beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
- "BS_%d : beiscsi_conn=%p conn=%p ep_cid=%d\n",
- beiscsi_conn, conn, beiscsi_ep->ep_cid);
-
- return beiscsi_bindconn_cid(phba, beiscsi_conn, beiscsi_ep->ep_cid);
+ "BS_%d : cid %d phba->conn_table[%u]=%p\n",
+ beiscsi_ep->ep_cid, cri_index, beiscsi_conn);
+ phba->conn_table[cri_index] = beiscsi_conn;
+ return 0;
}
static int beiscsi_iface_create_ipv4(struct beiscsi_hba *phba)
@@ -973,9 +961,9 @@ int beiscsi_conn_start(struct iscsi_cls_
*/
static int beiscsi_get_cid(struct beiscsi_hba *phba)
{
- unsigned short cid = 0xFFFF, cid_from_ulp;
- struct ulp_cid_info *cid_info = NULL;
uint16_t cid_avlbl_ulp0, cid_avlbl_ulp1;
+ unsigned short cid, cid_from_ulp;
+ struct ulp_cid_info *cid_info;
/* Find the ULP which has more CID available */
cid_avlbl_ulp0 = (phba->cid_array_info[BEISCSI_ULP0]) ?
@@ -984,20 +972,27 @@ static int beiscsi_get_cid(struct beiscs
BEISCSI_ULP1_AVLBL_CID(phba) : 0;
cid_from_ulp = (cid_avlbl_ulp0 > cid_avlbl_ulp1) ?
BEISCSI_ULP0 : BEISCSI_ULP1;
+ /**
+ * If iSCSI protocol is loaded only on ULP 0, and when cid_avlbl_ulp
+ * is ZERO for both, ULP 1 is returned.
+ * Check if ULP is loaded before getting new CID.
+ */
+ if (!test_bit(cid_from_ulp, (void *)&phba->fw_config.ulp_supported))
+ return BE_INVALID_CID;
- if (test_bit(cid_from_ulp, (void *)&phba->fw_config.ulp_supported)) {
- cid_info = phba->cid_array_info[cid_from_ulp];
- if (!cid_info->avlbl_cids)
- return cid;
-
- cid = cid_info->cid_array[cid_info->cid_alloc++];
-
- if (cid_info->cid_alloc == BEISCSI_GET_CID_COUNT(
- phba, cid_from_ulp))
- cid_info->cid_alloc = 0;
-
- cid_info->avlbl_cids--;
- }
+ cid_info = phba->cid_array_info[cid_from_ulp];
+ cid = cid_info->cid_array[cid_info->cid_alloc];
+ if (!cid_info->avlbl_cids || cid == BE_INVALID_CID) {
+ __beiscsi_log(phba, KERN_ERR,
+ "BS_%d : failed to get cid: available %u:%u\n",
+ cid_info->avlbl_cids, cid_info->cid_free);
+ return BE_INVALID_CID;
+ }
+ /* empty the slot */
+ cid_info->cid_array[cid_info->cid_alloc++] = BE_INVALID_CID;
+ if (cid_info->cid_alloc == BEISCSI_GET_CID_COUNT(phba, cid_from_ulp))
+ cid_info->cid_alloc = 0;
+ cid_info->avlbl_cids--;
return cid;
}
@@ -1008,22 +1003,28 @@ static int beiscsi_get_cid(struct beiscs
*/
static void beiscsi_put_cid(struct beiscsi_hba *phba, unsigned short cid)
{
- uint16_t cid_post_ulp;
- struct hwi_controller *phwi_ctrlr;
- struct hwi_wrb_context *pwrb_context;
- struct ulp_cid_info *cid_info = NULL;
uint16_t cri_index = BE_GET_CRI_FROM_CID(cid);
+ struct hwi_wrb_context *pwrb_context;
+ struct hwi_controller *phwi_ctrlr;
+ struct ulp_cid_info *cid_info;
+ uint16_t cid_post_ulp;
phwi_ctrlr = phba->phwi_ctrlr;
pwrb_context = &phwi_ctrlr->wrb_context[cri_index];
cid_post_ulp = pwrb_context->ulp_num;
cid_info = phba->cid_array_info[cid_post_ulp];
- cid_info->avlbl_cids++;
-
+ /* fill only in empty slot */
+ if (cid_info->cid_array[cid_info->cid_free] != BE_INVALID_CID) {
+ __beiscsi_log(phba, KERN_ERR,
+ "BS_%d : failed to put cid %u: available %u:%u\n",
+ cid, cid_info->avlbl_cids, cid_info->cid_free);
+ return;
+ }
cid_info->cid_array[cid_info->cid_free++] = cid;
if (cid_info->cid_free == BEISCSI_GET_CID_COUNT(phba, cid_post_ulp))
cid_info->cid_free = 0;
+ cid_info->avlbl_cids++;
}
/**
@@ -1037,8 +1038,8 @@ static void beiscsi_free_ep(struct beisc
beiscsi_put_cid(phba, beiscsi_ep->ep_cid);
beiscsi_ep->phba = NULL;
- phba->ep_array[BE_GET_CRI_FROM_CID
- (beiscsi_ep->ep_cid)] = NULL;
+ /* clear this to track freeing in beiscsi_ep_disconnect */
+ phba->ep_array[BE_GET_CRI_FROM_CID(beiscsi_ep->ep_cid)] = NULL;
/**
* Check if any connection resource allocated by driver
@@ -1049,6 +1050,11 @@ static void beiscsi_free_ep(struct beisc
return;
beiscsi_conn = beiscsi_ep->conn;
+ /**
+ * Break ep->conn link here so that completions after
+ * this are ignored.
+ */
+ beiscsi_ep->conn = NULL;
if (beiscsi_conn->login_in_progress) {
beiscsi_free_mgmt_task_handles(beiscsi_conn,
beiscsi_conn->task);
@@ -1079,7 +1085,7 @@ static int beiscsi_open_conn(struct iscs
"BS_%d : In beiscsi_open_conn\n");
beiscsi_ep->ep_cid = beiscsi_get_cid(phba);
- if (beiscsi_ep->ep_cid == 0xFFFF) {
+ if (beiscsi_ep->ep_cid == BE_INVALID_CID) {
beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG,
"BS_%d : No free cid available\n");
return ret;
@@ -1285,26 +1291,6 @@ static int beiscsi_close_conn(struct be
}
/**
- * beiscsi_unbind_conn_to_cid - Unbind the beiscsi_conn from phba conn table
- * @phba: The phba instance
- * @cid: The cid to free
- */
-static int beiscsi_unbind_conn_to_cid(struct beiscsi_hba *phba,
- unsigned int cid)
-{
- uint16_t cri_index = BE_GET_CRI_FROM_CID(cid);
-
- if (phba->conn_table[cri_index])
- phba->conn_table[cri_index] = NULL;
- else {
- beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
- "BS_%d : Connection table Not occupied.\n");
- return -EINVAL;
- }
- return 0;
-}
-
-/**
* beiscsi_ep_disconnect - Tears down the TCP connection
* @ep: endpoint to be used
*
@@ -1318,13 +1304,23 @@ void beiscsi_ep_disconnect(struct iscsi_
unsigned int tag;
uint8_t mgmt_invalidate_flag, tcp_upload_flag;
unsigned short savecfg_flag = CMD_ISCSI_SESSION_SAVE_CFG_ON_FLASH;
+ uint16_t cri_index;
beiscsi_ep = ep->dd_data;
phba = beiscsi_ep->phba;
beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
- "BS_%d : In beiscsi_ep_disconnect for ep_cid = %d\n",
+ "BS_%d : In beiscsi_ep_disconnect for ep_cid = %u\n",
beiscsi_ep->ep_cid);
+ cri_index = BE_GET_CRI_FROM_CID(beiscsi_ep->ep_cid);
+ if (!phba->ep_array[cri_index]) {
+ __beiscsi_log(phba, KERN_ERR,
+ "BS_%d : ep_array at %u cid %u empty\n",
+ cri_index,
+ beiscsi_ep->ep_cid);
+ return;
+ }
+
if (beiscsi_ep->conn) {
beiscsi_conn = beiscsi_ep->conn;
iscsi_suspend_queue(beiscsi_conn->conn);
@@ -1356,7 +1352,12 @@ void beiscsi_ep_disconnect(struct iscsi_
free_ep:
msleep(BEISCSI_LOGOUT_SYNC_DELAY);
beiscsi_free_ep(beiscsi_ep);
- beiscsi_unbind_conn_to_cid(phba, beiscsi_ep->ep_cid);
+ if (!phba->conn_table[cri_index])
+ __beiscsi_log(phba, KERN_ERR,
+ "BS_%d : conn_table empty at %u: cid %u\n",
+ cri_index,
+ beiscsi_ep->ep_cid);
+ phba->conn_table[cri_index] = NULL;
iscsi_destroy_endpoint(beiscsi_ep->openiscsi_ep);
}
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -4085,9 +4085,10 @@ static int hba_setup_cid_tbls(struct bei
}
/* Allocate memory for CID array */
- ptr_cid_info->cid_array = kzalloc(sizeof(void *) *
- BEISCSI_GET_CID_COUNT(phba,
- ulp_num), GFP_KERNEL);
+ ptr_cid_info->cid_array =
+ kcalloc(BEISCSI_GET_CID_COUNT(phba, ulp_num),
+ sizeof(*ptr_cid_info->cid_array),
+ GFP_KERNEL);
if (!ptr_cid_info->cid_array) {
beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_INIT,
"BM_%d : Failed to allocate memory"
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -358,6 +358,7 @@ struct beiscsi_hba {
unsigned int age;
struct list_head hba_queue;
#define BE_MAX_SESSION 2048
+#define BE_INVALID_CID 0xffff
#define BE_SET_CID_TO_CRI(cri_index, cid) \
(phba->cid_to_cri_map[cid] = cri_index)
#define BE_GET_CRI_FROM_CID(cid) (phba->cid_to_cri_map[cid])
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 016/104] ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 015/104] scsi: be2iscsi: Add checks to validate CID alloc/free Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 017/104] igb: re-assign hw address pointer on reset after PCI error Greg Kroah-Hartman
` (86 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marcin Niestroj, Tony Lindgren, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marcin Niestroj <m.niestroj@grinn-global.com>
[ Upstream commit ca244a83ecc7f0a9242ee2116e622cb6d7ec2a90 ]
On chiliSOM TPS65217 nWAKEUP pin is connected to AM335x internal RTC
EXT_WAKEUP input. In RTC-only state TPS65217 is notifying about power on
events (such as power buton presses) by setting nWAKEUP output
low. After that it waits 5s for proper device boot. Currently it doesn't
happen, as the processor doesn't listen for such events. Consequently
TPS65217 changes state from SLEEP (RTC-only state) to OFF.
Enable EXT_WAKEUP input of AM335x's RTC, so the processor can properly
detect power on events and recover immediately from RTC-only states,
without powering off RTC and losing time.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/am335x-chilisom.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -124,6 +124,14 @@
&rtc {
system-power-controller;
+
+ pinctrl-0 = <&ext_wakeup>;
+ pinctrl-names = "default";
+
+ ext_wakeup: ext-wakeup {
+ pins = "ext_wakeup0";
+ input-enable;
+ };
};
/* NAND Flash */
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 017/104] igb: re-assign hw address pointer on reset after PCI error
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 016/104] ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 018/104] extcon: axp288: Use vbus-valid instead of -present to determine cable presence Greg Kroah-Hartman
` (85 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Anthony H Thai, Harsha Thyagaraja,
Guilherme G Piccoli, Aaron Brown, Jeff Kirsher, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
[ Upstream commit 69b97cf6dbce7403845a28bbc75d57f5be7b12ac ]
Whenever the igb driver detects the result of a read operation returns
a value composed only by F's (like 0xFFFFFFFF), it will detach the
net_device, clear the hw_addr pointer and warn to the user that adapter's
link is lost - those steps happen on igb_rd32().
In case a PCI error happens on Power architecture, there's a recovery
mechanism called EEH, that will reset the PCI slot and call driver's
handlers to reset the adapter and network functionality as well.
We observed that once hw_addr is NULL after the error is detected on
igb_rd32(), it's never assigned back, so in the process of resetting
the network functionality we got a NULL pointer dereference in both
igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid
such bug, this patch re-assigns the hw_addr value in the slot_reset
handler.
Reported-by: Anthony H Thai <ahthai@us.ibm.com>
Reported-by: Harsha Thyagaraja <hathyaga@in.ibm.com>
Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -7882,6 +7882,11 @@ static pci_ers_result_t igb_io_slot_rese
pci_enable_wake(pdev, PCI_D3hot, 0);
pci_enable_wake(pdev, PCI_D3cold, 0);
+ /* In case of PCI error, adapter lose its HW address
+ * so we should re-assign it here.
+ */
+ hw->hw_addr = adapter->io_addr;
+
igb_reset(adapter);
wr32(E1000_WUS, ~0);
result = PCI_ERS_RESULT_RECOVERED;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 018/104] extcon: axp288: Use vbus-valid instead of -present to determine cable presence
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 017/104] igb: re-assign hw address pointer on reset after PCI error Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 019/104] reset: ti_syscon: fix a ti_syscon_reset_status issue Greg Kroah-Hartman
` (84 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Chanwoo Choi, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 5757aca10146061befd168dab37fb0db1ccd8f73 ]
The vbus-present bit in the power status register also gets set to 1
when a usb-host cable (id-pin shorted to ground) is plugged in and a 5v
boost converter is supplying 5v to the otg usb bus.
This causes a "disconnect or unknown or ID event" warning in dmesg as
well as the extcon device to report the last detected charger cable
type as being connected even though none is connected.
This commit switches to checking the vbus-valid bit instead, which is
only 1 when both vbus is present and the vbus-path is enabled in the
vbus-path control register (the vbus-path gets disabled when a usb-host
cable is detected, to avoid the pmic drawing power from the 5v boost
converter).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/extcon/extcon-axp288.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -168,7 +168,7 @@ static int axp288_handle_chrg_det_event(
return ret;
}
- vbus_attach = (pwr_stat & PS_STAT_VBUS_PRESENT);
+ vbus_attach = (pwr_stat & PS_STAT_VBUS_VALID);
if (!vbus_attach)
goto notify_otg;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 019/104] reset: ti_syscon: fix a ti_syscon_reset_status issue
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 018/104] extcon: axp288: Use vbus-valid instead of -present to determine cable presence Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 021/104] clk/axs10x: Clear init field in driver probe Greg Kroah-Hartman
` (83 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiancheng Xue, Philipp Zabel, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiancheng Xue <xuejiancheng@hisilicon.com>
[ Upstream commit 5987b4bf512101137fa60c5c0ccac3db51541221 ]
If STATUS_SET was not set, ti_syscon_reset_status would always return 0
no matter whether the status_bit was set or not.
Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
Fixes: cc7c2bb1493c ("reset: add TI SYSCON based reset driver")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/reset/reset-ti-syscon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/reset/reset-ti-syscon.c
+++ b/drivers/reset/reset-ti-syscon.c
@@ -154,8 +154,8 @@ static int ti_syscon_reset_status(struct
if (ret)
return ret;
- return (reset_state & BIT(control->status_bit)) &&
- (control->flags & STATUS_SET);
+ return !(reset_state & BIT(control->status_bit)) ==
+ !(control->flags & STATUS_SET);
}
static struct reset_control_ops ti_syscon_reset_ops = {
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 021/104] clk/axs10x: Clear init field in driver probe
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 019/104] reset: ti_syscon: fix a ti_syscon_reset_status issue Greg Kroah-Hartman
@ 2017-10-06 8:50 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 022/104] usb: make the MTK XHCI driver compile for older MIPS SoCs Greg Kroah-Hartman
` (82 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:50 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jose Abreu, Carlos Palminha,
Stephen Boyd, Michael Turquette, linux-clk, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jose Abreu <Jose.Abreu@synopsys.com>
[ Upstream commit 6205406cf6f282d622f31de25036e6d1ab3a2ff5 ]
Init field must be cleared in driver probe as this structure is not
dinamically allocated. If not, wrong flags can be passed to core.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Fixes: 923587aafc2c ("clk/axs10x: Add I2S PLL clock driver")
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Link: lkml.kernel.org/r/040cc9afdfa0e95ce7a01c406ff427ef7dc0c0fd.1481540717.git.joabreu@synopsys.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/axs10x/i2s_pll_clock.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/clk/axs10x/i2s_pll_clock.c
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -182,6 +182,7 @@ static int i2s_pll_clk_probe(struct plat
if (IS_ERR(pll_clk->base))
return PTR_ERR(pll_clk->base);
+ memset(&init, 0, sizeof(init));
clk_name = node->name;
init.name = clk_name;
init.ops = &i2s_pll_ops;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 022/104] usb: make the MTK XHCI driver compile for older MIPS SoCs
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2017-10-06 8:50 ` [PATCH 4.9 021/104] clk/axs10x: Clear init field in driver probe Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 023/104] hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes Greg Kroah-Hartman
` (81 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John Crispin, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Crispin <john@phrozen.org>
[ Upstream commit 808cf33d4817c730008de9b2736b357708a3d7f6 ]
The MIPS based MT7621 shares the same XHCI core as the newer generation of
ARM based SoCs. The driver works out of the box and we only need to make it
buildable in Kconfig.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -45,9 +45,9 @@ config USB_XHCI_PLATFORM
If unsure, say N.
config USB_XHCI_MTK
- tristate "xHCI support for Mediatek MT65xx"
+ tristate "xHCI support for Mediatek MT65xx/MT7621"
select MFD_SYSCON
- depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on (MIPS && SOC_MT7621) || ARCH_MEDIATEK || COMPILE_TEST
---help---
Say 'Y' to enable the support for the xHCI host controller
found in Mediatek MT65xx SoCs.
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 023/104] hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 022/104] usb: make the MTK XHCI driver compile for older MIPS SoCs Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 024/104] iio: adc: imx25-gcq: Fix module autoload Greg Kroah-Hartman
` (80 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Guenter Roeck, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <linux@roeck-us.net>
[ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ]
Writes into limit attributes can overflow due to multplications and
additions with unbound input values. Writing into fan limit attributes
can result in a crash with a division by zero if very large values are
written and the fan divider is larger than 1.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/gl520sm.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/drivers/hwmon/gl520sm.c
+++ b/drivers/hwmon/gl520sm.c
@@ -208,11 +208,13 @@ static ssize_t get_cpu_vid(struct device
}
static DEVICE_ATTR(cpu0_vid, S_IRUGO, get_cpu_vid, NULL);
-#define VDD_FROM_REG(val) (((val) * 95 + 2) / 4)
-#define VDD_TO_REG(val) clamp_val((((val) * 4 + 47) / 95), 0, 255)
-
-#define IN_FROM_REG(val) ((val) * 19)
-#define IN_TO_REG(val) clamp_val((((val) + 9) / 19), 0, 255)
+#define VDD_FROM_REG(val) DIV_ROUND_CLOSEST((val) * 95, 4)
+#define VDD_CLAMP(val) clamp_val(val, 0, 255 * 95 / 4)
+#define VDD_TO_REG(val) DIV_ROUND_CLOSEST(VDD_CLAMP(val) * 4, 95)
+
+#define IN_FROM_REG(val) ((val) * 19)
+#define IN_CLAMP(val) clamp_val(val, 0, 255 * 19)
+#define IN_TO_REG(val) DIV_ROUND_CLOSEST(IN_CLAMP(val), 19)
static ssize_t get_in_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -349,8 +351,13 @@ static SENSOR_DEVICE_ATTR(in4_max, S_IRU
#define DIV_FROM_REG(val) (1 << (val))
#define FAN_FROM_REG(val, div) ((val) == 0 ? 0 : (480000 / ((val) << (div))))
-#define FAN_TO_REG(val, div) ((val) <= 0 ? 0 : \
- clamp_val((480000 + ((val) << ((div)-1))) / ((val) << (div)), 1, 255))
+
+#define FAN_BASE(div) (480000 >> (div))
+#define FAN_CLAMP(val, div) clamp_val(val, FAN_BASE(div) / 255, \
+ FAN_BASE(div))
+#define FAN_TO_REG(val, div) ((val) == 0 ? 0 : \
+ DIV_ROUND_CLOSEST(480000, \
+ FAN_CLAMP(val, div) << (div)))
static ssize_t get_fan_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -513,9 +520,9 @@ static SENSOR_DEVICE_ATTR(fan2_div, S_IR
static DEVICE_ATTR(fan1_off, S_IRUGO | S_IWUSR,
get_fan_off, set_fan_off);
-#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
-#define TEMP_TO_REG(val) clamp_val(((((val) < 0 ? \
- (val) - 500 : (val) + 500) / 1000) + 130), 0, 255)
+#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
+#define TEMP_CLAMP(val) clamp_val(val, -130000, 125000)
+#define TEMP_TO_REG(val) (DIV_ROUND_CLOSEST(TEMP_CLAMP(val), 1000) + 130)
static ssize_t get_temp_input(struct device *dev, struct device_attribute *attr,
char *buf)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 024/104] iio: adc: imx25-gcq: Fix module autoload
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 023/104] hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 025/104] iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications Greg Kroah-Hartman
` (79 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Javier Martinez Canillas,
Jonathan Cameron, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Martinez Canillas <javier@osg.samsung.com>
[ Upstream commit 8f0d7daf53972da0004f7a5a4d938c85333db300 ]
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
$
After this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
alias: of:N*T*Cfsl,imx25-gcqC*
alias: of:N*T*Cfsl,imx25-gcq
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/fsl-imx25-gcq.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/fsl-imx25-gcq.c
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -401,6 +401,7 @@ static const struct of_device_id mx25_gc
{ .compatible = "fsl,imx25-gcq", },
{ /* Sentinel */ }
};
+MODULE_DEVICE_TABLE(of, mx25_gcq_ids);
static struct platform_driver mx25_gcq_driver = {
.driver = {
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 025/104] iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 024/104] iio: adc: imx25-gcq: Fix module autoload Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 026/104] iio: adc: hx711: Add DT binding for avia,hx711 Greg Kroah-Hartman
` (78 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Chen-Yu Tsai,
Jonathan Cameron, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit fa2849e9649b5180ffc4cb3c3b005261c403093a ]
For some reason the axp288_adc driver was modifying the
AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on
whether the GP_ADC channel or another channel was written.
These bits control when a bias current is send to the TS_PIN, the
GP_ADC has its own pin and a separate bit in another register to
control the bias current.
Not only does changing when to enable the TS_PIN bias current
(always or only when sampling) when reading the GP_ADC make no sense
at all, the code is modifying these bits is writing the entire register,
assuming that all the other bits have their default value.
So if the firmware has configured a different bias-current for either
pin, then that change gets clobbered by the write, likewise if the
firmware has set bit 2 to indicate that the battery has no thermal sensor,
this will get clobbered by the write.
This commit fixes all this, by simply removing all writes to the
AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the
GP_ADC pin, and can actually be harmful.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/axp288_adc.c | 32 +-------------------------------
1 file changed, 1 insertion(+), 31 deletions(-)
--- a/drivers/iio/adc/axp288_adc.c
+++ b/drivers/iio/adc/axp288_adc.c
@@ -28,8 +28,6 @@
#include <linux/iio/driver.h>
#define AXP288_ADC_EN_MASK 0xF1
-#define AXP288_ADC_TS_PIN_GPADC 0xF2
-#define AXP288_ADC_TS_PIN_ON 0xF3
enum axp288_adc_id {
AXP288_ADC_TS,
@@ -123,16 +121,6 @@ static int axp288_adc_read_channel(int *
return IIO_VAL_INT;
}
-static int axp288_adc_set_ts(struct regmap *regmap, unsigned int mode,
- unsigned long address)
-{
- /* channels other than GPADC do not need to switch TS pin */
- if (address != AXP288_GP_ADC_H)
- return 0;
-
- return regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL, mode);
-}
-
static int axp288_adc_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val, int *val2, long mask)
@@ -143,16 +131,7 @@ static int axp288_adc_read_raw(struct ii
mutex_lock(&indio_dev->mlock);
switch (mask) {
case IIO_CHAN_INFO_RAW:
- if (axp288_adc_set_ts(info->regmap, AXP288_ADC_TS_PIN_GPADC,
- chan->address)) {
- dev_err(&indio_dev->dev, "GPADC mode\n");
- ret = -EINVAL;
- break;
- }
ret = axp288_adc_read_channel(val, chan->address, info->regmap);
- if (axp288_adc_set_ts(info->regmap, AXP288_ADC_TS_PIN_ON,
- chan->address))
- dev_err(&indio_dev->dev, "TS pin restore\n");
break;
default:
ret = -EINVAL;
@@ -162,15 +141,6 @@ static int axp288_adc_read_raw(struct ii
return ret;
}
-static int axp288_adc_set_state(struct regmap *regmap)
-{
- /* ADC should be always enabled for internal FG to function */
- if (regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL, AXP288_ADC_TS_PIN_ON))
- return -EIO;
-
- return regmap_write(regmap, AXP20X_ADC_EN1, AXP288_ADC_EN_MASK);
-}
-
static const struct iio_info axp288_adc_iio_info = {
.read_raw = &axp288_adc_read_raw,
.driver_module = THIS_MODULE,
@@ -199,7 +169,7 @@ static int axp288_adc_probe(struct platf
* Set ADC to enabled state at all time, including system suspend.
* otherwise internal fuel gauge functionality may be affected.
*/
- ret = axp288_adc_set_state(axp20x->regmap);
+ ret = regmap_write(info->regmap, AXP20X_ADC_EN1, AXP288_ADC_EN_MASK);
if (ret) {
dev_err(&pdev->dev, "unable to enable ADC device\n");
return ret;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 026/104] iio: adc: hx711: Add DT binding for avia,hx711
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 025/104] iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 027/104] IB/rxe: Add a runtime check in alloc_index() Greg Kroah-Hartman
` (77 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andreas Klinger, Rob Herring,
Jonathan Cameron, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Klinger <ak@it-klinger.de>
[ Upstream commit ff1293f67734da68e23fecb6ecdae7112b8c43f9 ]
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 18 +++++++++++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,18 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+ - avdd-supply: Definition of the regulator used as analog supply
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ avdd-suppy = <&avdd>;
+};
+
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -38,6 +38,7 @@ atmel Atmel Corporation
auo AU Optronics Corporation
auvidea Auvidea GmbH
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
boe BOE Technology Group Co., Ltd.
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 027/104] IB/rxe: Add a runtime check in alloc_index()
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 026/104] iio: adc: hx711: Add DT binding for avia,hx711 Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 028/104] IB/rxe: Fix a MR reference leak in check_rkey() Greg Kroah-Hartman
` (76 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bart Van Assche, Andrew Boyer,
Moni Shoua, Doug Ledford, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <bart.vanassche@sandisk.com>
[ Upstream commit 642c7cbcaf2ffc1e27f67eda3dc47347ac5aff37 ]
Since index values equal to or above 'range' can trigger memory
corruption, complain if index >= range.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Andrew Boyer <andrew.boyer@dell.com>
Cc: Moni Shoua <monis@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/sw/rxe/rxe_pool.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/infiniband/sw/rxe/rxe_pool.c
+++ b/drivers/infiniband/sw/rxe/rxe_pool.c
@@ -274,6 +274,7 @@ static u32 alloc_index(struct rxe_pool *
if (index >= range)
index = find_first_zero_bit(pool->table, range);
+ WARN_ON_ONCE(index >= range);
set_bit(index, pool->table);
pool->last = index;
return index + pool->min_index;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 028/104] IB/rxe: Fix a MR reference leak in check_rkey()
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 027/104] IB/rxe: Add a runtime check in alloc_index() Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 029/104] ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM Greg Kroah-Hartman
` (75 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bart Van Assche, Andrew Boyer,
Moni Shoua, Doug Ledford, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <bart.vanassche@sandisk.com>
[ Upstream commit b3a459961014b14c267544c327db033669493295 ]
Avoid that calling check_rkey() for mem->state == RXE_MEM_STATE_FREE
triggers an MR reference leak.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Andrew Boyer <andrew.boyer@dell.com>
Cc: Moni Shoua <monis@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/sw/rxe/rxe_resp.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -418,7 +418,7 @@ static enum resp_states check_length(str
static enum resp_states check_rkey(struct rxe_qp *qp,
struct rxe_pkt_info *pkt)
{
- struct rxe_mem *mem;
+ struct rxe_mem *mem = NULL;
u64 va;
u32 rkey;
u32 resid;
@@ -452,38 +452,38 @@ static enum resp_states check_rkey(struc
mem = lookup_mem(qp->pd, access, rkey, lookup_remote);
if (!mem) {
state = RESPST_ERR_RKEY_VIOLATION;
- goto err1;
+ goto err;
}
if (unlikely(mem->state == RXE_MEM_STATE_FREE)) {
state = RESPST_ERR_RKEY_VIOLATION;
- goto err1;
+ goto err;
}
if (mem_check_range(mem, va, resid)) {
state = RESPST_ERR_RKEY_VIOLATION;
- goto err2;
+ goto err;
}
if (pkt->mask & RXE_WRITE_MASK) {
if (resid > mtu) {
if (pktlen != mtu || bth_pad(pkt)) {
state = RESPST_ERR_LENGTH;
- goto err2;
+ goto err;
}
qp->resp.resid = mtu;
} else {
if (pktlen != resid) {
state = RESPST_ERR_LENGTH;
- goto err2;
+ goto err;
}
if ((bth_pad(pkt) != (0x3 & (-resid)))) {
/* This case may not be exactly that
* but nothing else fits.
*/
state = RESPST_ERR_LENGTH;
- goto err2;
+ goto err;
}
}
}
@@ -493,9 +493,9 @@ static enum resp_states check_rkey(struc
qp->resp.mr = mem;
return RESPST_EXECUTE;
-err2:
- rxe_drop_ref(mem);
-err1:
+err:
+ if (mem)
+ rxe_drop_ref(mem);
return state;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 029/104] ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 028/104] IB/rxe: Fix a MR reference leak in check_rkey() Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 030/104] drm/i915/psr: disable psr2 for resolution greater than 32X20 Greg Kroah-Hartman
` (74 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Afzal Mohammed, Vladimir Murzin,
Russell King, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
[ Upstream commit 8a792e9afbce84a0fdaf213fe42bb97382487094 ]
REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
available to Kconfig, DRAM_BASE also is available as the Kconfig
gets sourced on !MMU.
Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/Kconfig-nommu | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/Kconfig-nommu
+++ b/arch/arm/Kconfig-nommu
@@ -34,8 +34,7 @@ config PROCESSOR_ID
used instead of the auto-probing which utilizes the register.
config REMAP_VECTORS_TO_RAM
- bool 'Install vectors to the beginning of RAM' if DRAM_BASE
- depends on DRAM_BASE
+ bool 'Install vectors to the beginning of RAM'
help
The kernel needs to change the hardware exception vectors.
In nommu mode, the hardware exception vectors are normally
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 030/104] drm/i915/psr: disable psr2 for resolution greater than 32X20
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 029/104] ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 031/104] serial: 8250: moxa: Store num_ports in brd Greg Kroah-Hartman
` (73 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rodrigo Vivi, Jim Bride,
Vathsala Nagaraju, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Nagaraju, Vathsala" <vathsala.nagaraju@intel.com>
[ Upstream commit acf45d11050abd751dcec986ab121cb2367dcbba ]
PSR2 is restricted to work with panel resolutions upto 3200x2000,
move the check to intel_psr_match_conditions and fully block psr.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484031746-20874-1-git-send-email-vathsala.nagaraju@intel.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_psr.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -387,6 +387,13 @@ static bool intel_psr_match_conditions(s
return false;
}
+ /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
+ if (intel_crtc->config->pipe_src_w > 3200 ||
+ intel_crtc->config->pipe_src_h > 2000) {
+ dev_priv->psr.psr2_support = false;
+ return false;
+ }
+
dev_priv->psr.source_ok = true;
return true;
}
@@ -425,7 +432,6 @@ void intel_psr_enable(struct intel_dp *i
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
if (!HAS_PSR(dev)) {
DRM_DEBUG_KMS("PSR not supported on this platform\n");
@@ -452,12 +458,7 @@ void intel_psr_enable(struct intel_dp *i
hsw_psr_setup_vsc(intel_dp);
if (dev_priv->psr.psr2_support) {
- /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
- if (crtc->config->pipe_src_w > 3200 ||
- crtc->config->pipe_src_h > 2000)
- dev_priv->psr.psr2_support = false;
- else
- skl_psr_setup_su_vsc(intel_dp);
+ skl_psr_setup_su_vsc(intel_dp);
}
/*
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 031/104] serial: 8250: moxa: Store num_ports in brd
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 030/104] drm/i915/psr: disable psr2 for resolution greater than 32X20 Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 032/104] tty: goldfish: Fix a parameter of a call to free_irq Greg Kroah-Hartman
` (72 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Matwey V. Kornilov, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matwey V. Kornilov" <matwey@sai.msu.ru>
[ Upstream commit 9c4b60fe5313c125b1bf68ef04b0010512c27f2d ]
When struct moxa8250_board is allocated, then num_ports should
be initialized in order to use it later in moxa8250_remove.
Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/8250/8250_moxa.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/tty/serial/8250/8250_moxa.c
+++ b/drivers/tty/serial/8250/8250_moxa.c
@@ -68,6 +68,7 @@ static int moxa8250_probe(struct pci_dev
sizeof(unsigned int) * nr_ports, GFP_KERNEL);
if (!brd)
return -ENOMEM;
+ brd->num_ports = nr_ports;
memset(&uart, 0, sizeof(struct uart_8250_port));
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 032/104] tty: goldfish: Fix a parameter of a call to free_irq
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 031/104] serial: 8250: moxa: Store num_ports in brd Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 033/104] serial: 8250_port: Remove dangerous pr_debug() Greg Kroah-Hartman
` (71 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Christophe JAILLET, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
[ Upstream commit 1a5c2d1de7d35f5eb9793266237903348989502b ]
'request_irq()' and 'free_irq()' should be called with the same dev_id.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/goldfish.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/goldfish.c
+++ b/drivers/tty/goldfish.c
@@ -300,7 +300,7 @@ static int goldfish_tty_probe(struct pla
return 0;
err_tty_register_device_failed:
- free_irq(irq, pdev);
+ free_irq(irq, qtty);
err_request_irq_failed:
goldfish_tty_current_line_count--;
if (goldfish_tty_current_line_count == 0)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 033/104] serial: 8250_port: Remove dangerous pr_debug()
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 032/104] tty: goldfish: Fix a parameter of a call to free_irq Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 034/104] IB/ipoib: Fix deadlock over vlan_mutex Greg Kroah-Hartman
` (70 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexey Brodkin, Jiri Slaby,
Peter Hurley, Phillip Raffeck, Anton Wuerfel, Matwey V. Kornilov,
Yegor Yefremov, Thor Thayer, Andy Shevchenko, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
[ Upstream commit 699a11ba7ec869b006623182881f2f1f5b4aea53 ]
With CONFIG_DYNAMIC_DEBUG if dyndbg enables debug output in
8250_port.c deadlock happens inevitably on UART IRQ handling.
That's the problematic execution path:
---------------------------->8------------------------
UART IRQ:
serial8250_interrupt() ->
serial8250_handle_irq(): lock "port->lock" ->
pr_debug() ->
serial8250_console_write(): bump in locked "port->lock".
OR (if above pr_debug() gets removed):
serial8250_tx_chars() ->
pr_debug() ->
serial8250_console_write(): bump in locked "port->lock".
---------------------------->8------------------------
So let's get rid of those not that much useful debug entries.
Discussed problem could be easily reproduced with QEMU for x86_64.
As well as this fix could be mimicked with muting of dynamic debug for
the problematic lines as simple as:
---------------------------->8------------------------
dyndbg="+p; file 8250_port.c line 1756 -p; file 8250_port.c line 1822 -p"
---------------------------->8------------------------
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Phillip Raffeck <phillip.raffeck@fau.de>
Cc: Anton Wuerfel <anton.wuerfel@fau.de>
Cc: "Matwey V. Kornilov" <matwey@sai.msu.ru>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Thor Thayer <tthayer@opensource.altera.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 4 ----
1 file changed, 4 deletions(-)
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1751,8 +1751,6 @@ void serial8250_tx_chars(struct uart_825
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(port);
- pr_debug("%s: THRE\n", __func__);
-
/*
* With RPM enabled, we have to wait until the FIFO is empty before the
* HW can go idle. So we get here once again with empty FIFO and disable
@@ -1817,8 +1815,6 @@ int serial8250_handle_irq(struct uart_po
status = serial_port_in(port, UART_LSR);
- pr_debug("%s: status = %x\n", __func__, status);
-
if (status & (UART_LSR_DR | UART_LSR_BI)) {
if (!up->dma || handle_rx_dma(up, iir))
status = serial8250_rx_chars(up, status);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 034/104] IB/ipoib: Fix deadlock over vlan_mutex
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 033/104] serial: 8250_port: Remove dangerous pr_debug() Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 035/104] IB/ipoib: rtnl_unlock can not come after free_netdev Greg Kroah-Hartman
` (69 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Feras Daoud, Erez Shitrit,
Alex Vesker, Leon Romanovsky, Doug Ledford, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 1c3098cdb05207e740715857df7b0998e372f527 ]
This patch fixes Deadlock while executing ipoib_vlan_delete.
The function takes the vlan_rwsem semaphore and calls
unregister_netdevice. The later function calls
ipoib_mcast_stop_thread that cause workqueue flush.
When the queue has one of the ipoib_ib_dev_flush_xxx events,
a deadlock occur because these events also tries to catch the
same vlan_rwsem semaphore.
To fix, unregister_netdevice should be called after releasing
the semaphore.
Fixes: cbbe1efa4972 ("IPoIB: Fix deadlock between ipoib_open() and child interface create")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -193,7 +193,6 @@ int ipoib_vlan_delete(struct net_device
list_for_each_entry_safe(priv, tpriv, &ppriv->child_intfs, list) {
if (priv->pkey == pkey &&
priv->child_type == IPOIB_LEGACY_CHILD) {
- unregister_netdevice(priv->dev);
list_del(&priv->list);
dev = priv->dev;
break;
@@ -201,6 +200,11 @@ int ipoib_vlan_delete(struct net_device
}
up_write(&ppriv->vlan_rwsem);
+ if (dev) {
+ ipoib_dbg(ppriv, "delete child vlan %s\n", dev->name);
+ unregister_netdevice(dev);
+ }
+
rtnl_unlock();
if (dev) {
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 035/104] IB/ipoib: rtnl_unlock can not come after free_netdev
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 034/104] IB/ipoib: Fix deadlock over vlan_mutex Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 036/104] IB/ipoib: Replace list_del of the neigh->list with list_del_init Greg Kroah-Hartman
` (68 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Or Gerlitz, Feras Daoud,
Erez Shitrit, Yuval Shaia, Leon Romanovsky, Doug Ledford,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 89a3987ab7a923c047c6dec008e60ad6f41fac22 ]
The ipoib_vlan_add function calls rtnl_unlock after free_netdev,
rtnl_unlock not only releases the lock, but also calls netdev_run_todo.
The latter function browses the net_todo_list array and completes the
unregistration of all its net_device instances. If we call free_netdev
before rtnl_unlock, then netdev_run_todo call over the freed device causes
panic.
To fix, move rtnl_unlock call before free_netdev call.
Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -165,11 +165,11 @@ int ipoib_vlan_add(struct net_device *pd
out:
up_write(&ppriv->vlan_rwsem);
+ rtnl_unlock();
+
if (result)
free_netdev(priv->dev);
- rtnl_unlock();
-
return result;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 036/104] IB/ipoib: Replace list_del of the neigh->list with list_del_init
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 035/104] IB/ipoib: rtnl_unlock can not come after free_netdev Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 037/104] arm: dts: mt2701: Add subsystem clock controller device nodes Greg Kroah-Hartman
` (67 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Feras Daoud, Erez Shitrit,
Alex Vesker, Leon Romanovsky, Yuval Shaia, Doug Ledford,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit c586071d1dc8227a7182179b8e50ee92cc43f6d2 ]
In order to resolve a situation where a few process delete
the same list element in sequence and cause panic, list_del
is replaced with list_del_init. In this case if the first
process that calls list_del releases the lock before acquiring
it again, other processes who can acquire the lock will call
list_del_init.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1302,7 +1302,7 @@ static void __ipoib_reap_neigh(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1466,7 +1466,7 @@ void ipoib_neigh_free(struct ipoib_neigh
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
return;
} else {
@@ -1551,7 +1551,7 @@ void ipoib_del_neighs_by_gid(struct net_
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1593,7 +1593,7 @@ static void ipoib_flush_neighs(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
}
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 037/104] arm: dts: mt2701: Add subsystem clock controller device nodes
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 036/104] IB/ipoib: Replace list_del of the neigh->list with list_del_init Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 038/104] drm/amdkfd: fix improper return value on error Greg Kroah-Hartman
` (66 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, James Liao, Matthias Brugger, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Liao <jamesjj.liao@mediatek.com>
[ Upstream commit f235c7e7a75325f28a33559a71f25a0eca6112db ]
Add MT2701 subsystem clock controllers, inlcude mmsys, imgsys,
vdecsys, hifsys, ethsys and bdpsys.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/mt2701.dtsi | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -174,4 +174,40 @@
clocks = <&uart_clk>;
status = "disabled";
};
+
+ mmsys: syscon@14000000 {
+ compatible = "mediatek,mt2701-mmsys", "syscon";
+ reg = <0 0x14000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: syscon@15000000 {
+ compatible = "mediatek,mt2701-imgsys", "syscon";
+ reg = <0 0x15000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: syscon@16000000 {
+ compatible = "mediatek,mt2701-vdecsys", "syscon";
+ reg = <0 0x16000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ hifsys: syscon@1a000000 {
+ compatible = "mediatek,mt2701-hifsys", "syscon";
+ reg = <0 0x1a000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ethsys: syscon@1b000000 {
+ compatible = "mediatek,mt2701-ethsys", "syscon";
+ reg = <0 0x1b000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ bdpsys: syscon@1c000000 {
+ compatible = "mediatek,mt2701-bdpsys", "syscon";
+ reg = <0 0x1c000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
};
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 038/104] drm/amdkfd: fix improper return value on error
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 037/104] arm: dts: mt2701: Add subsystem clock controller device nodes Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 039/104] USB: serial: mos7720: fix control-message error handling Greg Kroah-Hartman
` (65 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pan Bian, Oded Gabbay, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pan Bian <bianpan2016@163.com>
[ Upstream commit 8bf793883da213864efc50c274d2b38ec0ca58b2 ]
In function kfd_wait_on_events(), when the call to copy_from_user()
fails, the value of return variable ret is 0. 0 indicates success, which
is inconsistent with the execution status. This patch fixes the bug by
assigning "-EFAULT" to ret when copy_from_user() returns an unexpected
value.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
@@ -739,8 +739,10 @@ int kfd_wait_on_events(struct kfd_proces
struct kfd_event_data event_data;
if (copy_from_user(&event_data, &events[i],
- sizeof(struct kfd_event_data)))
+ sizeof(struct kfd_event_data))) {
+ ret = -EFAULT;
goto fail;
+ }
ret = init_event_waiter(p, &event_waiters[i],
event_data.event_id, i);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 039/104] USB: serial: mos7720: fix control-message error handling
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 038/104] drm/amdkfd: fix improper return value on error Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 040/104] USB: serial: mos7840: " Greg Kroah-Hartman
` (64 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
[ Upstream commit 0d130367abf582e7cbf60075c2a7ab53817b1d14 ]
Make sure to log an error on short transfers when reading a device
register.
Also clear the provided buffer (which if often an uninitialised
automatic variable) on errors as the driver currently does not bother to
check for errors.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/mos7720.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -234,11 +234,16 @@ static int read_mos_reg(struct usb_seria
status = usb_control_msg(usbdev, pipe, request, requesttype, value,
index, buf, 1, MOS_WDR_TIMEOUT);
- if (status == 1)
+ if (status == 1) {
*data = *buf;
- else if (status < 0)
+ } else {
dev_err(&usbdev->dev,
"mos7720: usb_control_msg() failed: %d\n", status);
+ if (status >= 0)
+ status = -EIO;
+ *data = 0;
+ }
+
kfree(buf);
return status;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 040/104] USB: serial: mos7840: fix control-message error handling
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 039/104] USB: serial: mos7720: fix control-message error handling Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 041/104] sfc: get PIO buffer size from the NIC Greg Kroah-Hartman
` (63 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
[ Upstream commit cd8db057e93ddaacbec025b567490555d2bca280 ]
Make sure to detect short transfers when reading a device register.
The modem-status handling had sufficient error checks in place, but move
handling of short transfers into the register accessor function itself
for consistency.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/mos7840.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -285,9 +285,15 @@ static int mos7840_get_reg_sync(struct u
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), MCS_RDREQ,
MCS_RD_RTYPE, 0, reg, buf, VENDOR_READ_LENGTH,
MOS_WDR_TIMEOUT);
+ if (ret < VENDOR_READ_LENGTH) {
+ if (ret >= 0)
+ ret = -EIO;
+ goto out;
+ }
+
*val = buf[0];
dev_dbg(&port->dev, "%s offset is %x, return val %x\n", __func__, reg, *val);
-
+out:
kfree(buf);
return ret;
}
@@ -353,8 +359,13 @@ static int mos7840_get_uart_reg(struct u
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), MCS_RDREQ,
MCS_RD_RTYPE, Wval, reg, buf, VENDOR_READ_LENGTH,
MOS_WDR_TIMEOUT);
+ if (ret < VENDOR_READ_LENGTH) {
+ if (ret >= 0)
+ ret = -EIO;
+ goto out;
+ }
*val = buf[0];
-
+out:
kfree(buf);
return ret;
}
@@ -1490,10 +1501,10 @@ static int mos7840_tiocmget(struct tty_s
return -ENODEV;
status = mos7840_get_uart_reg(port, MODEM_STATUS_REGISTER, &msr);
- if (status != 1)
+ if (status < 0)
return -EIO;
status = mos7840_get_uart_reg(port, MODEM_CONTROL_REGISTER, &mcr);
- if (status != 1)
+ if (status < 0)
return -EIO;
result = ((mcr & MCR_DTR) ? TIOCM_DTR : 0)
| ((mcr & MCR_RTS) ? TIOCM_RTS : 0)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 041/104] sfc: get PIO buffer size from the NIC
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 040/104] USB: serial: mos7840: " Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 042/104] pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show() Greg Kroah-Hartman
` (62 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Edward Cree, David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Edward Cree <ecree@solarflare.com>
[ Upstream commit c634700f7eec3c0da46e299cd0a0ae8b594f9b55 ]
The 8000 series SFC NICs have 4K PIO buffers, rather than the 2K of
the 7000 series. Rather than having a hard-coded PIO buffer size
(ER_DZ_TX_PIOBUF_SIZE), read it from the GET_CAPABILITIES_V2 MCDI
response.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/sfc/ef10.c | 16 ++++++++++------
drivers/net/ethernet/sfc/nic.h | 2 ++
drivers/net/ethernet/sfc/tx.c | 1 -
3 files changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -197,11 +197,15 @@ static int efx_ef10_init_datapath_caps(s
nic_data->datapath_caps =
MCDI_DWORD(outbuf, GET_CAPABILITIES_OUT_FLAGS1);
- if (outlen >= MC_CMD_GET_CAPABILITIES_V2_OUT_LEN)
+ if (outlen >= MC_CMD_GET_CAPABILITIES_V2_OUT_LEN) {
nic_data->datapath_caps2 = MCDI_DWORD(outbuf,
GET_CAPABILITIES_V2_OUT_FLAGS2);
- else
+ nic_data->piobuf_size = MCDI_WORD(outbuf,
+ GET_CAPABILITIES_V2_OUT_SIZE_PIO_BUFF);
+ } else {
nic_data->datapath_caps2 = 0;
+ nic_data->piobuf_size = ER_DZ_TX_PIOBUF_SIZE;
+ }
/* record the DPCPU firmware IDs to determine VEB vswitching support.
*/
@@ -825,8 +829,8 @@ static int efx_ef10_link_piobufs(struct
offset = ((efx->tx_channel_offset + efx->n_tx_channels -
tx_queue->channel->channel - 1) *
efx_piobuf_size);
- index = offset / ER_DZ_TX_PIOBUF_SIZE;
- offset = offset % ER_DZ_TX_PIOBUF_SIZE;
+ index = offset / nic_data->piobuf_size;
+ offset = offset % nic_data->piobuf_size;
/* When the host page size is 4K, the first
* host page in the WC mapping may be within
@@ -1161,11 +1165,11 @@ static int efx_ef10_dimension_resources(
* functions of the controller.
*/
if (efx_piobuf_size != 0 &&
- ER_DZ_TX_PIOBUF_SIZE / efx_piobuf_size * EF10_TX_PIOBUF_COUNT >=
+ nic_data->piobuf_size / efx_piobuf_size * EF10_TX_PIOBUF_COUNT >=
efx->n_tx_channels) {
unsigned int n_piobufs =
DIV_ROUND_UP(efx->n_tx_channels,
- ER_DZ_TX_PIOBUF_SIZE / efx_piobuf_size);
+ nic_data->piobuf_size / efx_piobuf_size);
rc = efx_ef10_alloc_piobufs(efx, n_piobufs);
if (rc)
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -500,6 +500,7 @@ enum {
* @pio_write_base: Base address for writing PIO buffers
* @pio_write_vi_base: Relative VI number for @pio_write_base
* @piobuf_handle: Handle of each PIO buffer allocated
+ * @piobuf_size: size of a single PIO buffer
* @must_restore_piobufs: Flag: PIO buffers have yet to be restored after MC
* reboot
* @rx_rss_context: Firmware handle for our RSS context
@@ -537,6 +538,7 @@ struct efx_ef10_nic_data {
void __iomem *wc_membase, *pio_write_base;
unsigned int pio_write_vi_base;
unsigned int piobuf_handle[EF10_TX_PIOBUF_COUNT];
+ u16 piobuf_size;
bool must_restore_piobufs;
u32 rx_rss_context;
bool rx_rss_context_exclusive;
--- a/drivers/net/ethernet/sfc/tx.c
+++ b/drivers/net/ethernet/sfc/tx.c
@@ -27,7 +27,6 @@
#ifdef EFX_USE_PIO
-#define EFX_PIOBUF_SIZE_MAX ER_DZ_TX_PIOBUF_SIZE
#define EFX_PIOBUF_SIZE_DEF ALIGN(256, L1_CACHE_BYTES)
unsigned int efx_piobuf_size __read_mostly = EFX_PIOBUF_SIZE_DEF;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 042/104] pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 041/104] sfc: get PIO buffer size from the NIC Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 043/104] partitions/efi: Fix integer overflow in GPT size calculation Greg Kroah-Hartman
` (61 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Markus Elfring, Linus Walleij, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Elfring <elfring@users.sourceforge.net>
[ Upstream commit 420dc61642920849d824a0de2aa853db59f5244f ]
Strings which did not contain data format specifications should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -195,11 +195,12 @@ static void mvebu_pinconf_group_dbg_show
seq_printf(s, "o");
seq_printf(s, ")");
}
- } else
- seq_printf(s, "current: UNKNOWN");
+ } else {
+ seq_puts(s, "current: UNKNOWN");
+ }
if (grp->num_settings > 1) {
- seq_printf(s, ", available = [");
+ seq_puts(s, ", available = [");
for (n = 0; n < grp->num_settings; n++) {
if (curr == &grp->settings[n])
continue;
@@ -222,7 +223,7 @@ static void mvebu_pinconf_group_dbg_show
seq_printf(s, ")");
}
}
- seq_printf(s, " ]");
+ seq_puts(s, " ]");
}
return;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 043/104] partitions/efi: Fix integer overflow in GPT size calculation
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 042/104] pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show() Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 044/104] ASoC: dapm: handle probe deferrals Greg Kroah-Hartman
` (60 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alden Tondettar, Ard Biesheuvel,
Jens Axboe, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alden Tondettar <alden.tondettar@gmail.com>
[ Upstream commit c5082b70adfe8e1ea1cf4a8eff92c9f260e364d2 ]
If a GUID Partition Table claims to have more than 2**25 entries, the
calculation of the partition table size in alloc_read_gpt_entries() will
overflow a 32-bit integer and not enough space will be allocated for the
table.
Nothing seems to get written out of bounds, but later efi_partition() will
read up to 32768 bytes from a 128 byte buffer, possibly OOPSing or exposing
information to /proc/partitions and uevents.
The problem exists on both 64-bit and 32-bit platforms.
Fix the overflow and also print a meaningful debug message if the table
size is too large.
Signed-off-by: Alden Tondettar <alden.tondettar@gmail.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/partitions/efi.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -293,7 +293,7 @@ static gpt_entry *alloc_read_gpt_entries
if (!gpt)
return NULL;
- count = le32_to_cpu(gpt->num_partition_entries) *
+ count = (size_t)le32_to_cpu(gpt->num_partition_entries) *
le32_to_cpu(gpt->sizeof_partition_entry);
if (!count)
return NULL;
@@ -352,7 +352,7 @@ static int is_gpt_valid(struct parsed_pa
gpt_header **gpt, gpt_entry **ptes)
{
u32 crc, origcrc;
- u64 lastlba;
+ u64 lastlba, pt_size;
if (!ptes)
return 0;
@@ -434,13 +434,20 @@ static int is_gpt_valid(struct parsed_pa
goto fail;
}
+ /* Sanity check partition table size */
+ pt_size = (u64)le32_to_cpu((*gpt)->num_partition_entries) *
+ le32_to_cpu((*gpt)->sizeof_partition_entry);
+ if (pt_size > KMALLOC_MAX_SIZE) {
+ pr_debug("GUID Partition Table is too large: %llu > %lu bytes\n",
+ (unsigned long long)pt_size, KMALLOC_MAX_SIZE);
+ goto fail;
+ }
+
if (!(*ptes = alloc_read_gpt_entries(state, *gpt)))
goto fail;
/* Check the GUID Partition Entry Array CRC */
- crc = efi_crc32((const unsigned char *) (*ptes),
- le32_to_cpu((*gpt)->num_partition_entries) *
- le32_to_cpu((*gpt)->sizeof_partition_entry));
+ crc = efi_crc32((const unsigned char *) (*ptes), pt_size);
if (crc != le32_to_cpu((*gpt)->partition_entry_array_crc32)) {
pr_debug("GUID Partition Entry Array CRC check failed.\n");
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 044/104] ASoC: dapm: handle probe deferrals
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 043/104] partitions/efi: Fix integer overflow in GPT size calculation Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 045/104] audit: log 32-bit socketcalls Greg Kroah-Hartman
` (59 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Linus Walleij, Mark Brown, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <linus.walleij@linaro.org>
[ Upstream commit 37e1df8c95e2c8a57c77eafc097648f6e40a60ff ]
This starts to handle probe deferrals on regulators and clocks
on the ASoC DAPM.
I came to this patch after audio stopped working on Ux500 ages
ago and I finally looked into it to see what is wrong. I had
messages like this in the console since a while back:
ab8500-codec.0: ASoC: Failed to request audioclk: -517
ab8500-codec.0: ASoC: Failed to create DAPM control audioclk
ab8500-codec.0: Failed to create new controls -12
snd-soc-mop500.0: ASoC: failed to instantiate card -12
snd-soc-mop500.0: Error: snd_soc_register_card failed (-12)!
snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -12
Apparently because the widget table for the codec looks like
this (sound/soc/codecs/ab8500-codec.c):
static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = {
/* Clocks */
SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"),
/* Regulators */
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0),
So when we call snd_soc_register_codec() and any of these widgets
get a deferred probe we do not get an -EPROBE_DEFER (-517) back as
we should and instead we just fail. Apparently the code assumes
that clocks and regulators must be available at this point and
not defer.
After this patch it rather looks like this:
ab8500-codec.0: Failed to create new controls -517
snd-soc-mop500.0: ASoC: failed to instantiate card -517
snd-soc-mop500.0: Error: snd_soc_register_card failed (-517)!
(...)
abx500-clk.0: registered clocks for ab850x
snd-soc-mop500.0: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok
snd-soc-mop500.0: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok
I'm pretty happy about the patch as it it, but I'm a bit
uncertain on how to proceed: there are a lot of users of the
external functions snd_soc_dapm_new_control() (111 sites)
and that will now return an occassional error pointer, which
is not handled in the calling sites.
I want an indication from the maintainers whether I should just
go in and augment all these call sites, or if deferred probe
is frowned upon when it leads to this much overhead.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-dapm.c | 42 ++++++++++++++++++++++++++++++++++++++++++
sound/soc/soc-topology.c | 9 +++++++++
2 files changed, 51 insertions(+)
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -358,6 +358,10 @@ static int dapm_kcontrol_data_alloc(stru
snd_soc_dapm_new_control_unlocked(widget->dapm,
&template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -392,6 +396,10 @@ static int dapm_kcontrol_data_alloc(stru
data->widget = snd_soc_dapm_new_control_unlocked(
widget->dapm, &template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -3311,11 +3319,22 @@ snd_soc_dapm_new_control(struct snd_soc_
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
w = snd_soc_dapm_new_control_unlocked(dapm, widget);
+ /* Do not nag about probe deferrals */
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create DAPM control %s (%d)\n",
+ widget->name, ret);
+ goto out_unlock;
+ }
if (!w)
dev_err(dapm->dev,
"ASoC: Failed to create DAPM control %s\n",
widget->name);
+out_unlock:
mutex_unlock(&dapm->card->dapm_mutex);
return w;
}
@@ -3338,6 +3357,8 @@ snd_soc_dapm_new_control_unlocked(struct
w->regulator = devm_regulator_get(dapm->dev, w->name);
if (IS_ERR(w->regulator)) {
ret = PTR_ERR(w->regulator);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
dev_err(dapm->dev, "ASoC: Failed to request %s: %d\n",
w->name, ret);
return NULL;
@@ -3356,6 +3377,8 @@ snd_soc_dapm_new_control_unlocked(struct
w->clk = devm_clk_get(dapm->dev, w->name);
if (IS_ERR(w->clk)) {
ret = PTR_ERR(w->clk);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
dev_err(dapm->dev, "ASoC: Failed to request %s: %d\n",
w->name, ret);
return NULL;
@@ -3474,6 +3497,16 @@ int snd_soc_dapm_new_controls(struct snd
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_INIT);
for (i = 0; i < num; i++) {
w = snd_soc_dapm_new_control_unlocked(dapm, widget);
+ if (IS_ERR(w)) {
+ ret = PTR_ERR(w);
+ /* Do not nag about probe deferrals */
+ if (ret == -EPROBE_DEFER)
+ break;
+ dev_err(dapm->dev,
+ "ASoC: Failed to create DAPM control %s (%d)\n",
+ widget->name, ret);
+ break;
+ }
if (!w) {
dev_err(dapm->dev,
"ASoC: Failed to create DAPM control %s\n",
@@ -3750,6 +3783,15 @@ int snd_soc_dapm_new_pcm(struct snd_soc_
dev_dbg(card->dev, "ASoC: adding %s widget\n", link_name);
w = snd_soc_dapm_new_control_unlocked(&card->dapm, &template);
+ if (IS_ERR(w)) {
+ ret = PTR_ERR(w);
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(card->dev,
+ "ASoC: Failed to create %s widget (%d)\n",
+ link_name, ret);
+ goto outfree_kcontrol_news;
+ }
if (!w) {
dev_err(card->dev, "ASoC: Failed to create %s widget\n",
link_name);
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -1473,6 +1473,15 @@ widget:
widget = snd_soc_dapm_new_control(dapm, &template);
else
widget = snd_soc_dapm_new_control_unlocked(dapm, &template);
+ if (IS_ERR(widget)) {
+ ret = PTR_ERR(widget);
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(tplg->dev,
+ "ASoC: failed to create widget %s controls (%d)\n",
+ w->name, ret);
+ goto hdr_err;
+ }
if (widget == NULL) {
dev_err(tplg->dev, "ASoC: failed to create widget %s controls\n",
w->name);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 045/104] audit: log 32-bit socketcalls
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 044/104] ASoC: dapm: handle probe deferrals Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 046/104] ath10k: prevent sta pointer rcu violation Greg Kroah-Hartman
` (58 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Richard Guy Briggs, David S. Miller,
Paul Moore, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Guy Briggs <rgb@redhat.com>
[ Upstream commit 62bc306e2083436675e33b5bdeb6a77907d35971 ]
32-bit socketcalls were not being logged by audit on x86_64 systems.
Log them. This is basically a duplicate of the call from
net/socket.c:sys_socketcall(), but it addresses the impedance mismatch
between 32-bit userspace process and 64-bit kernel audit.
See: https://github.com/linux-audit/audit-kernel/issues/14
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/audit.h | 20 ++++++++++++++++++++
net/compat.c | 17 ++++++++++++++---
2 files changed, 34 insertions(+), 3 deletions(-)
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -387,6 +387,20 @@ static inline int audit_socketcall(int n
return __audit_socketcall(nargs, args);
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ unsigned long a[AUDITSC_ARGS];
+ int i;
+
+ if (audit_dummy_context())
+ return 0;
+
+ for (i = 0; i < nargs; i++)
+ a[i] = (unsigned long)args[i];
+ return __audit_socketcall(nargs, a);
+}
+
static inline int audit_sockaddr(int len, void *addr)
{
if (unlikely(!audit_dummy_context()))
@@ -513,6 +527,12 @@ static inline int audit_socketcall(int n
{
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ return 0;
+}
+
static inline void audit_fd_pair(int fd1, int fd2)
{ }
static inline int audit_sockaddr(int len, void *addr)
--- a/net/compat.c
+++ b/net/compat.c
@@ -22,6 +22,7 @@
#include <linux/filter.h>
#include <linux/compat.h>
#include <linux/security.h>
+#include <linux/audit.h>
#include <linux/export.h>
#include <net/scm.h>
@@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd
COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
{
- int ret;
- u32 a[6];
+ u32 a[AUDITSC_ARGS];
+ unsigned int len;
u32 a0, a1;
+ int ret;
if (call < SYS_SOCKET || call > SYS_SENDMMSG)
return -EINVAL;
- if (copy_from_user(a, args, nas[call]))
+ len = nas[call];
+ if (len > sizeof(a))
+ return -EINVAL;
+
+ if (copy_from_user(a, args, len))
return -EFAULT;
+
+ ret = audit_socketcall_compat(len / sizeof(a[0]), a);
+ if (ret)
+ return ret;
+
a0 = a[0];
a1 = a[1];
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 046/104] ath10k: prevent sta pointer rcu violation
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 045/104] audit: log 32-bit socketcalls Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 047/104] spi: pxa2xx: Add support for Intel Gemini Lake Greg Kroah-Hartman
` (57 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michal Kazior, Kalle Valo, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Kazior <michal.kazior@tieto.com>
[ Upstream commit 0a744d927406389e00687560d9ce3c5ab0e58db9 ]
Station pointers are RCU protected so driver must
be extra careful if it tries to store them
internally for later use outside of the RCU
section it obtained it in.
It was possible for station teardown to race with
some htt events. The possible outcome could be a
use-after-free and a crash.
Only peer-flow-control capable firmware was
affected (so hardware-wise qca99x0 and qca4019).
This could be done in sta_state() itself via
explicit synchronize_net() call but there's
already a convenient sta_pre_rcu_remove() op that
can be hooked up to avoid extra rcu stall.
The peer->sta pointer itself can't be set to
NULL/ERR_PTR because it is later used in
sta_state() for extra sanity checks.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/mac.c | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -314,6 +314,7 @@ struct ath10k_peer {
struct ieee80211_vif *vif;
struct ieee80211_sta *sta;
+ bool removed;
int vdev_id;
u8 addr[ETH_ALEN];
DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3738,6 +3738,9 @@ struct ieee80211_txq *ath10k_mac_txq_loo
if (!peer)
return NULL;
+ if (peer->removed)
+ return NULL;
+
if (peer->sta)
return peer->sta->txq[tid];
else if (peer->vif)
@@ -7422,6 +7425,20 @@ ath10k_mac_op_switch_vif_chanctx(struct
return 0;
}
+static void ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k *ar;
+ struct ath10k_peer *peer;
+
+ ar = hw->priv;
+
+ list_for_each_entry(peer, &ar->peers, list)
+ if (peer->sta == sta)
+ peer->removed = true;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
.wake_tx_queue = ath10k_mac_op_wake_tx_queue,
@@ -7462,6 +7479,7 @@ static const struct ieee80211_ops ath10k
.assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
.unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
+ .sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 047/104] spi: pxa2xx: Add support for Intel Gemini Lake
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 046/104] ath10k: prevent sta pointer rcu violation Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 048/104] iommu/arm-smmu: Set privileged attribute to default instead of unprivileged Greg Kroah-Hartman
` (56 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David E. Box, Jarkko Nikula,
Mark Brown, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "David E. Box" <david.e.box@linux.intel.com>
[ Upstream commit e18a80acd1365e91e3efcd69942d9073936cf851 ]
Gemini Lake reuses the same LPSS SPI configuration as Broxton
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-pxa2xx.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1458,6 +1458,10 @@ static const struct pci_device_id pxa2xx
{ PCI_VDEVICE(INTEL, 0x1ac2), LPSS_BXT_SSP },
{ PCI_VDEVICE(INTEL, 0x1ac4), LPSS_BXT_SSP },
{ PCI_VDEVICE(INTEL, 0x1ac6), LPSS_BXT_SSP },
+ /* GLK */
+ { PCI_VDEVICE(INTEL, 0x31c2), LPSS_BXT_SSP },
+ { PCI_VDEVICE(INTEL, 0x31c4), LPSS_BXT_SSP },
+ { PCI_VDEVICE(INTEL, 0x31c6), LPSS_BXT_SSP },
/* APL */
{ PCI_VDEVICE(INTEL, 0x5ac2), LPSS_BXT_SSP },
{ PCI_VDEVICE(INTEL, 0x5ac4), LPSS_BXT_SSP },
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 048/104] iommu/arm-smmu: Set privileged attribute to default instead of unprivileged
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 047/104] spi: pxa2xx: Add support for Intel Gemini Lake Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 049/104] usb: chipidea: vbus event may exist before starting gadget Greg Kroah-Hartman
` (55 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Will Deacon, Sricharan R, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sricharan R <sricharan@codeaurora.org>
[ Upstream commit e19898077cfb642fe151ba22981e795c74d9e114 ]
Currently the driver sets all the device transactions privileges
to UNPRIVILEGED, but there are cases where the iommu masters wants
to isolate privileged supervisor and unprivileged user.
So don't override the privileged setting to unprivileged, instead
set it to default as incoming and let it be controlled by the pagetable
settings.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1211,7 +1211,7 @@ static int arm_smmu_domain_add_master(st
continue;
s2cr[idx].type = type;
- s2cr[idx].privcfg = S2CR_PRIVCFG_UNPRIV;
+ s2cr[idx].privcfg = S2CR_PRIVCFG_DEFAULT;
s2cr[idx].cbndx = cbndx;
arm_smmu_write_s2cr(smmu, idx);
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 049/104] usb: chipidea: vbus event may exist before starting gadget
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 048/104] iommu/arm-smmu: Set privileged attribute to default instead of unprivileged Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 051/104] ASoC: dapm: fix some pointer error handling Greg Kroah-Hartman
` (54 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Chen, Stephen Boyd, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Chen <peter.chen@nxp.com>
[ Upstream commit c3b674a04b8ab62a1d35e86714d466af0a0ecc18 ]
At some situations, the vbus may already be there before starting
gadget. So we need to check vbus event after switching to gadget in
order to handle missing vbus event. The typical use cases are plugging
vbus cable before driver load or the vbus has already been there
after stopping host but before starting gadget.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by: Stephen Boyd <stephen.boyd@linaro.org>
Reported-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/chipidea/otg.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -134,9 +134,9 @@ void ci_handle_vbus_change(struct ci_hdr
if (!ci->is_otg)
return;
- if (hw_read_otgsc(ci, OTGSC_BSV))
+ if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
usb_gadget_vbus_connect(&ci->gadget);
- else
+ else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active)
usb_gadget_vbus_disconnect(&ci->gadget);
}
@@ -175,14 +175,21 @@ static void ci_handle_id_switch(struct c
ci_role_stop(ci);
- if (role == CI_ROLE_GADGET)
+ if (role == CI_ROLE_GADGET &&
+ IS_ERR(ci->platdata->vbus_extcon.edev))
/*
- * wait vbus lower than OTGSC_BSV before connecting
- * to host
+ * Wait vbus lower than OTGSC_BSV before connecting
+ * to host. If connecting status is from an external
+ * connector instead of register, we don't need to
+ * care vbus on the board, since it will not affect
+ * external connector status.
*/
hw_wait_vbus_lower_bsv(ci);
ci_role_start(ci, role);
+ /* vbus change may have already occurred */
+ if (role == CI_ROLE_GADGET)
+ ci_handle_vbus_change(ci);
}
}
/**
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 051/104] ASoC: dapm: fix some pointer error handling
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 049/104] usb: chipidea: vbus event may exist before starting gadget Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 052/104] drm: mali-dp: Fix destination size handling when rotating Greg Kroah-Hartman
` (53 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Linus Walleij,
Mark Brown, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <linus.walleij@linaro.org>
[ Upstream commit 639467c8f26d834c934215e8b59129ce442475fe ]
commit 66feeec9322132689d42723df2537d60f96f8e44
"RFC: ASoC: dapm: handle probe deferrals"
forgot a to update some two sites where the call
was used. The static codechecks quickly found them.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 66feeec93221 ("RFC: ASoC: dapm: handle probe deferrals")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-dapm.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -3843,6 +3843,16 @@ int snd_soc_dapm_new_dai_widgets(struct
template.name);
w = snd_soc_dapm_new_control_unlocked(dapm, &template);
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create %s widget (%d)\n",
+ dai->driver->playback.stream_name, ret);
+ return ret;
+ }
if (!w) {
dev_err(dapm->dev, "ASoC: Failed to create %s widget\n",
dai->driver->playback.stream_name);
@@ -3862,6 +3872,16 @@ int snd_soc_dapm_new_dai_widgets(struct
template.name);
w = snd_soc_dapm_new_control_unlocked(dapm, &template);
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create %s widget (%d)\n",
+ dai->driver->playback.stream_name, ret);
+ return ret;
+ }
if (!w) {
dev_err(dapm->dev, "ASoC: Failed to create %s widget\n",
dai->driver->capture.stream_name);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 052/104] drm: mali-dp: Fix destination size handling when rotating
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 051/104] ASoC: dapm: fix some pointer error handling Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 053/104] drm: mali-dp: Fix transposed horizontal/vertical flip Greg Kroah-Hartman
` (52 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Brian Starkey, Liviu Dudau, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Starkey <brian.starkey@arm.com>
[ Upstream commit edabb3c4cd2d035bc93a3d67b25a304ea6217301 ]
The destination rectangle provided by userspace in the CRTC_X/Y/W/H
properties is already expressed as the dimensions after rotation.
This means we shouldn't swap the width and height ourselves when a
90/270 degree rotation is requested, so remove the code doing the swap.
Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/arm/malidp_planes.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -150,13 +150,8 @@ static void malidp_de_plane_update(struc
/* convert src values from Q16 fixed point to integer */
src_w = plane->state->src_w >> 16;
src_h = plane->state->src_h >> 16;
- if (plane->state->rotation & MALIDP_ROTATED_MASK) {
- dest_w = plane->state->crtc_h;
- dest_h = plane->state->crtc_w;
- } else {
- dest_w = plane->state->crtc_w;
- dest_h = plane->state->crtc_h;
- }
+ dest_w = plane->state->crtc_w;
+ dest_h = plane->state->crtc_h;
malidp_hw_write(mp->hwdev, format_id, mp->layer->base);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 053/104] drm: mali-dp: Fix transposed horizontal/vertical flip
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 052/104] drm: mali-dp: Fix destination size handling when rotating Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 054/104] HID: wacom: release the resources before leaving despite devm Greg Kroah-Hartman
` (51 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Brian Starkey, Liviu Dudau, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Starkey <brian.starkey@arm.com>
[ Upstream commit 7916efe5b57505080b3cebf5bdb228b4eda008ea ]
The horizontal and vertical flip flags were the wrong way around,
causing reflect-x to result in reflect-y being applied and vice-versa.
Fix them.
Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -184,9 +184,9 @@ static void malidp_de_plane_update(struc
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << LAYER_ROT_OFFSET;
if (plane->state->rotation & DRM_REFLECT_X)
- val |= LAYER_V_FLIP;
- if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;
+ if (plane->state->rotation & DRM_REFLECT_Y)
+ val |= LAYER_V_FLIP;
/* set the 'enable layer' bit */
val |= LAYER_ENABLE;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 054/104] HID: wacom: release the resources before leaving despite devm
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 053/104] drm: mali-dp: Fix transposed horizontal/vertical flip Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 055/104] MIPS: Lantiq: Fix another request_mem_region() return code check Greg Kroah-Hartman
` (50 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Benjamin Tissoires, Jason Gerecke,
Jiri Kosina, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[ Upstream commit 5b779fc52020ac6f5beea31c5eafc3d25cf70dc1 ]
In the general case, the resources are properly released by devm without
needing to do anything. However, when unplugging the wireless receiver,
the kernel segfaults from time to time while calling devres_release_all().
I think in that case the resources attempt to access hid_get_drvdata(hdev)
which has been set to null while leaving wacom_remove().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/wacom_sys.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2433,6 +2433,8 @@ static void wacom_remove(struct hid_devi
if (hdev->bus == BUS_BLUETOOTH)
device_remove_file(&hdev->dev, &dev_attr_speed);
+ wacom_release_resources(wacom);
+
hid_set_drvdata(hdev, NULL);
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 055/104] MIPS: Lantiq: Fix another request_mem_region() return code check
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 054/104] HID: wacom: release the resources before leaving despite devm Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 056/104] mips: ath79: clock:- Unmap region obtained by of_iomap Greg Kroah-Hartman
` (49 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, John Crispin,
linux-mips, Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 98ea51cb0c8ce009d9da1fd7b48f0ff1d7a9bbb0 ]
Hauke already fixed a couple of them, but one instance remains
that checks for a negative integer when it should check
for a NULL pointer:
arch/mips/lantiq/xway/sysctrl.c: In function 'ltq_soc_init':
arch/mips/lantiq/xway/sysctrl.c:473:19: error: ordered comparison of pointer with integer zero [-Werror=extra]
Fixes: 6e807852676a ("MIPS: Lantiq: Fix check for return value of request_mem_region()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: John Crispin <john@phrozen.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15043/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/lantiq/xway/sysctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/mips/lantiq/xway/sysctrl.c
+++ b/arch/mips/lantiq/xway/sysctrl.c
@@ -469,8 +469,8 @@ void __init ltq_soc_init(void)
panic("Failed to load xbar nodes from devicetree");
if (of_address_to_resource(np_xbar, 0, &res_xbar))
panic("Failed to get xbar resources");
- if (request_mem_region(res_xbar.start, resource_size(&res_xbar),
- res_xbar.name) < 0)
+ if (!request_mem_region(res_xbar.start, resource_size(&res_xbar),
+ res_xbar.name))
panic("Failed to get xbar resources");
ltq_xbar_membase = ioremap_nocache(res_xbar.start,
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 056/104] mips: ath79: clock:- Unmap region obtained by of_iomap
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 055/104] MIPS: Lantiq: Fix another request_mem_region() return code check Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 057/104] lkdtm: Fix Oops when unloading the module Greg Kroah-Hartman
` (48 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arvind Yadav, antonynpavlov, albeu,
hackpascal, sboyd, linux-mips, Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
[ Upstream commit b3d91db3f71d5f70ea60d900425a3f96aeb3d065 ]
Free memory mapping, if ath79_clocks_init_dt_ng is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Fixes: 3bdf1071ba7d ("MIPS: ath79: update devicetree clock support for AR9132")
Cc: antonynpavlov@gmail.com
Cc: albeu@free.fr
Cc: hackpascal@gmail.com
Cc: sboyd@codeaurora.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14915/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/ath79/clock.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/mips/ath79/clock.c
+++ b/arch/mips/ath79/clock.c
@@ -508,16 +508,19 @@ static void __init ath79_clocks_init_dt_
ar9330_clk_init(ref_clk, pll_base);
else {
pr_err("%s: could not find any appropriate clk_init()\n", dnfn);
- goto err_clk;
+ goto err_iounmap;
}
if (of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data)) {
pr_err("%s: could not register clk provider\n", dnfn);
- goto err_clk;
+ goto err_iounmap;
}
return;
+err_iounmap:
+ iounmap(pll_base);
+
err_clk:
clk_put(ref_clk);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 057/104] lkdtm: Fix Oops when unloading the module
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 056/104] mips: ath79: clock:- Unmap region obtained by of_iomap Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 058/104] net: core: Prevent from dereferencing null pointer when releasing SKB Greg Kroah-Hartman
` (47 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Juerg Haefliger, Kees Cook, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juerg Haefliger <juerg.haefliger@hpe.com>
[ Upstream commit 9ba60573638e2006170ebcc5489fb1e068afbc8f ]
No jprobe is registered when the module is loaded without specifying a
crashpoint that uses a jprobe. At the moment, we unconditionally try to
unregister the jprobe on module unload which results in an Oops. Add a
check to fix this.
Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/lkdtm_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/misc/lkdtm_core.c
+++ b/drivers/misc/lkdtm_core.c
@@ -533,7 +533,9 @@ static void __exit lkdtm_module_exit(voi
/* Handle test-specific clean-up. */
lkdtm_usercopy_exit();
- unregister_jprobe(lkdtm_jprobe);
+ if (lkdtm_jprobe != NULL)
+ unregister_jprobe(lkdtm_jprobe);
+
pr_info("Crash point unregistered\n");
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 058/104] net: core: Prevent from dereferencing null pointer when releasing SKB
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 057/104] lkdtm: Fix Oops when unloading the module Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 059/104] net/packet: check length in getsockopt() called with PACKET_HDRLEN Greg Kroah-Hartman
` (46 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Myungho Jung, David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myungho Jung <mhjungk@gmail.com>
[ Upstream commit 9899886d5e8ec5b343b1efe44f185a0e68dc6454 ]
Added NULL check to make __dev_kfree_skb_irq consistent with kfree
family of functions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2355,6 +2355,9 @@ void __dev_kfree_skb_irq(struct sk_buff
{
unsigned long flags;
+ if (unlikely(!skb))
+ return;
+
if (likely(atomic_read(&skb->users) == 1)) {
smp_rmb();
atomic_set(&skb->users, 0);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 059/104] net/packet: check length in getsockopt() called with PACKET_HDRLEN
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 058/104] net: core: Prevent from dereferencing null pointer when releasing SKB Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 060/104] team: fix memory leaks Greg Kroah-Hartman
` (45 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Potapenko, David S. Miller,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Potapenko <glider@google.com>
[ Upstream commit fd2c83b35752f0a8236b976978ad4658df14a59f ]
In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
|val| remains uninitialized and the syscall may behave differently
depending on its value, and even copy garbage to userspace on certain
architectures. To fix this we now return -EINVAL if optlen is too small.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3884,6 +3884,8 @@ static int packet_getsockopt(struct sock
case PACKET_HDRLEN:
if (len > sizeof(int))
len = sizeof(int);
+ if (len < sizeof(int))
+ return -EINVAL;
if (copy_from_user(&val, optval, len))
return -EFAULT;
switch (val) {
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 060/104] team: fix memory leaks
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 059/104] net/packet: check length in getsockopt() called with PACKET_HDRLEN Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 062/104] udp: disable inner UDP checksum offloads in IPsec case Greg Kroah-Hartman
` (44 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pan Bian, Jiri Pirko,
David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pan Bian <bianpan2016@163.com>
[ Upstream commit 72ec0bc64b9a5d8e0efcb717abfc757746b101b7 ]
In functions team_nl_send_port_list_get() and
team_nl_send_options_get(), pointer skb keeps the return value of
nlmsg_new(). When the call to genlmsg_put() fails, the memory is not
freed(). This will result in memory leak bugs.
Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options transfers")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/team/team.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2366,8 +2366,10 @@ start_again:
hdr = genlmsg_put(skb, portid, seq, &team_nl_family, flags | NLM_F_MULTI,
TEAM_CMD_OPTIONS_GET);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (nla_put_u32(skb, TEAM_ATTR_TEAM_IFINDEX, team->dev->ifindex))
goto nla_put_failure;
@@ -2639,8 +2641,10 @@ start_again:
hdr = genlmsg_put(skb, portid, seq, &team_nl_family, flags | NLM_F_MULTI,
TEAM_CMD_PORT_LIST_GET);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (nla_put_u32(skb, TEAM_ATTR_TEAM_IFINDEX, team->dev->ifindex))
goto nla_put_failure;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 062/104] udp: disable inner UDP checksum offloads in IPsec case
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 060/104] team: fix memory leaks Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 063/104] net: dsa: b53: Include IMP/CPU port in dumb forwarding mode Greg Kroah-Hartman
` (43 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ansis Atteka, David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ansis Atteka <aatteka@ovn.org>
[ Upstream commit b40c5f4fde22fb98eff205b3aece05b471c24eed ]
Otherwise, UDP checksum offloads could corrupt ESP packets by attempting
to calculate UDP checksum when this inner UDP packet is already protected
by IPsec.
One way to reproduce this bug is to have a VM with virtio_net driver (UFO
set to ON in the guest VM); and then encapsulate all guest's Ethernet
frames in Geneve; and then further encrypt Geneve with IPsec. In this
case following symptoms are observed:
1. If using ixgbe NIC, then it will complain with following error message:
ixgbe 0000:01:00.1: partial checksum but l4 proto=32!
2. Receiving IPsec stack will drop all the corrupted ESP packets and
increase XfrmInStateProtoError counter in /proc/net/xfrm_stat.
3. iperf UDP test from the VM with packet sizes above MTU will not work at
all.
4. iperf TCP test from the VM will get ridiculously low performance because.
Signed-off-by: Ansis Atteka <aatteka@ovn.org>
Co-authored-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/udp_offload.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -29,6 +29,7 @@ static struct sk_buff *__skb_udp_tunnel_
u16 mac_len = skb->mac_len;
int udp_offset, outer_hlen;
__wsum partial;
+ bool need_ipsec;
if (unlikely(!pskb_may_pull(skb, tnl_hlen)))
goto out;
@@ -62,8 +63,10 @@ static struct sk_buff *__skb_udp_tunnel_
ufo = !!(skb_shinfo(skb)->gso_type & SKB_GSO_UDP);
+ need_ipsec = skb_dst(skb) && dst_xfrm(skb_dst(skb));
/* Try to offload checksum if possible */
offload_csum = !!(need_csum &&
+ !need_ipsec &&
(skb->dev->features &
(is_ipv6 ? (NETIF_F_HW_CSUM | NETIF_F_IPV6_CSUM) :
(NETIF_F_HW_CSUM | NETIF_F_IP_CSUM))));
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 063/104] net: dsa: b53: Include IMP/CPU port in dumb forwarding mode
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 062/104] udp: disable inner UDP checksum offloads in IPsec case Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 064/104] qed: Fix possible system hang in the dcbnl-getdcbx() path Greg Kroah-Hartman
` (42 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Anholt, Florian Fainelli,
David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <f.fainelli@gmail.com>
[ Upstream commit a424f0de61638cbb5047e0a888c54da9cf471f90 ]
Since Broadcom tags are not enabled in b53 (DSA_PROTO_TAG_NONE), we need
to make sure that the IMP/CPU port is included in the forwarding
decision.
Without this change, switching between non-management ports would work,
but not between management ports and non-management ports thus breaking
the default state in which DSA switch are brought up.
Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/b53/b53_common.c | 10 ++++++++++
drivers/net/dsa/b53/b53_regs.h | 4 ++++
2 files changed, 14 insertions(+)
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -326,6 +326,7 @@ static void b53_get_vlan_entry(struct b5
static void b53_set_forwarding(struct b53_device *dev, int enable)
{
+ struct dsa_switch *ds = dev->ds;
u8 mgmt;
b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
@@ -336,6 +337,15 @@ static void b53_set_forwarding(struct b5
mgmt &= ~SM_SW_FWD_EN;
b53_write8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, mgmt);
+
+ /* Include IMP port in dumb forwarding mode when no tagging protocol is
+ * set
+ */
+ if (ds->ops->get_tag_protocol(ds) == DSA_TAG_PROTO_NONE) {
+ b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_CTRL, &mgmt);
+ mgmt |= B53_MII_DUMB_FWDG_EN;
+ b53_write8(dev, B53_CTRL_PAGE, B53_SWITCH_CTRL, mgmt);
+ }
}
static void b53_enable_vlan(struct b53_device *dev, bool enable)
--- a/drivers/net/dsa/b53/b53_regs.h
+++ b/drivers/net/dsa/b53/b53_regs.h
@@ -104,6 +104,10 @@
#define B53_UC_FWD_EN BIT(6)
#define B53_MC_FWD_EN BIT(7)
+/* Switch control (8 bit) */
+#define B53_SWITCH_CTRL 0x22
+#define B53_MII_DUMB_FWDG_EN BIT(6)
+
/* (16 bit) */
#define B53_UC_FLOOD_MASK 0x32
#define B53_MC_FLOOD_MASK 0x34
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 064/104] qed: Fix possible system hang in the dcbnl-getdcbx() path.
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 063/104] net: dsa: b53: Include IMP/CPU port in dumb forwarding mode Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 065/104] mmc: sdio: fix alignment issue in struct sdio_func Greg Kroah-Hartman
` (41 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sudarsana Reddy Kalluru, Yuval Mintz,
David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "sudarsana.kalluru@cavium.com" <sudarsana.kalluru@cavium.com>
[ Upstream commit 62289ba27558553871fd047baadaaeda886c6a63 ]
qed_dcbnl_get_dcbx() API uses kmalloc in GFT_KERNEL mode. The API gets
invoked in the interrupt context by qed_dcbnl_getdcbx callback. Need
to invoke this kmalloc in atomic mode.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -1222,7 +1222,7 @@ static struct qed_dcbx_get *qed_dcbnl_ge
{
struct qed_dcbx_get *dcbx_info;
- dcbx_info = kzalloc(sizeof(*dcbx_info), GFP_KERNEL);
+ dcbx_info = kmalloc(sizeof(*dcbx_info), GFP_ATOMIC);
if (!dcbx_info)
return NULL;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 065/104] mmc: sdio: fix alignment issue in struct sdio_func
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 064/104] qed: Fix possible system hang in the dcbnl-getdcbx() path Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 066/104] bridge: netlink: register netdevice before executing changelink Greg Kroah-Hartman
` (40 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Heiner Kallweit, Helmut Klein,
Ulf Hansson, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]
Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Helmut Klein <hgkr.klein@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/sdio_bus.c | 12 +++++++++++-
include/linux/mmc/sdio_func.h | 2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -266,7 +266,7 @@ static void sdio_release_func(struct dev
sdio_free_func_cis(func);
kfree(func->info);
-
+ kfree(func->tmpbuf);
kfree(func);
}
@@ -281,6 +281,16 @@ struct sdio_func *sdio_alloc_func(struct
if (!func)
return ERR_PTR(-ENOMEM);
+ /*
+ * allocate buffer separately to make sure it's properly aligned for
+ * DMA usage (incl. 64 bit DMA)
+ */
+ func->tmpbuf = kmalloc(4, GFP_KERNEL);
+ if (!func->tmpbuf) {
+ kfree(func);
+ return ERR_PTR(-ENOMEM);
+ }
+
func->card = card;
device_initialize(&func->dev);
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -53,7 +53,7 @@ struct sdio_func {
unsigned int state; /* function state */
#define SDIO_STATE_PRESENT (1<<0) /* present in sysfs */
- u8 tmpbuf[4]; /* DMA:able scratch buffer */
+ u8 *tmpbuf; /* DMA:able scratch buffer */
unsigned num_info; /* number of info strings */
const char **info; /* info strings */
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 066/104] bridge: netlink: register netdevice before executing changelink
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 065/104] mmc: sdio: fix alignment issue in struct sdio_func Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 067/104] Btrfs: fix segmentation fault when doing dio read Greg Kroah-Hartman
` (39 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikolay Aleksandrov, Ido Schimmel,
Peter V. Saveliev, David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <idosch@mellanox.com>
[ Upstream commit 5b8d5429daa05bebef6ffd3297df3b502cc6f184 ]
Peter reported a kernel oops when executing the following command:
$ ip link add name test type bridge vlan_default_pvid 1
[13634.939408] BUG: unable to handle kernel NULL pointer dereference at
0000000000000190
[13634.939436] IP: __vlan_add+0x73/0x5f0
[...]
[13634.939783] Call Trace:
[13634.939791] ? pcpu_next_unpop+0x3b/0x50
[13634.939801] ? pcpu_alloc+0x3d2/0x680
[13634.939810] ? br_vlan_add+0x135/0x1b0
[13634.939820] ? __br_vlan_set_default_pvid.part.28+0x204/0x2b0
[13634.939834] ? br_changelink+0x120/0x4e0
[13634.939844] ? br_dev_newlink+0x50/0x70
[13634.939854] ? rtnl_newlink+0x5f5/0x8a0
[13634.939864] ? rtnl_newlink+0x176/0x8a0
[13634.939874] ? mem_cgroup_commit_charge+0x7c/0x4e0
[13634.939886] ? rtnetlink_rcv_msg+0xe1/0x220
[13634.939896] ? lookup_fast+0x52/0x370
[13634.939905] ? rtnl_newlink+0x8a0/0x8a0
[13634.939915] ? netlink_rcv_skb+0xa1/0xc0
[13634.939925] ? rtnetlink_rcv+0x24/0x30
[13634.939934] ? netlink_unicast+0x177/0x220
[13634.939944] ? netlink_sendmsg+0x2fe/0x3b0
[13634.939954] ? _copy_from_user+0x39/0x40
[13634.939964] ? sock_sendmsg+0x30/0x40
[13634.940159] ? ___sys_sendmsg+0x29d/0x2b0
[13634.940326] ? __alloc_pages_nodemask+0xdf/0x230
[13634.940478] ? mem_cgroup_commit_charge+0x7c/0x4e0
[13634.940592] ? mem_cgroup_try_charge+0x76/0x1a0
[13634.940701] ? __handle_mm_fault+0xdb9/0x10b0
[13634.940809] ? __sys_sendmsg+0x51/0x90
[13634.940917] ? entry_SYSCALL_64_fastpath+0x1e/0xad
The problem is that the bridge's VLAN group is created after setting the
default PVID, when registering the netdevice and executing its
ndo_init().
Fix this by changing the order of both operations, so that
br_changelink() is only processed after the netdevice is registered,
when the VLAN group is already initialized.
Fixes: b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Peter V. Saveliev <peter@svinota.eu>
Tested-by: Peter V. Saveliev <peter@svinota.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bridge/br_netlink.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1098,11 +1098,14 @@ static int br_dev_newlink(struct net *sr
spin_unlock_bh(&br->lock);
}
- err = br_changelink(dev, tb, data);
+ err = register_netdevice(dev);
if (err)
return err;
- return register_netdevice(dev);
+ err = br_changelink(dev, tb, data);
+ if (err)
+ unregister_netdevice(dev);
+ return err;
}
static size_t br_get_size(const struct net_device *brdev)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 067/104] Btrfs: fix segmentation fault when doing dio read
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 066/104] bridge: netlink: register netdevice before executing changelink Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 068/104] Btrfs: fix potential use-after-free for cloned bio Greg Kroah-Hartman
` (38 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liu Bo, David Sterba, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <bo.li.liu@oracle.com>
[ Upstream commit 97bf5a5589aa3a59c60aa775fc12ec0483fc5002 ]
Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
introduced this bug during iterating bio pages in dio read's endio hook,
and it could end up with segment fault of the dio reading task.
So the reason is 'if (nr_sectors--)', and it makes the code assume that
there is one more block in the same page, so page offset is increased and
the bio which is created to repair the bad block then has an incorrect
bvec.bv_offset, and a later access of the page content would throw a
segmentation fault.
This also adds ASSERT to check page offset against page size.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/inode.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8050,8 +8050,10 @@ next_block_or_try_again:
start += sectorsize;
- if (nr_sectors--) {
+ nr_sectors--;
+ if (nr_sectors) {
pgoff += sectorsize;
+ ASSERT(pgoff < PAGE_SIZE);
goto next_block_or_try_again;
}
}
@@ -8157,8 +8159,10 @@ next:
ASSERT(nr_sectors);
- if (--nr_sectors) {
+ nr_sectors--;
+ if (nr_sectors) {
pgoff += sectorsize;
+ ASSERT(pgoff < PAGE_SIZE);
goto next_block;
}
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 068/104] Btrfs: fix potential use-after-free for cloned bio
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 067/104] Btrfs: fix segmentation fault when doing dio read Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 069/104] sata_via: Enable hotplug only on VT6421 Greg Kroah-Hartman
` (37 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Diego, Liu Bo, David Sterba, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <bo.li.liu@oracle.com>
[ Upstream commit a967efb30b3afa3d858edd6a17f544f9e9e46eea ]
KASAN reports that there is a use-after-free case of bio in btrfs_map_bio.
If we need to submit IOs to several disks at a time, the original bio
would get cloned and mapped to the destination disk, but we really should
use the original bio instead of a cloned bio to do the sanity check
because cloned bios are likely to be freed by its endio.
Reported-by: Diego <diegocg@gmail.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6226,7 +6226,7 @@ int btrfs_map_bio(struct btrfs_root *roo
for (dev_nr = 0; dev_nr < total_devs; dev_nr++) {
dev = bbio->stripes[dev_nr].dev;
if (!dev || !dev->bdev ||
- (bio_op(bio) == REQ_OP_WRITE && !dev->writeable)) {
+ (bio_op(first_bio) == REQ_OP_WRITE && !dev->writeable)) {
bbio_error(bbio, first_bio, logical);
continue;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 069/104] sata_via: Enable hotplug only on VT6421
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 068/104] Btrfs: fix potential use-after-free for cloned bio Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 070/104] hugetlbfs: initialize shared policy as part of inode allocation Greg Kroah-Hartman
` (36 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ondrej Zary, Tejun Heo, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ondrej Zary <linux@rainbow-software.org>
[ Upstream commit 3cf864520e877505158f09075794a08abab11bbe ]
Commit 57e5568fda27 ("sata_via: Implement hotplug for VT6421") adds
hotplug IRQ handler for VT6421 but enables hotplug on all chips. This
is a bug because it causes "irq xx: nobody cared" error on VT6420 when
hot-(un)plugging a drive:
[ 381.839948] irq 20: nobody cared (try booting with the "irqpoll" option)
[ 381.840014] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc5+ #148
[ 381.840066] Hardware name: P4VM800/P4VM800, BIOS P1.60 05/29/2006
[ 381.840117] Call Trace:
[ 381.840167] <IRQ>
[ 381.840225] ? dump_stack+0x44/0x58
[ 381.840278] ? __report_bad_irq+0x14/0x97
[ 381.840327] ? handle_edge_irq+0xa5/0xa5
[ 381.840376] ? note_interrupt+0x155/0x1cf
[ 381.840426] ? handle_edge_irq+0xa5/0xa5
[ 381.840474] ? handle_irq_event_percpu+0x32/0x38
[ 381.840524] ? handle_irq_event+0x1f/0x38
[ 381.840573] ? handle_fasteoi_irq+0x69/0xb8
[ 381.840625] ? handle_irq+0x4f/0x5d
[ 381.840672] </IRQ>
[ 381.840726] ? do_IRQ+0x2e/0x8b
[ 381.840782] ? common_interrupt+0x2c/0x34
[ 381.840836] ? mwait_idle+0x60/0x82
[ 381.840892] ? arch_cpu_idle+0x6/0x7
[ 381.840949] ? do_idle+0x96/0x18e
[ 381.841002] ? cpu_startup_entry+0x16/0x1a
[ 381.841057] ? start_kernel+0x319/0x31c
[ 381.841111] ? startup_32_smp+0x166/0x168
[ 381.841165] handlers:
[ 381.841219] [<c12a7263>] ata_bmdma_interrupt
[ 381.841274] Disabling IRQ #20
Seems that VT6420 can do hotplug too (there's no documentation) but the
comments say that SCR register access (required for detecting hotplug
events) can cause problems on these chips.
For now, just keep hotplug disabled on anything other than VT6421.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/sata_via.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
--- a/drivers/ata/sata_via.c
+++ b/drivers/ata/sata_via.c
@@ -644,14 +644,16 @@ static void svia_configure(struct pci_de
pci_write_config_byte(pdev, SATA_NATIVE_MODE, tmp8);
}
- /* enable IRQ on hotplug */
- pci_read_config_byte(pdev, SVIA_MISC_3, &tmp8);
- if ((tmp8 & SATA_HOTPLUG) != SATA_HOTPLUG) {
- dev_dbg(&pdev->dev,
- "enabling SATA hotplug (0x%x)\n",
- (int) tmp8);
- tmp8 |= SATA_HOTPLUG;
- pci_write_config_byte(pdev, SVIA_MISC_3, tmp8);
+ if (board_id == vt6421) {
+ /* enable IRQ on hotplug */
+ pci_read_config_byte(pdev, SVIA_MISC_3, &tmp8);
+ if ((tmp8 & SATA_HOTPLUG) != SATA_HOTPLUG) {
+ dev_dbg(&pdev->dev,
+ "enabling SATA hotplug (0x%x)\n",
+ (int) tmp8);
+ tmp8 |= SATA_HOTPLUG;
+ pci_write_config_byte(pdev, SVIA_MISC_3, tmp8);
+ }
}
/*
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 070/104] hugetlbfs: initialize shared policy as part of inode allocation
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 069/104] sata_via: Enable hotplug only on VT6421 Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 071/104] kasan: do not sanitize kexec purgatory Greg Kroah-Hartman
` (35 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Kravetz, Dmitry Vyukov,
Hillf Danton, Tetsuo Handa, Michal Hocko, Dave Hansen,
Andrew Morton, Linus Torvalds, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Kravetz <mike.kravetz@oracle.com>
[ Upstream commit 4742a35d9de745e867405b4311e1aac412f0ace1 ]
Any time after inode allocation, destroy_inode can be called. The
hugetlbfs inode contains a shared_policy structure, and
mpol_free_shared_policy is unconditionally called as part of
hugetlbfs_destroy_inode. Initialize the policy as part of inode
allocation so that any quick (error path) calls to destroy_inode will be
handed an initialized policy.
syzkaller fuzzer found this bug, that resulted in the following:
BUG: KASAN: user-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
000000131730bd7a
BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 000000131730bd7a
Write of size 4 by task syz-executor6/14086
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
__lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
__raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
_raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
alloc_inode+0x10d/0x180 fs/inode.c:216
new_inode_pseudo+0x69/0x190 fs/inode.c:889
new_inode+0x1c/0x40 fs/inode.c:918
hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
newseg+0x422/0xd30 ipc/shm.c:575
ipcget_new ipc/util.c:285 [inline]
ipcget+0x21e/0x580 ipc/util.c:639
SYSC_shmget ipc/shm.c:673 [inline]
SyS_shmget+0x158/0x230 ipc/shm.c:657
entry_SYSCALL_64_fastpath+0x1f/0xc2
Analysis provided by Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: http://lkml.kernel.org/r/1490477850-7944-1-git-send-email-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/hugetlbfs/inode.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -695,14 +695,11 @@ static struct inode *hugetlbfs_get_root(
inode = new_inode(sb);
if (inode) {
- struct hugetlbfs_inode_info *info;
inode->i_ino = get_next_ino();
inode->i_mode = S_IFDIR | config->mode;
inode->i_uid = config->uid;
inode->i_gid = config->gid;
inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
- info = HUGETLBFS_I(inode);
- mpol_shared_policy_init(&info->policy, NULL);
inode->i_op = &hugetlbfs_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
/* directory inodes start off with i_nlink == 2 (for "." entry) */
@@ -733,7 +730,6 @@ static struct inode *hugetlbfs_get_inode
inode = new_inode(sb);
if (inode) {
- struct hugetlbfs_inode_info *info;
inode->i_ino = get_next_ino();
inode_init_owner(inode, dir, mode);
lockdep_set_class(&inode->i_mapping->i_mmap_rwsem,
@@ -741,15 +737,6 @@ static struct inode *hugetlbfs_get_inode
inode->i_mapping->a_ops = &hugetlbfs_aops;
inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
inode->i_mapping->private_data = resv_map;
- info = HUGETLBFS_I(inode);
- /*
- * The policy is initialized here even if we are creating a
- * private inode because initialization simply creates an
- * an empty rb tree and calls rwlock_init(), later when we
- * call mpol_free_shared_policy() it will just return because
- * the rb tree will still be empty.
- */
- mpol_shared_policy_init(&info->policy, NULL);
switch (mode & S_IFMT) {
default:
init_special_inode(inode, mode, dev);
@@ -937,6 +924,18 @@ static struct inode *hugetlbfs_alloc_ino
hugetlbfs_inc_free_inodes(sbinfo);
return NULL;
}
+
+ /*
+ * Any time after allocation, hugetlbfs_destroy_inode can be called
+ * for the inode. mpol_free_shared_policy is unconditionally called
+ * as part of hugetlbfs_destroy_inode. So, initialize policy here
+ * in case of a quick call to destroy.
+ *
+ * Note that the policy is initialized even if we are creating a
+ * private inode. This simplifies hugetlbfs_destroy_inode.
+ */
+ mpol_shared_policy_init(&p->policy, NULL);
+
return &p->vfs_inode;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 071/104] kasan: do not sanitize kexec purgatory
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 070/104] hugetlbfs: initialize shared policy as part of inode allocation Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 073/104] netfilter: invoke synchronize_rcu after set the _hook_ to NULL Greg Kroah-Hartman
` (34 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Galbraith, Alexander Potapenko,
Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Linus Torvalds,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Galbraith <efault@gmx.de>
[ Upstream commit 13a6798e4a03096b11bf402a063786a7be55d426 ]
Fixes this:
kexec: Undefined symbol: __asan_load8_noabort
kexec-bzImage64: Loading purgatory failed
Link: http://lkml.kernel.org/r/1489672155.4458.7.camel@gmx.de
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/purgatory/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -8,6 +8,7 @@ PURGATORY_OBJS = $(addprefix $(obj)/,$(p
LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z nodefaultlib
targets += purgatory.ro
+KASAN_SANITIZE := n
KCOV_INSTRUMENT := n
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 073/104] netfilter: invoke synchronize_rcu after set the _hook_ to NULL
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 071/104] kasan: do not sanitize kexec purgatory Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 074/104] MIPS: IRQ Stack: Unwind IRQ stack onto task stack Greg Kroah-Hartman
` (33 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liping Zhang, Pablo Neira Ayuso, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liping Zhang <zlpnobody@gmail.com>
[ Upstream commit 3b7dabf029478bb80507a6c4500ca94132a2bc0b ]
Otherwise, another CPU may access the invalid pointer. For example:
CPU0 CPU1
- rcu_read_lock();
- pfunc = _hook_;
_hook_ = NULL; -
mod unload -
- pfunc(); // invalid, panic
- rcu_read_unlock();
So we must call synchronize_rcu() to wait the rcu reader to finish.
Also note, in nf_nat_snmp_basic_fini, synchronize_rcu() will be invoked
by later nf_conntrack_helper_unregister, but I'm inclined to add a
explicit synchronize_rcu after set the nf_nat_snmp_hook to NULL. Depend
on such obscure assumptions is not a good idea.
Last, in nfnetlink_cttimeout, we use kfree_rcu to free the time object,
so in cttimeout_exit, invoking rcu_barrier() is not necessary at all,
remove it too.
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/netfilter/nf_nat_snmp_basic.c | 1 +
net/netfilter/nf_conntrack_ecache.c | 2 ++
net/netfilter/nf_conntrack_netlink.c | 1 +
net/netfilter/nf_nat_core.c | 2 ++
net/netfilter/nfnetlink_cttimeout.c | 2 +-
5 files changed, 7 insertions(+), 1 deletion(-)
--- a/net/ipv4/netfilter/nf_nat_snmp_basic.c
+++ b/net/ipv4/netfilter/nf_nat_snmp_basic.c
@@ -1304,6 +1304,7 @@ static int __init nf_nat_snmp_basic_init
static void __exit nf_nat_snmp_basic_fini(void)
{
RCU_INIT_POINTER(nf_nat_snmp_hook, NULL);
+ synchronize_rcu();
nf_conntrack_helper_unregister(&snmp_trap_helper);
}
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -290,6 +290,7 @@ void nf_conntrack_unregister_notifier(st
BUG_ON(notify != new);
RCU_INIT_POINTER(net->ct.nf_conntrack_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
+ /* synchronize_rcu() is called from ctnetlink_exit. */
}
EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);
@@ -326,6 +327,7 @@ void nf_ct_expect_unregister_notifier(st
BUG_ON(notify != new);
RCU_INIT_POINTER(net->ct.nf_expect_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
+ /* synchronize_rcu() is called from ctnetlink_exit. */
}
EXPORT_SYMBOL_GPL(nf_ct_expect_unregister_notifier);
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -3413,6 +3413,7 @@ static void __exit ctnetlink_exit(void)
#ifdef CONFIG_NETFILTER_NETLINK_GLUE_CT
RCU_INIT_POINTER(nfnl_ct_hook, NULL);
#endif
+ synchronize_rcu();
}
module_init(ctnetlink_init);
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -892,6 +892,8 @@ static void __exit nf_nat_cleanup(void)
#ifdef CONFIG_XFRM
RCU_INIT_POINTER(nf_nat_decode_session_hook, NULL);
#endif
+ synchronize_rcu();
+
for (i = 0; i < NFPROTO_NUMPROTO; i++)
kfree(nf_nat_l4protos[i]);
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -646,8 +646,8 @@ static void __exit cttimeout_exit(void)
#ifdef CONFIG_NF_CONNTRACK_TIMEOUT
RCU_INIT_POINTER(nf_ct_timeout_find_get_hook, NULL);
RCU_INIT_POINTER(nf_ct_timeout_put_hook, NULL);
+ synchronize_rcu();
#endif /* CONFIG_NF_CONNTRACK_TIMEOUT */
- rcu_barrier();
}
module_init(cttimeout_init);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 074/104] MIPS: IRQ Stack: Unwind IRQ stack onto task stack
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 073/104] netfilter: invoke synchronize_rcu after set the _hook_ to NULL Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 075/104] iommu/exynos: Block SYSMMU while invalidating FLPD cache Greg Kroah-Hartman
` (32 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matt Redfearn, Paolo Bonzini,
Marcin Nowakowski, Masanari Iida, Chris Metcalf, James Hogan,
Paul Burton, Ingo Molnar, Jason A. Donenfeld, Andrew Morton,
linux-mips, Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <matt.redfearn@imgtec.com>
[ Upstream commit db8466c581cca1a08b505f1319c3ecd246f16fa8 ]
When the separate IRQ stack was introduced, stack unwinding only
proceeded as far as the top of the IRQ stack, leading to kernel
backtraces being less useful, lacking the trace of what was interrupted.
Fix this by providing a means for the kernel to unwind the IRQ stack
onto the interrupted task stack. The processor state is saved to the
kernel task stack on interrupt. The IRQ_STACK_START macro reserves an
unsigned long at the top of the IRQ stack where the interrupted task
stack pointer can be saved. After the active stack is switched to the
IRQ stack, save the interrupted tasks stack pointer to the reserved
location.
Fix the stack unwinding code to look for the frame being the top of the
IRQ stack and if so get the next frame from the saved location. The
existing test does not work with the separate stack since the ra is no
longer pointed at ret_from_{irq,exception}.
The test to stop unwinding the stack 32 bytes from the top of a stack
must be modified to allow unwinding to continue up to the location of
the saved task stack pointer when on the IRQ stack. The low / high marks
of the stack are set depending on whether the sp is on an irq stack or
not.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: Masanari Iida <standby24x7@gmail.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jason A. Donenfeld <jason@zx2c4.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15788/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/include/asm/irq.h | 15 ++++++++++
arch/mips/kernel/asm-offsets.c | 1
arch/mips/kernel/genex.S | 8 ++++-
arch/mips/kernel/process.c | 56 +++++++++++++++++++++++++++--------------
4 files changed, 60 insertions(+), 20 deletions(-)
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -18,9 +18,24 @@
#include <irq.h>
#define IRQ_STACK_SIZE THREAD_SIZE
+#define IRQ_STACK_START (IRQ_STACK_SIZE - sizeof(unsigned long))
extern void *irq_stack[NR_CPUS];
+/*
+ * The highest address on the IRQ stack contains a dummy frame put down in
+ * genex.S (handle_int & except_vec_vi_handler) which is structured as follows:
+ *
+ * top ------------
+ * | task sp | <- irq_stack[cpu] + IRQ_STACK_START
+ * ------------
+ * | | <- First frame of IRQ context
+ * ------------
+ *
+ * task sp holds a copy of the task stack pointer where the struct pt_regs
+ * from exception entry can be found.
+ */
+
static inline bool on_irq_stack(int cpu, unsigned long sp)
{
unsigned long low = (unsigned long)irq_stack[cpu];
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -103,6 +103,7 @@ void output_thread_info_defines(void)
DEFINE(_THREAD_SIZE, THREAD_SIZE);
DEFINE(_THREAD_MASK, THREAD_MASK);
DEFINE(_IRQ_STACK_SIZE, IRQ_STACK_SIZE);
+ DEFINE(_IRQ_STACK_START, IRQ_STACK_START);
BLANK();
}
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -215,9 +215,11 @@ NESTED(handle_int, PT_SIZE, sp)
beq t0, t1, 2f
/* Switch to IRQ stack */
- li t1, _IRQ_STACK_SIZE
+ li t1, _IRQ_STACK_START
PTR_ADD sp, t0, t1
+ /* Save task's sp on IRQ stack so that unwinding can follow it */
+ LONG_S s1, 0(sp)
2:
jal plat_irq_dispatch
@@ -325,9 +327,11 @@ NESTED(except_vec_vi_handler, 0, sp)
beq t0, t1, 2f
/* Switch to IRQ stack */
- li t1, _IRQ_STACK_SIZE
+ li t1, _IRQ_STACK_START
PTR_ADD sp, t0, t1
+ /* Save task's sp on IRQ stack so that unwinding can follow it */
+ LONG_S s1, 0(sp)
2:
jalr v0
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -487,31 +487,52 @@ unsigned long notrace unwind_stack_by_ad
unsigned long pc,
unsigned long *ra)
{
+ unsigned long low, high, irq_stack_high;
struct mips_frame_info info;
unsigned long size, ofs;
+ struct pt_regs *regs;
int leaf;
- extern void ret_from_irq(void);
- extern void ret_from_exception(void);
if (!stack_page)
return 0;
/*
- * If we reached the bottom of interrupt context,
- * return saved pc in pt_regs.
+ * IRQ stacks start at IRQ_STACK_START
+ * task stacks at THREAD_SIZE - 32
*/
- if (pc == (unsigned long)ret_from_irq ||
- pc == (unsigned long)ret_from_exception) {
- struct pt_regs *regs;
- if (*sp >= stack_page &&
- *sp + sizeof(*regs) <= stack_page + THREAD_SIZE - 32) {
- regs = (struct pt_regs *)*sp;
- pc = regs->cp0_epc;
- if (!user_mode(regs) && __kernel_text_address(pc)) {
- *sp = regs->regs[29];
- *ra = regs->regs[31];
- return pc;
- }
+ low = stack_page;
+ if (!preemptible() && on_irq_stack(raw_smp_processor_id(), *sp)) {
+ high = stack_page + IRQ_STACK_START;
+ irq_stack_high = high;
+ } else {
+ high = stack_page + THREAD_SIZE - 32;
+ irq_stack_high = 0;
+ }
+
+ /*
+ * If we reached the top of the interrupt stack, start unwinding
+ * the interrupted task stack.
+ */
+ if (unlikely(*sp == irq_stack_high)) {
+ unsigned long task_sp = *(unsigned long *)*sp;
+
+ /*
+ * Check that the pointer saved in the IRQ stack head points to
+ * something within the stack of the current task
+ */
+ if (!object_is_on_stack((void *)task_sp))
+ return 0;
+
+ /*
+ * Follow pointer to tasks kernel stack frame where interrupted
+ * state was saved.
+ */
+ regs = (struct pt_regs *)task_sp;
+ pc = regs->cp0_epc;
+ if (!user_mode(regs) && __kernel_text_address(pc)) {
+ *sp = regs->regs[29];
+ *ra = regs->regs[31];
+ return pc;
}
return 0;
}
@@ -532,8 +553,7 @@ unsigned long notrace unwind_stack_by_ad
if (leaf < 0)
return 0;
- if (*sp < stack_page ||
- *sp + info.frame_size > stack_page + THREAD_SIZE - 32)
+ if (*sp < low || *sp + info.frame_size > high)
return 0;
if (leaf)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 075/104] iommu/exynos: Block SYSMMU while invalidating FLPD cache
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 074/104] MIPS: IRQ Stack: Unwind IRQ stack onto task stack Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 076/104] [media] exynos-gsc: Do not swap cb/cr for semi planar formats Greg Kroah-Hartman
` (31 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marek Szyprowski, Joerg Roedel, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <m.szyprowski@samsung.com>
[ Upstream commit 7d2aa6b814476a2e2794960f844344519246df72 ]
Documentation specifies that SYSMMU should be in blocked state while
performing TLB/FLPD cache invalidation, so add needed calls to
sysmmu_block/unblock.
Fixes: 66a7ed84b345d ("iommu/exynos: Apply workaround of caching fault page table entries")
CC: stable@vger.kernel.org # v4.10+
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/exynos-iommu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -542,7 +542,10 @@ static void sysmmu_tlb_invalidate_flpdca
spin_lock_irqsave(&data->lock, flags);
if (is_sysmmu_active(data) && data->version >= MAKE_MMU_VER(3, 3)) {
clk_enable(data->clk_master);
- __sysmmu_tlb_invalidate_entry(data, iova, 1);
+ if (sysmmu_block(data)) {
+ __sysmmu_tlb_invalidate_entry(data, iova, 1);
+ sysmmu_unblock(data);
+ }
clk_disable(data->clk_master);
}
spin_unlock_irqrestore(&data->lock, flags);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 076/104] [media] exynos-gsc: Do not swap cb/cr for semi planar formats
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 075/104] iommu/exynos: Block SYSMMU while invalidating FLPD cache Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 077/104] MIPS: smp-cps: Fix retrieval of VPE mask on big endian CPUs Greg Kroah-Hartman
` (30 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nicolas Dufresne, Thibault Saunier,
Javier Martinez Canillas, Sylwester Nawrocki,
Mauro Carvalho Chehab, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thibault Saunier <thibault.saunier@osg.samsung.com>
[ Upstream commit d7f3e33df4fbdc9855fb151f4a328ec46447e3ba ]
In the case of semi planar formats cb and cr are in the same plane
in memory, meaning that will be set to 'cb' whatever the format is,
and whatever the (packed) order of those components are.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -849,9 +849,7 @@ int gsc_prepare_addr(struct gsc_ctx *ctx
if ((frame->fmt->pixelformat == V4L2_PIX_FMT_VYUY) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVYU) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV61) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV21) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420M))
swap(addr->cb, addr->cr);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 077/104] MIPS: smp-cps: Fix retrieval of VPE mask on big endian CPUs
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 076/104] [media] exynos-gsc: Do not swap cb/cr for semi planar formats Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 078/104] nvme-rdma: handle cpu unplug when re-establishing the controller Greg Kroah-Hartman
` (29 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matt Redfearn, Paul Burton,
linux-mips, Ralf Baechle, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <matt.redfearn@imgtec.com>
[ Upstream commit fb2155e3c30dc2043b52020e26965067a3e7779c ]
The vpe_mask member of struct core_boot_config is of type atomic_t,
which is a 32bit type. In cps-vec.S this member was being retrieved by a
PTR_L macro, which on 64bit systems is a 64bit load. On little endian
systems this is OK, since the double word that is retrieved will have
the required less significant word in the correct position. However, on
big endian systems the less significant word of the load is retrieved
from address+4, and the more significant from address+0. The destination
register therefore ends up with the required word in the more
significant word
e.g. when starting the second VP of a big endian 64bit system, the load
PTR_L ta2, COREBOOTCFG_VPEMASK(a0)
ends up setting register ta2 to 0x0000000300000000
When this value is written to the CPC it is ignored, since it is
invalid to write anything larger than 4 bits. This results in any VP
other than VP0 in a core failing to start in 64bit big endian systems.
Change the load to a 32bit load word instruction to fix the bug.
Fixes: f12401d7219f ("MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes")
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15787/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/cps-vec.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/cps-vec.S
+++ b/arch/mips/kernel/cps-vec.S
@@ -361,7 +361,7 @@ LEAF(mips_cps_get_bootcfg)
END(mips_cps_get_bootcfg)
LEAF(mips_cps_boot_vpes)
- PTR_L ta2, COREBOOTCFG_VPEMASK(a0)
+ lw ta2, COREBOOTCFG_VPEMASK(a0)
PTR_L ta3, COREBOOTCFG_VPECONFIG(a0)
#if defined(CONFIG_CPU_MIPSR6)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 078/104] nvme-rdma: handle cpu unplug when re-establishing the controller
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 077/104] MIPS: smp-cps: Fix retrieval of VPE mask on big endian CPUs Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 079/104] netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max Greg Kroah-Hartman
` (28 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, Sagi Grimberg,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sagi Grimberg <sagi@grimberg.me>
[ Upstream commit c248c64387fac5a6b31b343d9acb78f478e8619c ]
If a cpu unplug event has occured, we need to take the minimum
of the provided nr_io_queues and the number of online cpus,
otherwise we won't be able to connect them as blk-mq mapping
won't dispatch to those queues.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/rdma.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -337,8 +337,6 @@ static int __nvme_rdma_init_request(stru
struct ib_device *ibdev = dev->dev;
int ret;
- BUG_ON(queue_idx >= ctrl->queue_count);
-
ret = nvme_rdma_alloc_qe(ibdev, &req->sqe, sizeof(struct nvme_command),
DMA_TO_DEVICE);
if (ret)
@@ -643,8 +641,22 @@ out_free_queues:
static int nvme_rdma_init_io_queues(struct nvme_rdma_ctrl *ctrl)
{
+ struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
+ unsigned int nr_io_queues;
int i, ret;
+ nr_io_queues = min(opts->nr_io_queues, num_online_cpus());
+ ret = nvme_set_queue_count(&ctrl->ctrl, &nr_io_queues);
+ if (ret)
+ return ret;
+
+ ctrl->queue_count = nr_io_queues + 1;
+ if (ctrl->queue_count < 2)
+ return 0;
+
+ dev_info(ctrl->ctrl.device,
+ "creating %d I/O queues.\n", nr_io_queues);
+
for (i = 1; i < ctrl->queue_count; i++) {
ret = nvme_rdma_init_queue(ctrl, i,
ctrl->ctrl.opts->queue_size);
@@ -1795,20 +1807,8 @@ static const struct nvme_ctrl_ops nvme_r
static int nvme_rdma_create_io_queues(struct nvme_rdma_ctrl *ctrl)
{
- struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
int ret;
- ret = nvme_set_queue_count(&ctrl->ctrl, &opts->nr_io_queues);
- if (ret)
- return ret;
-
- ctrl->queue_count = opts->nr_io_queues + 1;
- if (ctrl->queue_count < 2)
- return 0;
-
- dev_info(ctrl->ctrl.device,
- "creating %d I/O queues.\n", opts->nr_io_queues);
-
ret = nvme_rdma_init_io_queues(ctrl);
if (ret)
return ret;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 079/104] netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 078/104] nvme-rdma: handle cpu unplug when re-establishing the controller Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 080/104] parisc: perf: Fix potential NULL pointer dereference Greg Kroah-Hartman
` (27 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liping Zhang, Pablo Neira Ayuso, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liping Zhang <zlpnobody@gmail.com>
[ Upstream commit ae5c682113f9f94cc5e76f92cf041ee624c173ee ]
The helper->expect_class_max must be set to the total number of
expect_policy minus 1, since we will use the statement "if (class >
helper->expect_class_max)" to validate the CTA_EXPECT_CLASS attr in
ctnetlink_alloc_expect.
So for compatibility, set the helper->expect_class_max to the
NFCTH_POLICY_SET_NUM attr's value minus 1.
Also: it's invalid when the NFCTH_POLICY_SET_NUM attr's value is zero.
1. this will result "expect_policy = kzalloc(0, GFP_KERNEL);";
2. we cannot set the helper->expect_class_max to a proper value.
So if nla_get_be32(tb[NFCTH_POLICY_SET_NUM]) is zero, report -EINVAL to
the userspace.
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/nfnetlink_cthelper.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/net/netfilter/nfnetlink_cthelper.c
+++ b/net/netfilter/nfnetlink_cthelper.c
@@ -161,6 +161,7 @@ nfnl_cthelper_parse_expect_policy(struct
int i, ret;
struct nf_conntrack_expect_policy *expect_policy;
struct nlattr *tb[NFCTH_POLICY_SET_MAX+1];
+ unsigned int class_max;
ret = nla_parse_nested(tb, NFCTH_POLICY_SET_MAX, attr,
nfnl_cthelper_expect_policy_set);
@@ -170,19 +171,18 @@ nfnl_cthelper_parse_expect_policy(struct
if (!tb[NFCTH_POLICY_SET_NUM])
return -EINVAL;
- helper->expect_class_max =
- ntohl(nla_get_be32(tb[NFCTH_POLICY_SET_NUM]));
-
- if (helper->expect_class_max != 0 &&
- helper->expect_class_max > NF_CT_MAX_EXPECT_CLASSES)
+ class_max = ntohl(nla_get_be32(tb[NFCTH_POLICY_SET_NUM]));
+ if (class_max == 0)
+ return -EINVAL;
+ if (class_max > NF_CT_MAX_EXPECT_CLASSES)
return -EOVERFLOW;
expect_policy = kzalloc(sizeof(struct nf_conntrack_expect_policy) *
- helper->expect_class_max, GFP_KERNEL);
+ class_max, GFP_KERNEL);
if (expect_policy == NULL)
return -ENOMEM;
- for (i=0; i<helper->expect_class_max; i++) {
+ for (i = 0; i < class_max; i++) {
if (!tb[NFCTH_POLICY_SET+i])
goto err;
@@ -191,6 +191,8 @@ nfnl_cthelper_parse_expect_policy(struct
if (ret < 0)
goto err;
}
+
+ helper->expect_class_max = class_max - 1;
helper->expect_policy = expect_policy;
return 0;
err:
@@ -377,10 +379,10 @@ nfnl_cthelper_dump_policy(struct sk_buff
goto nla_put_failure;
if (nla_put_be32(skb, NFCTH_POLICY_SET_NUM,
- htonl(helper->expect_class_max)))
+ htonl(helper->expect_class_max + 1)))
goto nla_put_failure;
- for (i=0; i<helper->expect_class_max; i++) {
+ for (i = 0; i < helper->expect_class_max + 1; i++) {
nest_parms2 = nla_nest_start(skb,
(NFCTH_POLICY_SET+i) | NLA_F_NESTED);
if (nest_parms2 == NULL)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 080/104] parisc: perf: Fix potential NULL pointer dereference
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (73 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 079/104] netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 081/104] nfs: make nfs4_cb_sv_ops static Greg Kroah-Hartman
` (26 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arvind Yadav, Helge Deller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
[ Upstream commit 74e3f6e63da6c8e8246fba1689e040bc926b4a1a ]
Fix potential NULL pointer dereference and clean up
coding style errors (code indent, trailing whitespaces).
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/perf.c | 94 +++++++++++++++++++++++-----------------------
1 file changed, 49 insertions(+), 45 deletions(-)
--- a/arch/parisc/kernel/perf.c
+++ b/arch/parisc/kernel/perf.c
@@ -39,7 +39,7 @@
* the PDC INTRIGUE calls. This is done to eliminate bugs introduced
* in various PDC revisions. The code is much more maintainable
* and reliable this way vs having to debug on every version of PDC
- * on every box.
+ * on every box.
*/
#include <linux/capability.h>
@@ -195,8 +195,8 @@ static int perf_config(uint32_t *image_p
static int perf_release(struct inode *inode, struct file *file);
static int perf_open(struct inode *inode, struct file *file);
static ssize_t perf_read(struct file *file, char __user *buf, size_t cnt, loff_t *ppos);
-static ssize_t perf_write(struct file *file, const char __user *buf, size_t count,
- loff_t *ppos);
+static ssize_t perf_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos);
static long perf_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
static void perf_start_counters(void);
static int perf_stop_counters(uint32_t *raddr);
@@ -222,7 +222,7 @@ extern void perf_intrigue_disable_perf_c
/*
* configure:
*
- * Configure the cpu with a given data image. First turn off the counters,
+ * Configure the cpu with a given data image. First turn off the counters,
* then download the image, then turn the counters back on.
*/
static int perf_config(uint32_t *image_ptr)
@@ -234,7 +234,7 @@ static int perf_config(uint32_t *image_p
error = perf_stop_counters(raddr);
if (error != 0) {
printk("perf_config: perf_stop_counters = %ld\n", error);
- return -EINVAL;
+ return -EINVAL;
}
printk("Preparing to write image\n");
@@ -242,7 +242,7 @@ printk("Preparing to write image\n");
error = perf_write_image((uint64_t *)image_ptr);
if (error != 0) {
printk("perf_config: DOWNLOAD = %ld\n", error);
- return -EINVAL;
+ return -EINVAL;
}
printk("Preparing to start counters\n");
@@ -254,7 +254,7 @@ printk("Preparing to start counters\n");
}
/*
- * Open the device and initialize all of its memory. The device is only
+ * Open the device and initialize all of its memory. The device is only
* opened once, but can be "queried" by multiple processes that know its
* file descriptor.
*/
@@ -298,8 +298,8 @@ static ssize_t perf_read(struct file *fi
* called on the processor that the download should happen
* on.
*/
-static ssize_t perf_write(struct file *file, const char __user *buf, size_t count,
- loff_t *ppos)
+static ssize_t perf_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
{
int err;
size_t image_size;
@@ -307,11 +307,11 @@ static ssize_t perf_write(struct file *f
uint32_t interface_type;
uint32_t test;
- if (perf_processor_interface == ONYX_INTF)
+ if (perf_processor_interface == ONYX_INTF)
image_size = PCXU_IMAGE_SIZE;
- else if (perf_processor_interface == CUDA_INTF)
+ else if (perf_processor_interface == CUDA_INTF)
image_size = PCXW_IMAGE_SIZE;
- else
+ else
return -EFAULT;
if (!capable(CAP_SYS_ADMIN))
@@ -331,22 +331,22 @@ static ssize_t perf_write(struct file *f
/* First check the machine type is correct for
the requested image */
- if (((perf_processor_interface == CUDA_INTF) &&
- (interface_type != CUDA_INTF)) ||
- ((perf_processor_interface == ONYX_INTF) &&
- (interface_type != ONYX_INTF)))
+ if (((perf_processor_interface == CUDA_INTF) &&
+ (interface_type != CUDA_INTF)) ||
+ ((perf_processor_interface == ONYX_INTF) &&
+ (interface_type != ONYX_INTF)))
return -EINVAL;
/* Next check to make sure the requested image
is valid */
- if (((interface_type == CUDA_INTF) &&
+ if (((interface_type == CUDA_INTF) &&
(test >= MAX_CUDA_IMAGES)) ||
- ((interface_type == ONYX_INTF) &&
- (test >= MAX_ONYX_IMAGES)))
+ ((interface_type == ONYX_INTF) &&
+ (test >= MAX_ONYX_IMAGES)))
return -EINVAL;
/* Copy the image into the processor */
- if (interface_type == CUDA_INTF)
+ if (interface_type == CUDA_INTF)
return perf_config(cuda_images[test]);
else
return perf_config(onyx_images[test]);
@@ -360,7 +360,7 @@ static ssize_t perf_write(struct file *f
static void perf_patch_images(void)
{
#if 0 /* FIXME!! */
-/*
+/*
* NOTE: this routine is VERY specific to the current TLB image.
* If the image is changed, this routine might also need to be changed.
*/
@@ -368,9 +368,9 @@ static void perf_patch_images(void)
extern void $i_dtlb_miss_2_0();
extern void PA2_0_iva();
- /*
+ /*
* We can only use the lower 32-bits, the upper 32-bits should be 0
- * anyway given this is in the kernel
+ * anyway given this is in the kernel
*/
uint32_t itlb_addr = (uint32_t)&($i_itlb_miss_2_0);
uint32_t dtlb_addr = (uint32_t)&($i_dtlb_miss_2_0);
@@ -378,21 +378,21 @@ static void perf_patch_images(void)
if (perf_processor_interface == ONYX_INTF) {
/* clear last 2 bytes */
- onyx_images[TLBMISS][15] &= 0xffffff00;
+ onyx_images[TLBMISS][15] &= 0xffffff00;
/* set 2 bytes */
onyx_images[TLBMISS][15] |= (0x000000ff&((dtlb_addr) >> 24));
onyx_images[TLBMISS][16] = (dtlb_addr << 8)&0xffffff00;
onyx_images[TLBMISS][17] = itlb_addr;
/* clear last 2 bytes */
- onyx_images[TLBHANDMISS][15] &= 0xffffff00;
+ onyx_images[TLBHANDMISS][15] &= 0xffffff00;
/* set 2 bytes */
onyx_images[TLBHANDMISS][15] |= (0x000000ff&((dtlb_addr) >> 24));
onyx_images[TLBHANDMISS][16] = (dtlb_addr << 8)&0xffffff00;
onyx_images[TLBHANDMISS][17] = itlb_addr;
/* clear last 2 bytes */
- onyx_images[BIG_CPI][15] &= 0xffffff00;
+ onyx_images[BIG_CPI][15] &= 0xffffff00;
/* set 2 bytes */
onyx_images[BIG_CPI][15] |= (0x000000ff&((dtlb_addr) >> 24));
onyx_images[BIG_CPI][16] = (dtlb_addr << 8)&0xffffff00;
@@ -405,24 +405,24 @@ static void perf_patch_images(void)
} else if (perf_processor_interface == CUDA_INTF) {
/* Cuda interface */
- cuda_images[TLBMISS][16] =
+ cuda_images[TLBMISS][16] =
(cuda_images[TLBMISS][16]&0xffff0000) |
((dtlb_addr >> 8)&0x0000ffff);
- cuda_images[TLBMISS][17] =
+ cuda_images[TLBMISS][17] =
((dtlb_addr << 24)&0xff000000) | ((itlb_addr >> 16)&0x000000ff);
cuda_images[TLBMISS][18] = (itlb_addr << 16)&0xffff0000;
- cuda_images[TLBHANDMISS][16] =
+ cuda_images[TLBHANDMISS][16] =
(cuda_images[TLBHANDMISS][16]&0xffff0000) |
((dtlb_addr >> 8)&0x0000ffff);
- cuda_images[TLBHANDMISS][17] =
+ cuda_images[TLBHANDMISS][17] =
((dtlb_addr << 24)&0xff000000) | ((itlb_addr >> 16)&0x000000ff);
cuda_images[TLBHANDMISS][18] = (itlb_addr << 16)&0xffff0000;
- cuda_images[BIG_CPI][16] =
+ cuda_images[BIG_CPI][16] =
(cuda_images[BIG_CPI][16]&0xffff0000) |
((dtlb_addr >> 8)&0x0000ffff);
- cuda_images[BIG_CPI][17] =
+ cuda_images[BIG_CPI][17] =
((dtlb_addr << 24)&0xff000000) | ((itlb_addr >> 16)&0x000000ff);
cuda_images[BIG_CPI][18] = (itlb_addr << 16)&0xffff0000;
} else {
@@ -434,7 +434,7 @@ static void perf_patch_images(void)
/*
* ioctl routine
- * All routines effect the processor that they are executed on. Thus you
+ * All routines effect the processor that they are executed on. Thus you
* must be running on the processor that you wish to change.
*/
@@ -460,7 +460,7 @@ static long perf_ioctl(struct file *file
}
/* copy out the Counters */
- if (copy_to_user((void __user *)arg, raddr,
+ if (copy_to_user((void __user *)arg, raddr,
sizeof (raddr)) != 0) {
error = -EFAULT;
break;
@@ -488,7 +488,7 @@ static const struct file_operations perf
.open = perf_open,
.release = perf_release
};
-
+
static struct miscdevice perf_dev = {
MISC_DYNAMIC_MINOR,
PA_PERF_DEV,
@@ -596,7 +596,7 @@ static int perf_stop_counters(uint32_t *
/* OR sticky2 (bit 1496) to counter2 bit 32 */
tmp64 |= (userbuf[23] >> 8) & 0x0000000080000000;
raddr[2] = (uint32_t)tmp64;
-
+
/* Counter3 is bits 1497 to 1528 */
tmp64 = (userbuf[23] >> 7) & 0x00000000ffffffff;
/* OR sticky3 (bit 1529) to counter3 bit 32 */
@@ -618,7 +618,7 @@ static int perf_stop_counters(uint32_t *
userbuf[22] = 0;
userbuf[23] = 0;
- /*
+ /*
* Write back the zeroed bytes + the image given
* the read was destructive.
*/
@@ -626,13 +626,13 @@ static int perf_stop_counters(uint32_t *
} else {
/*
- * Read RDR-15 which contains the counters and sticky bits
+ * Read RDR-15 which contains the counters and sticky bits
*/
if (!perf_rdr_read_ubuf(15, userbuf)) {
return -13;
}
- /*
+ /*
* Clear out the counters
*/
perf_rdr_clear(15);
@@ -645,7 +645,7 @@ static int perf_stop_counters(uint32_t *
raddr[2] = (uint32_t)((userbuf[1] >> 32) & 0x00000000ffffffffUL);
raddr[3] = (uint32_t)(userbuf[1] & 0x00000000ffffffffUL);
}
-
+
return 0;
}
@@ -683,7 +683,7 @@ static int perf_rdr_read_ubuf(uint32_t r
i = tentry->num_words;
while (i--) {
buffer[i] = 0;
- }
+ }
/* Check for bits an even number of 64 */
if ((xbits = width & 0x03f) != 0) {
@@ -809,18 +809,22 @@ static int perf_write_image(uint64_t *me
}
runway = ioremap_nocache(cpu_device->hpa.start, 4096);
+ if (!runway) {
+ pr_err("perf_write_image: ioremap failed!\n");
+ return -ENOMEM;
+ }
/* Merge intrigue bits into Runway STATUS 0 */
tmp64 = __raw_readq(runway + RUNWAY_STATUS) & 0xffecfffffffffffful;
- __raw_writeq(tmp64 | (*memaddr++ & 0x0013000000000000ul),
+ __raw_writeq(tmp64 | (*memaddr++ & 0x0013000000000000ul),
runway + RUNWAY_STATUS);
-
+
/* Write RUNWAY DEBUG registers */
for (i = 0; i < 8; i++) {
__raw_writeq(*memaddr++, runway + RUNWAY_DEBUG);
}
- return 0;
+ return 0;
}
/*
@@ -844,7 +848,7 @@ printk("perf_rdr_write\n");
perf_rdr_shift_out_U(rdr_num, buffer[i]);
} else {
perf_rdr_shift_out_W(rdr_num, buffer[i]);
- }
+ }
}
printk("perf_rdr_write done\n");
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 081/104] nfs: make nfs4_cb_sv_ops static
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (74 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 080/104] parisc: perf: Fix potential NULL pointer dereference Greg Kroah-Hartman
@ 2017-10-06 8:51 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 082/104] ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs Greg Kroah-Hartman
` (25 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jason Yan, Anna Schumaker, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Yan <yanaijie@huawei.com>
[ Upstream commit 05fae7bbc237bc7de0ee9c3dcf85b2572a80e3b5 ]
Fixes the following sparse warning:
fs/nfs/callback.c:235:21: warning: symbol 'nfs4_cb_sv_ops' was not
declared. Should it be static?
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/callback.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/callback.c
+++ b/fs/nfs/callback.c
@@ -239,12 +239,12 @@ static struct svc_serv_ops nfs41_cb_sv_o
.svo_module = THIS_MODULE,
};
-struct svc_serv_ops *nfs4_cb_sv_ops[] = {
+static struct svc_serv_ops *nfs4_cb_sv_ops[] = {
[0] = &nfs40_cb_sv_ops,
[1] = &nfs41_cb_sv_ops,
};
#else
-struct svc_serv_ops *nfs4_cb_sv_ops[] = {
+static struct svc_serv_ops *nfs4_cb_sv_ops[] = {
[0] = &nfs40_cb_sv_ops,
[1] = NULL,
};
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 082/104] ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (75 preceding siblings ...)
2017-10-06 8:51 ` [PATCH 4.9 081/104] nfs: make nfs4_cb_sv_ops static Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 083/104] cpufreq: intel_pstate: Update pid_params.sample_rate_ns in pid_param_set() Greg Kroah-Hartman
` (24 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nathan Fontenot, David S. Miller,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
[ Upstream commit 9501df3cd9204f5859f649182431616a31ee88a1 ]
The pointer array for the tx/rx sub crqs should be free'ed when
releasing the tx/rx sub crqs.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1253,6 +1253,7 @@ static void release_sub_crqs(struct ibmv
release_sub_crq_queue(adapter,
adapter->tx_scrq[i]);
}
+ kfree(adapter->tx_scrq);
adapter->tx_scrq = NULL;
}
@@ -1265,6 +1266,7 @@ static void release_sub_crqs(struct ibmv
release_sub_crq_queue(adapter,
adapter->rx_scrq[i]);
}
+ kfree(adapter->rx_scrq);
adapter->rx_scrq = NULL;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 083/104] cpufreq: intel_pstate: Update pid_params.sample_rate_ns in pid_param_set()
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (76 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 082/104] ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 084/104] x86/acpi: Restore the order of CPU IDs Greg Kroah-Hartman
` (23 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rafael J. Wysocki, Viresh Kumar, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
[ Upstream commit 6e7408acd04d06c04981c0c0fb5a2462b16fae4f ]
Fix the debugfs interface for PID tuning to actually update
pid_params.sample_rate_ns on PID parameters updates, as changing
pid_params.sample_rate_ms via debugfs has no effect now.
Fixes: a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpufreq/intel_pstate.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -609,6 +609,7 @@ static void intel_pstate_hwp_set_online_
static int pid_param_set(void *data, u64 val)
{
*(u32 *)data = val;
+ pid_params.sample_rate_ns = pid_params.sample_rate_ms * NSEC_PER_MSEC;
intel_pstate_reset_all_pid();
return 0;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 084/104] x86/acpi: Restore the order of CPU IDs
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (77 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 083/104] cpufreq: intel_pstate: Update pid_params.sample_rate_ns in pid_param_set() Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 085/104] iommu/io-pgtable-arm: Check for leaf entry before dereferencing it Greg Kroah-Hartman
` (22 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dou Liyang, Xiaolong Ye, rjw,
linux-acpi, guzheng1, izumi.taku, lenb, Thomas Gleixner,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dou Liyang <douly.fnst@cn.fujitsu.com>
[ Upstream commit 2b85b3d22920db7473e5fed5719e7955c0ec323e ]
The following commits:
f7c28833c2 ("x86/acpi: Enable acpi to register all possible cpus at
boot time") and 8f54969dc8 ("x86/acpi: Introduce persistent storage
for cpuid <-> apicid mapping")
... registered all the possible CPUs at boot time via ACPI tables to
make the mapping of cpuid <-> apicid fixed. Both enabled and disabled
CPUs could have a logical CPU ID after boot time.
But, ACPI tables are unreliable. the number amd order of Local APIC
entries which depends on the firmware is often inconsistent with the
physical devices. Even if they are consistent, The disabled CPUs which
take up some logical CPU IDs will also make the order discontinuous.
Revert the part of disabled CPUs registration, keep the allocation
logic of logical CPU IDs and also keep some code location changes.
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
Tested-by: Xiaolong Ye <xiaolong.ye@intel.com>
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-4-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 7 ++++++-
arch/x86/kernel/apic/apic.c | 26 +++++++-------------------
2 files changed, 13 insertions(+), 20 deletions(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -176,10 +176,15 @@ static int acpi_register_lapic(int id, u
return -EINVAL;
}
+ if (!enabled) {
+ ++disabled_cpus;
+ return -EINVAL;
+ }
+
if (boot_cpu_physical_apicid != -1U)
ver = boot_cpu_apic_version;
- cpu = __generic_processor_info(id, ver, enabled);
+ cpu = generic_processor_info(id, ver);
if (cpu >= 0)
early_per_cpu(x86_cpu_to_acpiid, cpu) = acpiid;
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2070,7 +2070,7 @@ static int allocate_logical_cpuid(int ap
return nr_logical_cpuids++;
}
-int __generic_processor_info(int apicid, int version, bool enabled)
+int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
@@ -2128,11 +2128,9 @@ int __generic_processor_info(int apicid,
if (num_processors >= nr_cpu_ids) {
int thiscpu = max + disabled_cpus;
- if (enabled) {
- pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
- "reached. Processor %d/0x%x ignored.\n",
- max, thiscpu, apicid);
- }
+ pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
+ "reached. Processor %d/0x%x ignored.\n",
+ max, thiscpu, apicid);
disabled_cpus++;
return -EINVAL;
@@ -2184,23 +2182,13 @@ int __generic_processor_info(int apicid,
apic->x86_32_early_logical_apicid(cpu);
#endif
set_cpu_possible(cpu, true);
-
- if (enabled) {
- num_processors++;
- physid_set(apicid, phys_cpu_present_map);
- set_cpu_present(cpu, true);
- } else {
- disabled_cpus++;
- }
+ physid_set(apicid, phys_cpu_present_map);
+ set_cpu_present(cpu, true);
+ num_processors++;
return cpu;
}
-int generic_processor_info(int apicid, int version)
-{
- return __generic_processor_info(apicid, version, true);
-}
-
int hard_smp_processor_id(void)
{
return read_apic_id();
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 085/104] iommu/io-pgtable-arm: Check for leaf entry before dereferencing it
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (78 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 084/104] x86/acpi: Restore the order of CPU IDs Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn() Greg Kroah-Hartman
` (21 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Oleksandr Tyshchenko, Will Deacon,
Robin Murphy, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
[ Upstream commit ed46e66cc1b3d684042f92dfa2ab15ee917b4cac ]
Do a check for already installed leaf entry at the current level before
dereferencing it in order to avoid walking the page table down with
wrong pointer to the next level.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/io-pgtable-arm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -335,8 +335,12 @@ static int __arm_lpae_map(struct arm_lpa
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
pte |= ARM_LPAE_PTE_NSTABLE;
__arm_lpae_set_pte(ptep, pte, cfg);
- } else {
+ } else if (!iopte_leaf(pte, lvl)) {
cptep = iopte_deref(pte, data);
+ } else {
+ /* We require an unmap first */
+ WARN_ON(!selftest_running);
+ return -EEXIST;
}
/* Rinse, repeat */
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (79 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 085/104] iommu/io-pgtable-arm: Check for leaf entry before dereferencing it Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 18:13 ` Mark Rutland
2017-10-06 8:52 ` [PATCH 4.9 087/104] mm/cgroup: avoid panic when init with low memory Greg Kroah-Hartman
` (20 subsequent siblings)
101 siblings, 1 reply; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Catalin Marinas, Will Deacon,
Laura Abbott, Mark Rutland, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <mark.rutland@arm.com>
[ Upstream commit b0de0ccc8b9edd8846828e0ecdc35deacdf186b0 ]
Booting a v4.11-rc1 kernel with DEBUG_VIRTUAL and KASAN enabled produces
the following splat (trimmed for brevity):
[ 0.000000] virt_to_phys used for non-linear address: ffff200008080000 (0xffff200008080000)
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:14 __virt_to_phys+0x48/0x70
[ 0.000000] PC is at __virt_to_phys+0x48/0x70
[ 0.000000] LR is at __virt_to_phys+0x48/0x70
[ 0.000000] Call trace:
[ 0.000000] [<ffff2000080b1ac0>] __virt_to_phys+0x48/0x70
[ 0.000000] [<ffff20000a03b86c>] kasan_init+0x1c0/0x498
[ 0.000000] [<ffff20000a034018>] setup_arch+0x2fc/0x948
[ 0.000000] [<ffff20000a030c68>] start_kernel+0xb8/0x570
[ 0.000000] [<ffff20000a0301e8>] __primary_switched+0x6c/0x74
This is because we use virt_to_pfn() on a kernel image address when
trying to figure out its nid, so that we can allocate its shadow from
the same node.
As with other recent changes, this patch uses lm_alias() to solve this.
We could instead use NUMA_NO_NODE, as x86 does for all shadow
allocations, though we'll likely want the "real" memory shadow to be
backed from its corresponding nid anyway, so we may as well be
consistent and find the nid for the image shadow.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/kasan_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -153,7 +153,7 @@ void __init kasan_init(void)
clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
vmemmap_populate(kimg_shadow_start, kimg_shadow_end,
- pfn_to_nid(virt_to_pfn(_text)));
+ pfn_to_nid(virt_to_pfn(lm_alias(_text))));
/*
* vmemmap_populate() has populated the shadow region that covers the
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-06 8:52 ` [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn() Greg Kroah-Hartman
@ 2017-10-06 18:13 ` Mark Rutland
2017-10-07 3:10 ` Levin, Alexander (Sasha Levin)
2017-10-07 8:42 ` Greg Kroah-Hartman
0 siblings, 2 replies; 144+ messages in thread
From: Mark Rutland @ 2017-10-06 18:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Catalin Marinas, Will Deacon, Laura Abbott,
Sasha Levin
Hi Greg,
On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
I'm a little confused as to why this is being backported, given it
wasn't Cc'd stable or marked as a fix.
The lm_alias() helper was only introduced in v4.10, and I don't recall
seeing that backported.
What's going on here?
Thanks,
Mark.
>
> ------------------
>
> From: Mark Rutland <mark.rutland@arm.com>
>
>
> [ Upstream commit b0de0ccc8b9edd8846828e0ecdc35deacdf186b0 ]
>
> Booting a v4.11-rc1 kernel with DEBUG_VIRTUAL and KASAN enabled produces
> the following splat (trimmed for brevity):
>
> [ 0.000000] virt_to_phys used for non-linear address: ffff200008080000 (0xffff200008080000)
> [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:14 __virt_to_phys+0x48/0x70
> [ 0.000000] PC is at __virt_to_phys+0x48/0x70
> [ 0.000000] LR is at __virt_to_phys+0x48/0x70
> [ 0.000000] Call trace:
> [ 0.000000] [<ffff2000080b1ac0>] __virt_to_phys+0x48/0x70
> [ 0.000000] [<ffff20000a03b86c>] kasan_init+0x1c0/0x498
> [ 0.000000] [<ffff20000a034018>] setup_arch+0x2fc/0x948
> [ 0.000000] [<ffff20000a030c68>] start_kernel+0xb8/0x570
> [ 0.000000] [<ffff20000a0301e8>] __primary_switched+0x6c/0x74
>
> This is because we use virt_to_pfn() on a kernel image address when
> trying to figure out its nid, so that we can allocate its shadow from
> the same node.
>
> As with other recent changes, this patch uses lm_alias() to solve this.
>
> We could instead use NUMA_NO_NODE, as x86 does for all shadow
> allocations, though we'll likely want the "real" memory shadow to be
> backed from its corresponding nid anyway, so we may as well be
> consistent and find the nid for the image shadow.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Acked-by: Laura Abbott <labbott@redhat.com>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> arch/arm64/mm/kasan_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -153,7 +153,7 @@ void __init kasan_init(void)
> clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
>
> vmemmap_populate(kimg_shadow_start, kimg_shadow_end,
> - pfn_to_nid(virt_to_pfn(_text)));
> + pfn_to_nid(virt_to_pfn(lm_alias(_text))));
>
> /*
> * vmemmap_populate() has populated the shadow region that covers the
>
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-06 18:13 ` Mark Rutland
@ 2017-10-07 3:10 ` Levin, Alexander (Sasha Levin)
2017-10-08 15:20 ` Mark Rutland
` (2 more replies)
2017-10-07 8:42 ` Greg Kroah-Hartman
1 sibling, 3 replies; 144+ messages in thread
From: Levin, Alexander (Sasha Levin) @ 2017-10-07 3:10 UTC (permalink / raw)
To: Mark Rutland
Cc: Greg Kroah-Hartman, linux-kernel, stable, Catalin Marinas,
Will Deacon, Laura Abbott
On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote:
>Hi Greg,
>
>On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote:
>> 4.9-stable review patch. If anyone has any objections, please let me know.
>
>I'm a little confused as to why this is being backported, given it
>wasn't Cc'd stable or marked as a fix.
>
>The lm_alias() helper was only introduced in v4.10, and I don't recall
>seeing that backported.
>
>What's going on here?
Mark,
We are experimenting with using neural network to aid with patch
selection for stable kernel trees. There are quite a few commits that
were not marked for stable, but are stable material, and we're trying
to get them into their appropriate kernel trees.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-07 3:10 ` Levin, Alexander (Sasha Levin)
@ 2017-10-08 15:20 ` Mark Rutland
2017-10-09 9:14 ` Mark Brown
2017-10-09 16:33 ` Laura Abbott
2 siblings, 0 replies; 144+ messages in thread
From: Mark Rutland @ 2017-10-08 15:20 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin)
Cc: Greg Kroah-Hartman, linux-kernel, stable, Catalin Marinas,
Will Deacon, Laura Abbott
On Sat, Oct 07, 2017 at 03:10:06AM +0000, Levin, Alexander (Sasha Levin) wrote:
> On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote:
> >Hi Greg,
> >
> >On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote:
> >> 4.9-stable review patch. If anyone has any objections, please let me know.
> >
> >I'm a little confused as to why this is being backported, given it
> >wasn't Cc'd stable or marked as a fix.
> >
> >The lm_alias() helper was only introduced in v4.10, and I don't recall
> >seeing that backported.
> >
> >What's going on here?
>
> Mark,
>
> We are experimenting with using neural network to aid with patch
> selection for stable kernel trees. There are quite a few commits that
> were not marked for stable, but are stable material, and we're trying
> to get them into their appropriate kernel trees.
I see.
Perhaps it would make sense to mark these patches as having been selected
automatically?
That way, reviewers would be able to better judge whether a backport makes
sense, as it wouldn't be implied that someone has encountered a problem on a
stable kernel, requiring the backport.
Maybe that was on the cover letter -- I only recieved this patch in isolation.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-07 3:10 ` Levin, Alexander (Sasha Levin)
2017-10-08 15:20 ` Mark Rutland
@ 2017-10-09 9:14 ` Mark Brown
2017-10-09 10:06 ` Will Deacon
2017-10-09 16:33 ` Laura Abbott
2 siblings, 1 reply; 144+ messages in thread
From: Mark Brown @ 2017-10-09 9:14 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin)
Cc: Mark Rutland, Greg Kroah-Hartman, linux-kernel, stable,
Catalin Marinas, Will Deacon, Laura Abbott
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Sat, Oct 07, 2017 at 03:10:06AM +0000, Levin, Alexander (Sasha Levin) wrote:
> We are experimenting with using neural network to aid with patch
> selection for stable kernel trees. There are quite a few commits that
> were not marked for stable, but are stable material, and we're trying
> to get them into their appropriate kernel trees.
If you're sending patches that were identified by a bot rather than a
domain expert it'd be really good to flag these *very* clearly (eg, by
sending the submissions with a different sender address) as they'll need
much more careful review than things that came in via a domain expert.
When they come from someone who's a stable maintainer as part of a big
batch of patches that doesn't look like a new submission from a not that
trusted source.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 9:14 ` Mark Brown
@ 2017-10-09 10:06 ` Will Deacon
2017-10-09 11:42 ` Greg Kroah-Hartman
0 siblings, 1 reply; 144+ messages in thread
From: Will Deacon @ 2017-10-09 10:06 UTC (permalink / raw)
To: Mark Brown
Cc: Levin, Alexander (Sasha Levin),
Mark Rutland, Greg Kroah-Hartman, linux-kernel, stable,
Catalin Marinas, Laura Abbott
On Mon, Oct 09, 2017 at 10:14:50AM +0100, Mark Brown wrote:
> On Sat, Oct 07, 2017 at 03:10:06AM +0000, Levin, Alexander (Sasha Levin) wrote:
>
> > We are experimenting with using neural network to aid with patch
> > selection for stable kernel trees. There are quite a few commits that
> > were not marked for stable, but are stable material, and we're trying
> > to get them into their appropriate kernel trees.
>
> If you're sending patches that were identified by a bot rather than a
> domain expert it'd be really good to flag these *very* clearly (eg, by
> sending the submissions with a different sender address) as they'll need
> much more careful review than things that came in via a domain expert.
> When they come from someone who's a stable maintainer as part of a big
> batch of patches that doesn't look like a new submission from a not that
> trusted source.
Taking this a bit further, I think ideally the subject would identify
whether or not the patch was selected by a bot, and it shouldn't get
backported to stable unless either the author or maintainer acks the patch,
or there is a tested-by from somebody reporting that it fixes a bug on
that stable tree that has actually been seen without it.
On the flip side, it means that the default response (silence) stops the
patches getting into stable, which isn't ideal for Greg. Thoughts?
Will
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 10:06 ` Will Deacon
@ 2017-10-09 11:42 ` Greg Kroah-Hartman
2017-10-09 14:00 ` Levin, Alexander (Sasha Levin)
2017-10-09 14:10 ` Mark Brown
0 siblings, 2 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-09 11:42 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Brown, Levin, Alexander (Sasha Levin),
Mark Rutland, linux-kernel, stable, Catalin Marinas,
Laura Abbott
On Mon, Oct 09, 2017 at 11:06:53AM +0100, Will Deacon wrote:
> On Mon, Oct 09, 2017 at 10:14:50AM +0100, Mark Brown wrote:
> > On Sat, Oct 07, 2017 at 03:10:06AM +0000, Levin, Alexander (Sasha Levin) wrote:
> >
> > > We are experimenting with using neural network to aid with patch
> > > selection for stable kernel trees. There are quite a few commits that
> > > were not marked for stable, but are stable material, and we're trying
> > > to get them into their appropriate kernel trees.
> >
> > If you're sending patches that were identified by a bot rather than a
> > domain expert it'd be really good to flag these *very* clearly (eg, by
> > sending the submissions with a different sender address) as they'll need
> > much more careful review than things that came in via a domain expert.
> > When they come from someone who's a stable maintainer as part of a big
> > batch of patches that doesn't look like a new submission from a not that
> > trusted source.
>
> Taking this a bit further, I think ideally the subject would identify
> whether or not the patch was selected by a bot, and it shouldn't get
> backported to stable unless either the author or maintainer acks the patch,
> or there is a tested-by from somebody reporting that it fixes a bug on
> that stable tree that has actually been seen without it.
>
> On the flip side, it means that the default response (silence) stops the
> patches getting into stable, which isn't ideal for Greg. Thoughts?
Yeah, default "do not take" isn't going to work, let's try just adding
another "this was picked because..." type line instead.
I know Sasha goes over these, and so do I, much more carefully than the
"normal" stable patches. But things slip in, like this one, at times.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 11:42 ` Greg Kroah-Hartman
@ 2017-10-09 14:00 ` Levin, Alexander (Sasha Levin)
2017-10-09 15:47 ` Mark Brown
2017-10-09 14:10 ` Mark Brown
1 sibling, 1 reply; 144+ messages in thread
From: Levin, Alexander (Sasha Levin) @ 2017-10-09 14:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Will Deacon, Mark Brown, Mark Rutland, linux-kernel, stable,
Catalin Marinas, Laura Abbott
On Mon, Oct 09, 2017 at 01:42:26PM +0200, Greg Kroah-Hartman wrote:
>On Mon, Oct 09, 2017 at 11:06:53AM +0100, Will Deacon wrote:
>> On Mon, Oct 09, 2017 at 10:14:50AM +0100, Mark Brown wrote:
>> > On Sat, Oct 07, 2017 at 03:10:06AM +0000, Levin, Alexander (Sasha Levin) wrote:
>> >
>> > > We are experimenting with using neural network to aid with patch
>> > > selection for stable kernel trees. There are quite a few commits that
>> > > were not marked for stable, but are stable material, and we're trying
>> > > to get them into their appropriate kernel trees.
>> >
>> > If you're sending patches that were identified by a bot rather than a
>> > domain expert it'd be really good to flag these *very* clearly (eg, by
>> > sending the submissions with a different sender address) as they'll need
>> > much more careful review than things that came in via a domain expert.
>> > When they come from someone who's a stable maintainer as part of a big
>> > batch of patches that doesn't look like a new submission from a not that
>> > trusted source.
>>
>> Taking this a bit further, I think ideally the subject would identify
>> whether or not the patch was selected by a bot, and it shouldn't get
>> backported to stable unless either the author or maintainer acks the patch,
>> or there is a tested-by from somebody reporting that it fixes a bug on
>> that stable tree that has actually been seen without it.
>>
>> On the flip side, it means that the default response (silence) stops the
>> patches getting into stable, which isn't ideal for Greg. Thoughts?
>
>Yeah, default "do not take" isn't going to work, let's try just adding
>another "this was picked because..." type line instead.
>
>I know Sasha goes over these, and so do I, much more carefully than the
>"normal" stable patches. But things slip in, like this one, at times.
I don't have an objection to adding another "pick by bot" line.
Note, also, that they go through a much longer review cycle: I send
out reviews and wait for comments for atleast a week, at which point
I send Greg a pull request (which he usually grabs after another week)
at which point a bunch more mails are sent out to the author/mailing
lists notifying that this patch was added.
In this case, for example, this patch had a "review cycle" of 18 days
where 4 different emails regarding this patch were sent out as it was
making it's way through review and queues, so we already try to be
as "loud" as we can with it.
At this point, we have almost 400 commits that were selected this way
and are now in the 4.9 LTS tree, and the recorded error rate so far
is slightly higher than 2%, which is in line with the average error
chance of a "regular" commit going into stable.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 14:00 ` Levin, Alexander (Sasha Levin)
@ 2017-10-09 15:47 ` Mark Brown
2017-10-09 16:23 ` Levin, Alexander (Sasha Levin)
0 siblings, 1 reply; 144+ messages in thread
From: Mark Brown @ 2017-10-09 15:47 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin)
Cc: Greg Kroah-Hartman, Will Deacon, Mark Rutland, linux-kernel,
stable, Catalin Marinas, Laura Abbott
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Mon, Oct 09, 2017 at 02:00:53PM +0000, Levin, Alexander (Sasha Levin) wrote:
> In this case, for example, this patch had a "review cycle" of 18 days
> where 4 different emails regarding this patch were sent out as it was
> making it's way through review and queues, so we already try to be
> as "loud" as we can with it.
As someone on the reviewing side what I'm seeing is a bunch of stable
maintainers sending fairly large patch serieses that look like normal
stable review things. That's not very loud. I usually don't spend that
much time on stable reviews as up until this started happening anything
that went in was either something I'd pushed in directly or something
where I had spent more time on already after someone had sent a "hey, we
should backport this" mail. Mails that look like the ones that have
been sent are just confirming prior review.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 15:47 ` Mark Brown
@ 2017-10-09 16:23 ` Levin, Alexander (Sasha Levin)
2017-10-09 16:27 ` Will Deacon
2017-10-09 16:30 ` Mark Brown
0 siblings, 2 replies; 144+ messages in thread
From: Levin, Alexander (Sasha Levin) @ 2017-10-09 16:23 UTC (permalink / raw)
To: Mark Brown
Cc: Greg Kroah-Hartman, Will Deacon, Mark Rutland, linux-kernel,
stable, Catalin Marinas, Laura Abbott
On Mon, Oct 09, 2017 at 04:47:46PM +0100, Mark Brown wrote:
>On Mon, Oct 09, 2017 at 02:00:53PM +0000, Levin, Alexander (Sasha Levin) wrote:
>
>> In this case, for example, this patch had a "review cycle" of 18 days
>> where 4 different emails regarding this patch were sent out as it was
>> making it's way through review and queues, so we already try to be
>> as "loud" as we can with it.
>
>As someone on the reviewing side what I'm seeing is a bunch of stable
>maintainers sending fairly large patch serieses that look like normal
>stable review things. That's not very loud. I usually don't spend that
>much time on stable reviews as up until this started happening anything
>that went in was either something I'd pushed in directly or something
>where I had spent more time on already after someone had sent a "hey, we
>should backport this" mail. Mails that look like the ones that have
>been sent are just confirming prior review.
Okay, so something like [REVIEW automatic-patch-selection for 4.X]
is sort of what you're suggesting?
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 16:23 ` Levin, Alexander (Sasha Levin)
@ 2017-10-09 16:27 ` Will Deacon
2017-10-09 16:30 ` Mark Brown
1 sibling, 0 replies; 144+ messages in thread
From: Will Deacon @ 2017-10-09 16:27 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin)
Cc: Mark Brown, Greg Kroah-Hartman, Mark Rutland, linux-kernel,
stable, Catalin Marinas, Laura Abbott
On Mon, Oct 09, 2017 at 04:23:21PM +0000, Levin, Alexander (Sasha Levin) wrote:
> On Mon, Oct 09, 2017 at 04:47:46PM +0100, Mark Brown wrote:
> >On Mon, Oct 09, 2017 at 02:00:53PM +0000, Levin, Alexander (Sasha Levin) wrote:
> >
> >> In this case, for example, this patch had a "review cycle" of 18 days
> >> where 4 different emails regarding this patch were sent out as it was
> >> making it's way through review and queues, so we already try to be
> >> as "loud" as we can with it.
> >
> >As someone on the reviewing side what I'm seeing is a bunch of stable
> >maintainers sending fairly large patch serieses that look like normal
> >stable review things. That's not very loud. I usually don't spend that
> >much time on stable reviews as up until this started happening anything
> >that went in was either something I'd pushed in directly or something
> >where I had spent more time on already after someone had sent a "hey, we
> >should backport this" mail. Mails that look like the ones that have
> >been sent are just confirming prior review.
>
> Okay, so something like [REVIEW automatic-patch-selection for 4.X]
> is sort of what you're suggesting?
That would work for me, thanks.
Will
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 16:23 ` Levin, Alexander (Sasha Levin)
2017-10-09 16:27 ` Will Deacon
@ 2017-10-09 16:30 ` Mark Brown
2017-10-09 17:29 ` Levin, Alexander (Sasha Levin)
1 sibling, 1 reply; 144+ messages in thread
From: Mark Brown @ 2017-10-09 16:30 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin)
Cc: Greg Kroah-Hartman, Will Deacon, Mark Rutland, linux-kernel,
stable, Catalin Marinas, Laura Abbott
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
On Mon, Oct 09, 2017 at 04:23:21PM +0000, Levin, Alexander (Sasha Levin) wrote:
> Okay, so something like [REVIEW automatic-patch-selection for 4.X]
> is sort of what you're suggesting?
Yeah (perhaps a bit less verbose so some of the actual patch subject is
visible!) but something visible like that. PATCH AUTOSEL or something?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 16:30 ` Mark Brown
@ 2017-10-09 17:29 ` Levin, Alexander (Sasha Levin)
0 siblings, 0 replies; 144+ messages in thread
From: Levin, Alexander (Sasha Levin) @ 2017-10-09 17:29 UTC (permalink / raw)
To: Mark Brown
Cc: Greg Kroah-Hartman, Will Deacon, Mark Rutland, linux-kernel,
stable, Catalin Marinas, Laura Abbott
On Mon, Oct 09, 2017 at 05:30:03PM +0100, Mark Brown wrote:
>On Mon, Oct 09, 2017 at 04:23:21PM +0000, Levin, Alexander (Sasha Levin) wrote:
>
>> Okay, so something like [REVIEW automatic-patch-selection for 4.X]
>> is sort of what you're suggesting?
>
>Yeah (perhaps a bit less verbose so some of the actual patch subject is
>visible!) but something visible like that. PATCH AUTOSEL or something?
Sure, I'll send my future review requests with that tag.
Thanks for the input and comments!
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 11:42 ` Greg Kroah-Hartman
2017-10-09 14:00 ` Levin, Alexander (Sasha Levin)
@ 2017-10-09 14:10 ` Mark Brown
1 sibling, 0 replies; 144+ messages in thread
From: Mark Brown @ 2017-10-09 14:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Will Deacon, Levin, Alexander (Sasha Levin),
Mark Rutland, linux-kernel, stable, Catalin Marinas,
Laura Abbott
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On Mon, Oct 09, 2017 at 01:42:26PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 09, 2017 at 11:06:53AM +0100, Will Deacon wrote:
> > On the flip side, it means that the default response (silence) stops the
> > patches getting into stable, which isn't ideal for Greg. Thoughts?
> Yeah, default "do not take" isn't going to work, let's try just adding
> another "this was picked because..." type line instead.
It would be worth trying harder for review, at least for an initial
period while this is new and people perhaps aren't aware that it's
happening at all. The suggestions for flagging things as not just being
normal stable stuff outside of the body of the message would help here,
something in the body of the message is going to get missed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-07 3:10 ` Levin, Alexander (Sasha Levin)
2017-10-08 15:20 ` Mark Rutland
2017-10-09 9:14 ` Mark Brown
@ 2017-10-09 16:33 ` Laura Abbott
2017-10-10 17:22 ` Levin, Alexander (Sasha Levin)
2 siblings, 1 reply; 144+ messages in thread
From: Laura Abbott @ 2017-10-09 16:33 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin), Mark Rutland
Cc: Greg Kroah-Hartman, linux-kernel, stable, Catalin Marinas, Will Deacon
On 10/06/2017 08:10 PM, Levin, Alexander (Sasha Levin) wrote:
> On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote:
>> Hi Greg,
>>
>> On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote:
>>> 4.9-stable review patch. If anyone has any objections, please let me know.
>>
>> I'm a little confused as to why this is being backported, given it
>> wasn't Cc'd stable or marked as a fix.
>>
>> The lm_alias() helper was only introduced in v4.10, and I don't recall
>> seeing that backported.
>>
>> What's going on here?
>
> Mark,
>
> We are experimenting with using neural network to aid with patch
> selection for stable kernel trees. There are quite a few commits that
> were not marked for stable, but are stable material, and we're trying
> to get them into their appropriate kernel trees.
>
Apart from the practical which has been covered, I'd be interested
in hearing about the details of how this works if you can share
them.
Thanks,
Laura
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-09 16:33 ` Laura Abbott
@ 2017-10-10 17:22 ` Levin, Alexander (Sasha Levin)
2017-10-10 17:31 ` Julia Lawall
0 siblings, 1 reply; 144+ messages in thread
From: Levin, Alexander (Sasha Levin) @ 2017-10-10 17:22 UTC (permalink / raw)
To: Laura Abbott
Cc: Mark Rutland, Greg Kroah-Hartman, linux-kernel, stable,
Catalin Marinas, Will Deacon, julia.lawall
(Cc'ed Julia)
On Mon, Oct 09, 2017 at 09:33:01AM -0700, Laura Abbott wrote:
>On 10/06/2017 08:10 PM, Levin, Alexander (Sasha Levin) wrote:
>> We are experimenting with using neural network to aid with patch
>> selection for stable kernel trees. There are quite a few commits that
>> were not marked for stable, but are stable material, and we're trying
>> to get them into their appropriate kernel trees.
>>
>
>Apart from the practical which has been covered, I'd be interested
>in hearing about the details of how this works if you can share
>them.
This work is based on Julia's work
(https://soarsmu.github.io/papers/icse12-patch.pdf) to identify
commits that fix bugs.
Essentially, my approach to this is to extract as much information as
possbile form the commit, including things such as:
- How many times a certain word appeared in the message
- Who is the author
- Code metrics
- etc
In my case, I end up with about 30,000 of these "inputs", and train a
neural network based on whether a given commit was included in a
stable tree or not.
This approach has a few drawbacks compared to the one Julia
described in her paper:
- Not every bug fixing commit ends up in stable (some end up in -rc
fixing a bug from the current merge window).
- Same as above, but for commits we miss and fail to add to stable.
- Sometimes commits get added to stable even though they don't follow
the rules at all (security fixes are a simple example).
But it does seem to be effective at finding bug fixing commits that
should be in stable.
At this stage we are still trying to figure out what a "bug fixing"
commit really is. For example, an observation we recently made was
that the code metrics actually don't have much weight in determining
whether a commit should be in stable or not.
As we just started, I'm still experimenting with a few approaches, and
I belive Julia is waiting for a new student to take over this, so we
don't have any big insights to share just yet :)
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-10 17:22 ` Levin, Alexander (Sasha Levin)
@ 2017-10-10 17:31 ` Julia Lawall
2017-11-15 17:43 ` Josh Hunt
0 siblings, 1 reply; 144+ messages in thread
From: Julia Lawall @ 2017-10-10 17:31 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin)
Cc: Laura Abbott, Mark Rutland, Greg Kroah-Hartman, linux-kernel,
stable, Catalin Marinas, Will Deacon
On Tue, 10 Oct 2017, Levin, Alexander (Sasha Levin) wrote:
> (Cc'ed Julia)
>
> On Mon, Oct 09, 2017 at 09:33:01AM -0700, Laura Abbott wrote:
> >On 10/06/2017 08:10 PM, Levin, Alexander (Sasha Levin) wrote:
> >> We are experimenting with using neural network to aid with patch
> >> selection for stable kernel trees. There are quite a few commits that
> >> were not marked for stable, but are stable material, and we're trying
> >> to get them into their appropriate kernel trees.
> >>
> >
> >Apart from the practical which has been covered, I'd be interested
> >in hearing about the details of how this works if you can share
> >them.
>
> This work is based on Julia's work
> (https://soarsmu.github.io/papers/icse12-patch.pdf) to identify
> commits that fix bugs.
>
> Essentially, my approach to this is to extract as much information as
> possbile form the commit, including things such as:
>
> - How many times a certain word appeared in the message
> - Who is the author
> - Code metrics
> - etc
>
> In my case, I end up with about 30,000 of these "inputs", and train a
> neural network based on whether a given commit was included in a
> stable tree or not.
>
> This approach has a few drawbacks compared to the one Julia
> described in her paper:
>
> - Not every bug fixing commit ends up in stable (some end up in -rc
> fixing a bug from the current merge window).
> - Same as above, but for commits we miss and fail to add to stable.
> - Sometimes commits get added to stable even though they don't follow
> the rules at all (security fixes are a simple example).
>
> But it does seem to be effective at finding bug fixing commits that
> should be in stable.
>
> At this stage we are still trying to figure out what a "bug fixing"
> commit really is. For example, an observation we recently made was
> that the code metrics actually don't have much weight in determining
> whether a commit should be in stable or not.
>
> As we just started, I'm still experimenting with a few approaches, and
> I belive Julia is waiting for a new student to take over this, so we
> don't have any big insights to share just yet :)
That's a good summary of the current status. Thanks!
julia
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-10 17:31 ` Julia Lawall
@ 2017-11-15 17:43 ` Josh Hunt
2017-11-16 23:13 ` alexander.levin
0 siblings, 1 reply; 144+ messages in thread
From: Josh Hunt @ 2017-11-15 17:43 UTC (permalink / raw)
To: Julia Lawall
Cc: Levin, Alexander (Sasha Levin),
Laura Abbott, Mark Rutland, Greg Kroah-Hartman, linux-kernel,
stable, Catalin Marinas, Will Deacon
On Tue, Oct 10, 2017 at 10:31 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
>
> On Tue, 10 Oct 2017, Levin, Alexander (Sasha Levin) wrote:
>
>> (Cc'ed Julia)
>>
>> On Mon, Oct 09, 2017 at 09:33:01AM -0700, Laura Abbott wrote:
>> >On 10/06/2017 08:10 PM, Levin, Alexander (Sasha Levin) wrote:
>> >> We are experimenting with using neural network to aid with patch
>> >> selection for stable kernel trees. There are quite a few commits that
>> >> were not marked for stable, but are stable material, and we're trying
>> >> to get them into their appropriate kernel trees.
>> >>
>> >
>> >Apart from the practical which has been covered, I'd be interested
>> >in hearing about the details of how this works if you can share
>> >them.
>>
>> This work is based on Julia's work
>> (https://soarsmu.github.io/papers/icse12-patch.pdf) to identify
>> commits that fix bugs.
>>
>> Essentially, my approach to this is to extract as much information as
>> possbile form the commit, including things such as:
>>
>> - How many times a certain word appeared in the message
>> - Who is the author
>> - Code metrics
>> - etc
>>
>> In my case, I end up with about 30,000 of these "inputs", and train a
>> neural network based on whether a given commit was included in a
>> stable tree or not.
>>
>> This approach has a few drawbacks compared to the one Julia
>> described in her paper:
>>
>> - Not every bug fixing commit ends up in stable (some end up in -rc
>> fixing a bug from the current merge window).
>> - Same as above, but for commits we miss and fail to add to stable.
>> - Sometimes commits get added to stable even though they don't follow
>> the rules at all (security fixes are a simple example).
>>
>> But it does seem to be effective at finding bug fixing commits that
>> should be in stable.
>>
>> At this stage we are still trying to figure out what a "bug fixing"
>> commit really is. For example, an observation we recently made was
>> that the code metrics actually don't have much weight in determining
>> whether a commit should be in stable or not.
>>
>> As we just started, I'm still experimenting with a few approaches, and
>> I belive Julia is waiting for a new student to take over this, so we
>> don't have any big insights to share just yet :)
>
> That's a good summary of the current status. Thanks!
>
> julia
I just started noticing the AUTOSEL tags yesterday and I think that's
a great idea to tag patches, but was there any thought to also putting
something in the commit message this way they're easily identifiable
in the git logs? I think it would be useful if there was some metadata
in the commit message which identified that it was selected through
some automated system. That way if I find a regression and it
identifies one of these commits I can know that maybe it was chosen
incorrectly, and also would allow me to alert the owner of the
selection script to better help refine its selection process.
Otherwise I'd have to track back through the mailing lists to see how
it landed in the stable release.
Just a thought. Also, thank you for trying to improve the stable kernels!
--
Josh
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-11-15 17:43 ` Josh Hunt
@ 2017-11-16 23:13 ` alexander.levin
2017-11-16 23:24 ` Josh Hunt
0 siblings, 1 reply; 144+ messages in thread
From: alexander.levin @ 2017-11-16 23:13 UTC (permalink / raw)
To: Josh Hunt
Cc: Julia Lawall, Laura Abbott, Mark Rutland, Greg Kroah-Hartman,
linux-kernel, stable, Catalin Marinas, Will Deacon
On Wed, Nov 15, 2017 at 09:43:41AM -0800, Josh Hunt wrote:
>I just started noticing the AUTOSEL tags yesterday and I think that's
>a great idea to tag patches, but was there any thought to also putting
>something in the commit message this way they're easily identifiable
>in the git logs? I think it would be useful if there was some metadata
>in the commit message which identified that it was selected through
>some automated system. That way if I find a regression and it
>identifies one of these commits I can know that maybe it was chosen
>incorrectly, and also would allow me to alert the owner of the
>selection script to better help refine its selection process.
>Otherwise I'd have to track back through the mailing lists to see how
>it landed in the stable release.
It's possible, but I didn't want to add a bunch of clutter to the
commit message. Right now it's somewhat easy to track it back to
automatic selection because:
1. I'm signed off on all of them, so I could chime in in the case
concerns/issues arise with a patch.
2. They all have a corresponding review request email with the
AUTOSEL marker.
Keep in mind that what the automatic tools are doing is only
identifying whether a patch "looks like" a patch that should be in
a stable tree. They do not verify that it's appropriate for any of
the stable trees it ends up going to - that's still mostly manual
and all fuck ups are PEBCAK.
>Just a thought. Also, thank you for trying to improve the stable kernels!
Thanks Josh!
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-11-16 23:13 ` alexander.levin
@ 2017-11-16 23:24 ` Josh Hunt
2017-11-17 8:06 ` Greg Kroah-Hartman
0 siblings, 1 reply; 144+ messages in thread
From: Josh Hunt @ 2017-11-16 23:24 UTC (permalink / raw)
To: Levin, Alexander
Cc: Julia Lawall, Laura Abbott, Mark Rutland, Greg Kroah-Hartman,
linux-kernel, stable, Catalin Marinas, Will Deacon
On Thu, Nov 16, 2017 at 3:13 PM, <alexander.levin@verizon.com> wrote:
>
> It's possible, but I didn't want to add a bunch of clutter to the
> commit message. Right now it's somewhat easy to track it back to
> automatic selection because:
>
> 1. I'm signed off on all of them, so I could chime in in the case
> concerns/issues arise with a patch.
> 2. They all have a corresponding review request email with the
> AUTOSEL marker.
>
I get the want to not clutter the commit logs. My comment was more
directed to a few weeks or months after the patch has made it into a
stable release. At that point I'm not sure the person who found the
problem with the change would know to CC you on any correspondence, or
even if the author of the change would know to contact you. Although I
guess maybe they'd eventually track things down and report to stable,
or Greg, or something else and it would eventually get back to you.
--
Josh
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-11-16 23:24 ` Josh Hunt
@ 2017-11-17 8:06 ` Greg Kroah-Hartman
0 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-17 8:06 UTC (permalink / raw)
To: Josh Hunt
Cc: Levin, Alexander, Julia Lawall, Laura Abbott, Mark Rutland,
linux-kernel, stable, Catalin Marinas, Will Deacon
On Thu, Nov 16, 2017 at 03:24:46PM -0800, Josh Hunt wrote:
> On Thu, Nov 16, 2017 at 3:13 PM, <alexander.levin@verizon.com> wrote:
> >
> > It's possible, but I didn't want to add a bunch of clutter to the
> > commit message. Right now it's somewhat easy to track it back to
> > automatic selection because:
> >
> > 1. I'm signed off on all of them, so I could chime in in the case
> > concerns/issues arise with a patch.
> > 2. They all have a corresponding review request email with the
> > AUTOSEL marker.
> >
>
> I get the want to not clutter the commit logs. My comment was more
> directed to a few weeks or months after the patch has made it into a
> stable release. At that point I'm not sure the person who found the
> problem with the change would know to CC you on any correspondence, or
> even if the author of the change would know to contact you. Although I
> guess maybe they'd eventually track things down and report to stable,
> or Greg, or something else and it would eventually get back to you.
If they report it to stable@vger (as they should), it is trivial for us
to look in the logs to see where the patch came from. It turns out that
the way Sasha formats these patches makes it obvious to me that it was
an auto-selected patch, so I can easily see that even without looking in
the email history.
So don't worry about us not being able to track things down, we are good
at that :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
2017-10-06 18:13 ` Mark Rutland
2017-10-07 3:10 ` Levin, Alexander (Sasha Levin)
@ 2017-10-07 8:42 ` Greg Kroah-Hartman
1 sibling, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-07 8:42 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-kernel, stable, Catalin Marinas, Will Deacon, Laura Abbott,
Sasha Levin
On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote:
> Hi Greg,
>
> On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch. If anyone has any objections, please let me know.
>
> I'm a little confused as to why this is being backported, given it
> wasn't Cc'd stable or marked as a fix.
Ok, I'm now dropping it, sorry for the issues it raised.
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH 4.9 087/104] mm/cgroup: avoid panic when init with low memory
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (80 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn() Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 088/104] rds: ib: add error handle Greg Kroah-Hartman
` (19 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Laurent Dufour, Michal Hocko,
Johannes Weiner, Balbir Singh, Vladimir Davydov, Andrew Morton,
Linus Torvalds, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
[ Upstream commit bfc7228b9a9647e1c353e50b40297a2929801759 ]
The system may panic when initialisation is done when almost all the
memory is assigned to the huge pages using the kernel command line
parameter hugepage=xxxx. Panic may occur like this:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc000000000302b88
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 [ 0.082424] NUMA
pSeries
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-15-generic #16-Ubuntu
task: c00000021ed01600 task.stack: c00000010d108000
NIP: c000000000302b88 LR: c000000000270e04 CTR: c00000000016cfd0
REGS: c00000010d10b2c0 TRAP: 0300 Not tainted (4.9.0-15-generic)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>[ 0.082770] CR: 28424422 XER: 00000000
CFAR: c0000000003d28b8 DAR: 0000000000000000 DSISR: 40000000 SOFTE: 1
GPR00: c000000000270e04 c00000010d10b540 c00000000141a300 c00000010fff6300
GPR04: 0000000000000000 00000000026012c0 c00000010d10b630 0000000487ab0000
GPR08: 000000010ee90000 c000000001454fd8 0000000000000000 0000000000000000
GPR12: 0000000000004400 c00000000fb80000 00000000026012c0 00000000026012c0
GPR16: 00000000026012c0 0000000000000000 0000000000000000 0000000000000002
GPR20: 000000000000000c 0000000000000000 0000000000000000 00000000024200c0
GPR24: c0000000016eef48 0000000000000000 c00000010fff7d00 00000000026012c0
GPR28: 0000000000000000 c00000010fff7d00 c00000010fff6300 c00000010d10b6d0
NIP mem_cgroup_soft_limit_reclaim+0xf8/0x4f0
LR do_try_to_free_pages+0x1b4/0x450
Call Trace:
do_try_to_free_pages+0x1b4/0x450
try_to_free_pages+0xf8/0x270
__alloc_pages_nodemask+0x7a8/0xff0
new_slab+0x104/0x8e0
___slab_alloc+0x620/0x700
__slab_alloc+0x34/0x60
kmem_cache_alloc_node_trace+0xdc/0x310
mem_cgroup_init+0x158/0x1c8
do_one_initcall+0x68/0x1d0
kernel_init_freeable+0x278/0x360
kernel_init+0x24/0x170
ret_from_kernel_thread+0x5c/0x74
Instruction dump:
eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 4e800020 3d230001 e9499a42 3d220004
3929acd8 794a1f24 7d295214 eac90100 <e9360000> 2fa90000 419eff74 3b200000
---[ end trace 342f5208b00d01b6 ]---
This is a chicken and egg issue where the kernel try to get free memory
when allocating per node data in mem_cgroup_init(), but in that path
mem_cgroup_soft_limit_reclaim() is called which assumes that these data
are allocated.
As mem_cgroup_soft_limit_reclaim() is best effort, it should return when
these data are not yet allocated.
This patch also fixes potential null pointer access in
mem_cgroup_remove_from_trees() and mem_cgroup_update_tree().
Link: http://lkml.kernel.org/r/1487856999-16581-2-git-send-email-ldufour@linux.vnet.ibm.com
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memcontrol.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -462,6 +462,8 @@ static void mem_cgroup_update_tree(struc
struct mem_cgroup_tree_per_node *mctz;
mctz = soft_limit_tree_from_page(page);
+ if (!mctz)
+ return;
/*
* Necessary to update all ancestors when hierarchy is used.
* because their event counter is not touched.
@@ -499,7 +501,8 @@ static void mem_cgroup_remove_from_trees
for_each_node(nid) {
mz = mem_cgroup_nodeinfo(memcg, nid);
mctz = soft_limit_tree_node(nid);
- mem_cgroup_remove_exceeded(mz, mctz);
+ if (mctz)
+ mem_cgroup_remove_exceeded(mz, mctz);
}
}
@@ -2565,7 +2568,7 @@ unsigned long mem_cgroup_soft_limit_recl
* is empty. Do it lockless to prevent lock bouncing. Races
* are acceptable as soft limit is best effort anyway.
*/
- if (RB_EMPTY_ROOT(&mctz->rb_root))
+ if (!mctz || RB_EMPTY_ROOT(&mctz->rb_root))
return 0;
/*
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 088/104] rds: ib: add error handle
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (81 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 087/104] mm/cgroup: avoid panic when init with low memory Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 089/104] md/raid10: submit bio directly to replacement disk Greg Kroah-Hartman
` (18 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Joe Jin, Junxiao Bi, Guanglei Li,
Zhu Yanjun, Santosh Shilimkar, David S. Miller, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhu Yanjun <yanjun.zhu@oracle.com>
[ Upstream commit 3b12f73a5c2977153f28a224392fd4729b50d1dc ]
In the function rds_ib_setup_qp, the error handle is missing. When some
error occurs, it is possible that memory leak occurs. As such, error
handle is added.
Cc: Joe Jin <joe.jin@oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Guanglei Li <guanglei.li@oracle.com>
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rds/ib_cm.c | 47 ++++++++++++++++++++++++++++++++++++-----------
1 file changed, 36 insertions(+), 11 deletions(-)
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -405,7 +405,7 @@ static int rds_ib_setup_qp(struct rds_co
ret = PTR_ERR(ic->i_send_cq);
ic->i_send_cq = NULL;
rdsdebug("ib_create_cq send failed: %d\n", ret);
- goto out;
+ goto rds_ibdev_out;
}
cq_attr.cqe = ic->i_recv_ring.w_nr;
@@ -416,19 +416,19 @@ static int rds_ib_setup_qp(struct rds_co
ret = PTR_ERR(ic->i_recv_cq);
ic->i_recv_cq = NULL;
rdsdebug("ib_create_cq recv failed: %d\n", ret);
- goto out;
+ goto send_cq_out;
}
ret = ib_req_notify_cq(ic->i_send_cq, IB_CQ_NEXT_COMP);
if (ret) {
rdsdebug("ib_req_notify_cq send failed: %d\n", ret);
- goto out;
+ goto recv_cq_out;
}
ret = ib_req_notify_cq(ic->i_recv_cq, IB_CQ_SOLICITED);
if (ret) {
rdsdebug("ib_req_notify_cq recv failed: %d\n", ret);
- goto out;
+ goto recv_cq_out;
}
/* XXX negotiate max send/recv with remote? */
@@ -453,7 +453,7 @@ static int rds_ib_setup_qp(struct rds_co
ret = rdma_create_qp(ic->i_cm_id, ic->i_pd, &attr);
if (ret) {
rdsdebug("rdma_create_qp failed: %d\n", ret);
- goto out;
+ goto recv_cq_out;
}
ic->i_send_hdrs = ib_dma_alloc_coherent(dev,
@@ -463,7 +463,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_send_hdrs) {
ret = -ENOMEM;
rdsdebug("ib_dma_alloc_coherent send failed\n");
- goto out;
+ goto qp_out;
}
ic->i_recv_hdrs = ib_dma_alloc_coherent(dev,
@@ -473,7 +473,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_recv_hdrs) {
ret = -ENOMEM;
rdsdebug("ib_dma_alloc_coherent recv failed\n");
- goto out;
+ goto send_hdrs_dma_out;
}
ic->i_ack = ib_dma_alloc_coherent(dev, sizeof(struct rds_header),
@@ -481,7 +481,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_ack) {
ret = -ENOMEM;
rdsdebug("ib_dma_alloc_coherent ack failed\n");
- goto out;
+ goto recv_hdrs_dma_out;
}
ic->i_sends = vzalloc_node(ic->i_send_ring.w_nr * sizeof(struct rds_ib_send_work),
@@ -489,7 +489,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_sends) {
ret = -ENOMEM;
rdsdebug("send allocation failed\n");
- goto out;
+ goto ack_dma_out;
}
ic->i_recvs = vzalloc_node(ic->i_recv_ring.w_nr * sizeof(struct rds_ib_recv_work),
@@ -497,7 +497,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_recvs) {
ret = -ENOMEM;
rdsdebug("recv allocation failed\n");
- goto out;
+ goto sends_out;
}
rds_ib_recv_init_ack(ic);
@@ -505,8 +505,33 @@ static int rds_ib_setup_qp(struct rds_co
rdsdebug("conn %p pd %p cq %p %p\n", conn, ic->i_pd,
ic->i_send_cq, ic->i_recv_cq);
-out:
+ return ret;
+
+sends_out:
+ vfree(ic->i_sends);
+ack_dma_out:
+ ib_dma_free_coherent(dev, sizeof(struct rds_header),
+ ic->i_ack, ic->i_ack_dma);
+recv_hdrs_dma_out:
+ ib_dma_free_coherent(dev, ic->i_recv_ring.w_nr *
+ sizeof(struct rds_header),
+ ic->i_recv_hdrs, ic->i_recv_hdrs_dma);
+send_hdrs_dma_out:
+ ib_dma_free_coherent(dev, ic->i_send_ring.w_nr *
+ sizeof(struct rds_header),
+ ic->i_send_hdrs, ic->i_send_hdrs_dma);
+qp_out:
+ rdma_destroy_qp(ic->i_cm_id);
+recv_cq_out:
+ if (!ib_destroy_cq(ic->i_recv_cq))
+ ic->i_recv_cq = NULL;
+send_cq_out:
+ if (!ib_destroy_cq(ic->i_send_cq))
+ ic->i_send_cq = NULL;
+rds_ibdev_out:
+ rds_ib_remove_conn(rds_ibdev, conn);
rds_ib_dev_put(rds_ibdev);
+
return ret;
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 089/104] md/raid10: submit bio directly to replacement disk
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (82 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 088/104] rds: ib: add error handle Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 090/104] netfilter: nf_tables: set pktinfo->thoff at AH header if found Greg Kroah-Hartman
` (17 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, NeilBrown, Shaohua Li, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaohua Li <shli@fb.com>
[ Upstream commit 6d399783e9d4e9bd44931501948059d24ad96ff8 ]
Commit 57c67df(md/raid10: submit IO from originating thread instead of
md thread) submits bio directly for normal disks but not for replacement
disks. There is no point we shouldn't do this for replacement disks.
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid10.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1407,11 +1407,24 @@ retry_write:
mbio->bi_private = r10_bio;
atomic_inc(&r10_bio->remaining);
+
+ cb = blk_check_plugged(raid10_unplug, mddev,
+ sizeof(*plug));
+ if (cb)
+ plug = container_of(cb, struct raid10_plug_cb,
+ cb);
+ else
+ plug = NULL;
spin_lock_irqsave(&conf->device_lock, flags);
- bio_list_add(&conf->pending_bio_list, mbio);
- conf->pending_count++;
+ if (plug) {
+ bio_list_add(&plug->pending, mbio);
+ plug->pending_cnt++;
+ } else {
+ bio_list_add(&conf->pending_bio_list, mbio);
+ conf->pending_count++;
+ }
spin_unlock_irqrestore(&conf->device_lock, flags);
- if (!mddev_check_plugged(mddev))
+ if (!plug)
md_wakeup_thread(mddev->thread);
}
}
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 090/104] netfilter: nf_tables: set pktinfo->thoff at AH header if found
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (83 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 089/104] md/raid10: submit bio directly to replacement disk Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 091/104] i2c: meson: fix wrong variable usage in meson_i2c_put_data Greg Kroah-Hartman
` (16 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Phil Sutter, Pablo Neira Ayuso, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <pablo@netfilter.org>
[ Upstream commit 568af6de058cb2b0c5b98d98ffcf37cdc6bc38a7 ]
Phil Sutter reports that IPv6 AH header matching is broken. From
userspace, nft generates bytecode that expects to find the AH header at
NFT_PAYLOAD_TRANSPORT_HEADER both for IPv4 and IPv6. However,
pktinfo->thoff is set to the inner header after the AH header in IPv6,
while in IPv4 pktinfo->thoff points to the AH header indeed. This
behaviour is inconsistent. This patch fixes this problem by updating
ipv6_find_hdr() to get the IP6_FH_F_AUTH flag so this function stops at
the AH header, so both IPv4 and IPv6 pktinfo->thoff point to the AH
header.
This is also inconsistent when trying to match encapsulated headers:
1) A packet that looks like IPv4 + AH + TCP dport 22 will *not* match.
2) A packet that looks like IPv6 + AH + TCP dport 22 will match.
Reported-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/netfilter/nf_tables_ipv6.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/include/net/netfilter/nf_tables_ipv6.h
+++ b/include/net/netfilter/nf_tables_ipv6.h
@@ -9,12 +9,13 @@ nft_set_pktinfo_ipv6(struct nft_pktinfo
struct sk_buff *skb,
const struct nf_hook_state *state)
{
+ unsigned int flags = IP6_FH_F_AUTH;
int protohdr, thoff = 0;
unsigned short frag_off;
nft_set_pktinfo(pkt, skb, state);
- protohdr = ipv6_find_hdr(pkt->skb, &thoff, -1, &frag_off, NULL);
+ protohdr = ipv6_find_hdr(pkt->skb, &thoff, -1, &frag_off, &flags);
if (protohdr < 0) {
nft_set_pktinfo_proto_unspec(pkt, skb);
return;
@@ -32,6 +33,7 @@ __nft_set_pktinfo_ipv6_validate(struct n
const struct nf_hook_state *state)
{
#if IS_ENABLED(CONFIG_IPV6)
+ unsigned int flags = IP6_FH_F_AUTH;
struct ipv6hdr *ip6h, _ip6h;
unsigned int thoff = 0;
unsigned short frag_off;
@@ -50,7 +52,7 @@ __nft_set_pktinfo_ipv6_validate(struct n
if (pkt_len + sizeof(*ip6h) > skb->len)
return -1;
- protohdr = ipv6_find_hdr(pkt->skb, &thoff, -1, &frag_off, NULL);
+ protohdr = ipv6_find_hdr(pkt->skb, &thoff, -1, &frag_off, &flags);
if (protohdr < 0)
return -1;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 091/104] i2c: meson: fix wrong variable usage in meson_i2c_put_data
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (84 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 090/104] netfilter: nf_tables: set pktinfo->thoff at AH header if found Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 092/104] xfs: remove kmem_zalloc_greedy Greg Kroah-Hartman
` (15 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Heiner Kallweit, Jerome Brunet,
Wolfram Sang, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 3b0277f198ac928f323c42e180680d2f79aa980d ]
Most likely a copy & paste error.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 30021e3707a7 ("i2c: add support for Amlogic Meson I2C controller")
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-meson.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -175,7 +175,7 @@ static void meson_i2c_put_data(struct me
wdata1 |= *buf++ << ((i - 4) * 8);
writel(wdata0, i2c->regs + REG_TOK_WDATA0);
- writel(wdata0, i2c->regs + REG_TOK_WDATA1);
+ writel(wdata1, i2c->regs + REG_TOK_WDATA1);
dev_dbg(i2c->dev, "%s: data %08x %08x len %d\n", __func__,
wdata0, wdata1, len);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 092/104] xfs: remove kmem_zalloc_greedy
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (85 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 091/104] i2c: meson: fix wrong variable usage in meson_i2c_put_data Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 093/104] ASoC: wm_adsp: Return an error on write to a disabled volatile control Greg Kroah-Hartman
` (14 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Darrick J. Wong, Christoph Hellwig,
Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Darrick J. Wong" <darrick.wong@oracle.com>
[ Upstream commit 08b005f1333154ae5b404ca28766e0ffb9f1c150 ]
The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses
it to grab 1-4 pages for staging of inobt records. The infinite loop in
the greedy allocation function is causing hangs[1] in generic/269, so
just get rid of the greedy allocator in favor of kmem_zalloc_large.
This makes bulkstat somewhat more likely to ENOMEM if there's really no
pages to spare, but eliminates a source of hangs.
[1] http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v2: remove single-page fallback
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/kmem.c | 18 ------------------
fs/xfs/kmem.h | 2 --
fs/xfs/xfs_itable.c | 6 ++----
3 files changed, 2 insertions(+), 24 deletions(-)
--- a/fs/xfs/kmem.c
+++ b/fs/xfs/kmem.c
@@ -24,24 +24,6 @@
#include "kmem.h"
#include "xfs_message.h"
-/*
- * Greedy allocation. May fail and may return vmalloced memory.
- */
-void *
-kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize)
-{
- void *ptr;
- size_t kmsize = maxsize;
-
- while (!(ptr = vzalloc(kmsize))) {
- if ((kmsize >>= 1) <= minsize)
- kmsize = minsize;
- }
- if (ptr)
- *size = kmsize;
- return ptr;
-}
-
void *
kmem_alloc(size_t size, xfs_km_flags_t flags)
{
--- a/fs/xfs/kmem.h
+++ b/fs/xfs/kmem.h
@@ -69,8 +69,6 @@ static inline void kmem_free(const void
}
-extern void *kmem_zalloc_greedy(size_t *, size_t, size_t);
-
static inline void *
kmem_zalloc(size_t size, xfs_km_flags_t flags)
{
--- a/fs/xfs/xfs_itable.c
+++ b/fs/xfs/xfs_itable.c
@@ -361,7 +361,6 @@ xfs_bulkstat(
xfs_agino_t agino; /* inode # in allocation group */
xfs_agnumber_t agno; /* allocation group number */
xfs_btree_cur_t *cur; /* btree cursor for ialloc btree */
- size_t irbsize; /* size of irec buffer in bytes */
xfs_inobt_rec_incore_t *irbuf; /* start of irec buffer */
int nirbuf; /* size of irbuf */
int ubcount; /* size of user's buffer */
@@ -388,11 +387,10 @@ xfs_bulkstat(
*ubcountp = 0;
*done = 0;
- irbuf = kmem_zalloc_greedy(&irbsize, PAGE_SIZE, PAGE_SIZE * 4);
+ irbuf = kmem_zalloc_large(PAGE_SIZE * 4, KM_SLEEP);
if (!irbuf)
return -ENOMEM;
-
- nirbuf = irbsize / sizeof(*irbuf);
+ nirbuf = (PAGE_SIZE * 4) / sizeof(*irbuf);
/*
* Loop over the allocation groups, starting from the last
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 093/104] ASoC: wm_adsp: Return an error on write to a disabled volatile control
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (86 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 092/104] xfs: remove kmem_zalloc_greedy Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 094/104] libata: transport: Remove circular dependency at free time Greg Kroah-Hartman
` (13 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Charles Keepax, Mark Brown, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
[ Upstream commit 67430a39ca7a6af28aade5acb92d43ee257c1014 ]
Volatile controls should only be accessed when the firmware is active,
currently however writes to these controls will succeed, but the data
will be lost, if the firmware is powered down. Update this behaviour such
that an error is returned the same as it is for reads.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/codecs/wm_adsp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -789,7 +789,10 @@ static int wm_coeff_put(struct snd_kcont
mutex_lock(&ctl->dsp->pwr_lock);
- memcpy(ctl->cache, p, ctl->len);
+ if (ctl->flags & WMFW_CTL_FLAG_VOLATILE)
+ ret = -EPERM;
+ else
+ memcpy(ctl->cache, p, ctl->len);
ctl->set = 1;
if (ctl->enabled && ctl->dsp->running)
@@ -816,6 +819,8 @@ static int wm_coeff_tlv_put(struct snd_k
ctl->set = 1;
if (ctl->enabled && ctl->dsp->running)
ret = wm_coeff_write_control(ctl, ctl->cache, size);
+ else if (ctl->flags & WMFW_CTL_FLAG_VOLATILE)
+ ret = -EPERM;
}
mutex_unlock(&ctl->dsp->pwr_lock);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 094/104] libata: transport: Remove circular dependency at free time
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (87 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 093/104] ASoC: wm_adsp: Return an error on write to a disabled volatile control Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 095/104] ARM: dts: BCM5301X: Fix memory start address Greg Kroah-Hartman
` (12 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matthew Whitehead, Tejun Heo,
Gwendal Grignou, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gwendal Grignou <gwendal@chromium.org>
[ Upstream commit d85fc67dd11e9a32966140677d4d6429ca540b25 ]
Without this patch, failed probe would not free resources like irq.
ata port tdev object currently hold a reference to the ata port
object. Therefore the ata port object release function will not get
called until the ata_tport_release is called. But that would never
happen, releasing the last reference of ata port dev is done by
scsi_host_release, which is called by ata_host_release when the ata
port object is released.
The ata device objects actually do not need to explicitly hold a
reference to their real counterpart, given the transport objects are
the children of these objects and device_add() is call for each child.
We know the parent will not be deleted until we call the child's
device_del().
Reported-by: Matthew Whitehead <tedheadster@gmail.com>
Tested-by: Matthew Whitehead <tedheadster@gmail.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-transport.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -224,7 +224,6 @@ static DECLARE_TRANSPORT_CLASS(ata_port_
static void ata_tport_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -284,7 +283,7 @@ int ata_tport_add(struct device *parent,
device_initialize(dev);
dev->type = &ata_port_type;
- dev->parent = get_device(parent);
+ dev->parent = parent;
dev->release = ata_tport_release;
dev_set_name(dev, "ata%d", ap->print_id);
transport_setup_device(dev);
@@ -348,7 +347,6 @@ static DECLARE_TRANSPORT_CLASS(ata_link_
static void ata_tlink_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -410,7 +408,7 @@ int ata_tlink_add(struct ata_link *link)
int error;
device_initialize(dev);
- dev->parent = get_device(&ap->tdev);
+ dev->parent = &ap->tdev;
dev->release = ata_tlink_release;
if (ata_is_host_link(link))
dev_set_name(dev, "link%d", ap->print_id);
@@ -589,7 +587,6 @@ static DECLARE_TRANSPORT_CLASS(ata_dev_c
static void ata_tdev_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -662,7 +659,7 @@ static int ata_tdev_add(struct ata_devic
int error;
device_initialize(dev);
- dev->parent = get_device(&link->tdev);
+ dev->parent = &link->tdev;
dev->release = ata_tdev_release;
if (ata_is_host_link(link))
dev_set_name(dev, "dev%d.%d", ap->print_id,ata_dev->devno);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 095/104] ARM: dts: BCM5301X: Fix memory start address
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (88 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 094/104] libata: transport: Remove circular dependency at free time Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 096/104] tools/power turbostat: bugfix: GFXMHz column not changing Greg Kroah-Hartman
` (11 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jon Mason, Florian Fainelli, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jon Mason <jon.mason@broadcom.com>
[ Upstream commit 88d1fa70c21d7b431386cfe70cdc514d98b0c9c4 ]
Memory starts at 0x80000000, not 0. 0 "works" due to mirrior of the
first 128M of RAM to that address. Anything greater than 128M will
quickly find nothing there. Correcting the starting address has
everything working again.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Fixes: 7eb05f6d ("ARM: dts: bcm5301x: Add BCM SVK DT files")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/bcm953012k.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/bcm953012k.dts
+++ b/arch/arm/boot/dts/bcm953012k.dts
@@ -48,7 +48,7 @@
};
memory {
- reg = <0x00000000 0x10000000>;
+ reg = <0x80000000 0x10000000>;
};
};
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 096/104] tools/power turbostat: bugfix: GFXMHz column not changing
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (89 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 095/104] ARM: dts: BCM5301X: Fix memory start address Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 097/104] IB/qib: fix false-postive maybe-uninitialized warning Greg Kroah-Hartman
` (10 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yaroslav Isakov, Len Brown, Sasha Levin
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Len Brown <len.brown@intel.com>
[ Upstream commit 22048c5485503749754b3b5daf9d99ef89fcacdc ]
turbostat displays a GFXMHz column, which comes from reading
/sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz
But GFXMHz was not changing, even when a manual
cat /sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz
showed a new value.
It turns out that a rewind() on the open file is not sufficient,
fflush() (or a close/open) is needed to read fresh values.
Reported-by: Yaroslav Isakov <yaroslav.isakov@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/power/x86/turbostat/turbostat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -2003,8 +2003,10 @@ int snapshot_gfx_mhz(void)
if (fp == NULL)
fp = fopen_or_die("/sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz", "r");
- else
+ else {
rewind(fp);
+ fflush(fp);
+ }
retval = fscanf(fp, "%d", &gfx_cur_mhz);
if (retval != 1)
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 097/104] IB/qib: fix false-postive maybe-uninitialized warning
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (90 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 096/104] tools/power turbostat: bugfix: GFXMHz column not changing Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 099/104] ASoC: rt5514: fix gcc-7 warning Greg Kroah-Hartman
` (9 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Ira Weiny, Doug Ledford
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit f6aafac184a3e46e919769dd4faa8bf0dc436534 upstream.
aarch64-linux-gcc-7 complains about code it doesn't fully understand:
drivers/infiniband/hw/qib/qib_iba7322.c: In function 'qib_7322_txchk_change':
include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The code is right, and despite trying hard, I could not come up with a version
that I liked better than just adding a fake initialization here to shut up the
warning.
Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/qib/qib_iba7322.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/qib/qib_iba7322.c
+++ b/drivers/infiniband/hw/qib/qib_iba7322.c
@@ -7080,7 +7080,7 @@ static void qib_7322_txchk_change(struct
unsigned long flags;
while (wait) {
- unsigned long shadow;
+ unsigned long shadow = 0;
int cstart, previ = -1;
/*
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 099/104] ASoC: rt5514: fix gcc-7 warning
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (91 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 097/104] IB/qib: fix false-postive maybe-uninitialized warning Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 100/104] ASoC: rt5659: drop double const Greg Kroah-Hartman
` (8 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Mark Brown
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit 03ba791df98d15d07ea74075122af71e35c7611c upstream.
gcc-7 warns that there is a duplicate 'const' specifier in some
variables that are declared using the SOC_ENUM_SINGLE_DECL macro:
sound/soc/codecs/rt5514.c:398:14: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
sound/soc/codecs/rt5514.c:405:14: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
This removes one to fix the warning.
Fixes: 4a6180ea7399 ("ASoC: rt5514: add rt5514 codec driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/codecs/rt5514.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/codecs/rt5514.c
+++ b/sound/soc/codecs/rt5514.c
@@ -395,14 +395,14 @@ static const char * const rt5514_dmic_sr
"DMIC1", "DMIC2"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo1_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD0_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
static const struct snd_kcontrol_new rt5514_sto1_dmic_mux =
SOC_DAPM_ENUM("Stereo1 DMIC Source", rt5514_stereo1_dmic_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo2_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD1_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 100/104] ASoC: rt5659: drop double const
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (92 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 099/104] ASoC: rt5514: fix gcc-7 warning Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 101/104] ASoC: rt5660: remove " Greg Kroah-Hartman
` (7 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nicholas Mc Guire, Mark Brown, Arnd Bergmann
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Mc Guire <hofrat@osadl.org>
commit eae39b5f4269260d5d8b35133ba0f4c5e2895b71 upstream.
Drop the const qualifier as it is being added by SOC_ENUM_DOUBLE_DECL()
already which is called by SOC_ENUM_SINGLE_DECL() as well as the
double const by calls to SOC_VALUE_ENUM_SINGLE_DECL() via
SOC_VALUE_ENUM_DOUBLE_DECL).
Fixes: commit d3cb2de2479b ("ASoC: rt5659: add rt5659 codec driver")
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/codecs/rt5659.c | 86 +++++++++++++++++++++++-----------------------
1 file changed, 43 insertions(+), 43 deletions(-)
--- a/sound/soc/codecs/rt5659.c
+++ b/sound/soc/codecs/rt5659.c
@@ -1150,28 +1150,28 @@ static const char * const rt5659_data_se
"L/R", "R/L", "L/L", "R/R"
};
-static const SOC_ENUM_SINGLE_DECL(rt5659_if1_01_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if1_01_adc_enum,
RT5659_TDM_CTRL_2, RT5659_DS_ADC_SLOT01_SFT, rt5659_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5659_if1_23_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if1_23_adc_enum,
RT5659_TDM_CTRL_2, RT5659_DS_ADC_SLOT23_SFT, rt5659_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5659_if1_45_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if1_45_adc_enum,
RT5659_TDM_CTRL_2, RT5659_DS_ADC_SLOT45_SFT, rt5659_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5659_if1_67_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if1_67_adc_enum,
RT5659_TDM_CTRL_2, RT5659_DS_ADC_SLOT67_SFT, rt5659_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5659_if2_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if2_dac_enum,
RT5659_DIG_INF23_DATA, RT5659_IF2_DAC_SEL_SFT, rt5659_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5659_if2_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if2_adc_enum,
RT5659_DIG_INF23_DATA, RT5659_IF2_ADC_SEL_SFT, rt5659_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5659_if3_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if3_dac_enum,
RT5659_DIG_INF23_DATA, RT5659_IF3_DAC_SEL_SFT, rt5659_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5659_if3_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5659_if3_adc_enum,
RT5659_DIG_INF23_DATA, RT5659_IF3_ADC_SEL_SFT, rt5659_data_select);
static const struct snd_kcontrol_new rt5659_if1_01_adc_swap_mux =
@@ -1207,31 +1207,31 @@ static unsigned int rt5659_asrc_clk_map_
0, 1, 2, 3, 5, 6,
};
-static const SOC_VALUE_ENUM_SINGLE_DECL(
+static SOC_VALUE_ENUM_SINGLE_DECL(
rt5659_da_sto_asrc_enum, RT5659_ASRC_2, RT5659_DA_STO_T_SFT, 0x7,
rt5659_asrc_clk_src, rt5659_asrc_clk_map_values);
-static const SOC_VALUE_ENUM_SINGLE_DECL(
+static SOC_VALUE_ENUM_SINGLE_DECL(
rt5659_da_monol_asrc_enum, RT5659_ASRC_2, RT5659_DA_MONO_L_T_SFT, 0x7,
rt5659_asrc_clk_src, rt5659_asrc_clk_map_values);
-static const SOC_VALUE_ENUM_SINGLE_DECL(
+static SOC_VALUE_ENUM_SINGLE_DECL(
rt5659_da_monor_asrc_enum, RT5659_ASRC_2, RT5659_DA_MONO_R_T_SFT, 0x7,
rt5659_asrc_clk_src, rt5659_asrc_clk_map_values);
-static const SOC_VALUE_ENUM_SINGLE_DECL(
+static SOC_VALUE_ENUM_SINGLE_DECL(
rt5659_ad_sto1_asrc_enum, RT5659_ASRC_2, RT5659_AD_STO1_T_SFT, 0x7,
rt5659_asrc_clk_src, rt5659_asrc_clk_map_values);
-static const SOC_VALUE_ENUM_SINGLE_DECL(
+static SOC_VALUE_ENUM_SINGLE_DECL(
rt5659_ad_sto2_asrc_enum, RT5659_ASRC_3, RT5659_AD_STO2_T_SFT, 0x7,
rt5659_asrc_clk_src, rt5659_asrc_clk_map_values);
-static const SOC_VALUE_ENUM_SINGLE_DECL(
+static SOC_VALUE_ENUM_SINGLE_DECL(
rt5659_ad_monol_asrc_enum, RT5659_ASRC_3, RT5659_AD_MONO_L_T_SFT, 0x7,
rt5659_asrc_clk_src, rt5659_asrc_clk_map_values);
-static const SOC_VALUE_ENUM_SINGLE_DECL(
+static SOC_VALUE_ENUM_SINGLE_DECL(
rt5659_ad_monor_asrc_enum, RT5659_ASRC_3, RT5659_AD_MONO_R_T_SFT, 0x7,
rt5659_asrc_clk_src, rt5659_asrc_clk_map_values);
@@ -1930,14 +1930,14 @@ static const char * const rt5659_dac2_sr
"IF1 DAC2", "IF2 DAC", "IF3 DAC", "Mono ADC MIX"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_dac_l2_enum, RT5659_DAC_CTRL,
RT5659_DAC_L2_SEL_SFT, rt5659_dac2_src);
static const struct snd_kcontrol_new rt5659_dac_l2_mux =
SOC_DAPM_ENUM("DAC L2 Source", rt5659_dac_l2_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_dac_r2_enum, RT5659_DAC_CTRL,
RT5659_DAC_R2_SEL_SFT, rt5659_dac2_src);
@@ -1951,7 +1951,7 @@ static const char * const rt5659_sto1_ad
"DAC MIX", "ADC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_sto1_adc1_enum, RT5659_STO1_ADC_MIXER,
RT5659_STO1_ADC1_SRC_SFT, rt5659_sto1_adc1_src);
@@ -1964,7 +1964,7 @@ static const char * const rt5659_sto1_ad
"ADC1", "ADC2"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_sto1_adc_enum, RT5659_STO1_ADC_MIXER,
RT5659_STO1_ADC_SRC_SFT, rt5659_sto1_adc_src);
@@ -1977,7 +1977,7 @@ static const char * const rt5659_sto1_ad
"DAC MIX", "DMIC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_sto1_adc2_enum, RT5659_STO1_ADC_MIXER,
RT5659_STO1_ADC2_SRC_SFT, rt5659_sto1_adc2_src);
@@ -1990,7 +1990,7 @@ static const char * const rt5659_sto1_dm
"DMIC1", "DMIC2"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_sto1_dmic_enum, RT5659_STO1_ADC_MIXER,
RT5659_STO1_DMIC_SRC_SFT, rt5659_sto1_dmic_src);
@@ -2004,7 +2004,7 @@ static const char * const rt5659_mono_ad
"Mono DAC MIXL", "DMIC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_adc_l2_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_ADC_L2_SRC_SFT, rt5659_mono_adc_l2_src);
@@ -2018,7 +2018,7 @@ static const char * const rt5659_mono_ad
"Mono DAC MIXL", "ADC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_adc_l1_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_ADC_L1_SRC_SFT, rt5659_mono_adc_l1_src);
@@ -2031,14 +2031,14 @@ static const char * const rt5659_mono_ad
"ADC1 L", "ADC1 R", "ADC2 L", "ADC2 R"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_adc_l_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_ADC_L_SRC_SFT, rt5659_mono_adc_src);
static const struct snd_kcontrol_new rt5659_mono_adc_l_mux =
SOC_DAPM_ENUM("Mono ADC L Source", rt5659_mono_adc_l_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_adcr_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_ADC_R_SRC_SFT, rt5659_mono_adc_src);
@@ -2051,7 +2051,7 @@ static const char * const rt5659_mono_dm
"DMIC1 L", "DMIC2 L"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_dmic_l_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_DMIC_L_SRC_SFT, rt5659_mono_dmic_l_src);
@@ -2064,7 +2064,7 @@ static const char * const rt5659_mono_ad
"Mono DAC MIXR", "DMIC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_adc_r2_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_ADC_R2_SRC_SFT, rt5659_mono_adc_r2_src);
@@ -2077,7 +2077,7 @@ static const char * const rt5659_mono_ad
"Mono DAC MIXR", "ADC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_adc_r1_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_ADC_R1_SRC_SFT, rt5659_mono_adc_r1_src);
@@ -2090,7 +2090,7 @@ static const char * const rt5659_mono_dm
"DMIC1 R", "DMIC2 R"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_mono_dmic_r_enum, RT5659_MONO_ADC_MIXER,
RT5659_MONO_DMIC_R_SRC_SFT, rt5659_mono_dmic_r_src);
@@ -2104,14 +2104,14 @@ static const char * const rt5659_dac1_sr
"IF1 DAC1", "IF2 DAC", "IF3 DAC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_dac_r1_enum, RT5659_AD_DA_MIXER,
RT5659_DAC1_R_SEL_SFT, rt5659_dac1_src);
static const struct snd_kcontrol_new rt5659_dac_r1_mux =
SOC_DAPM_ENUM("DAC R1 Source", rt5659_dac_r1_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_dac_l1_enum, RT5659_AD_DA_MIXER,
RT5659_DAC1_L_SEL_SFT, rt5659_dac1_src);
@@ -2124,14 +2124,14 @@ static const char * const rt5659_dig_dac
"Stereo DAC Mixer", "Mono DAC Mixer"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_dig_dac_mixl_enum, RT5659_DIG_MIXER,
RT5659_DAC_MIX_L_SFT, rt5659_dig_dac_mix_src);
static const struct snd_kcontrol_new rt5659_dig_dac_mixl_mux =
SOC_DAPM_ENUM("DAC Digital Mixer L Source", rt5659_dig_dac_mixl_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_dig_dac_mixr_enum, RT5659_DIG_MIXER,
RT5659_DAC_MIX_R_SFT, rt5659_dig_dac_mix_src);
@@ -2144,14 +2144,14 @@ static const char * const rt5659_alg_dac
"DAC", "Stereo DAC Mixer"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_alg_dac_l1_enum, RT5659_A_DAC_MUX,
RT5659_A_DACL1_SFT, rt5659_alg_dac1_src);
static const struct snd_kcontrol_new rt5659_alg_dac_l1_mux =
SOC_DAPM_ENUM("Analog DACL1 Source", rt5659_alg_dac_l1_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_alg_dac_r1_enum, RT5659_A_DAC_MUX,
RT5659_A_DACR1_SFT, rt5659_alg_dac1_src);
@@ -2164,14 +2164,14 @@ static const char * const rt5659_alg_dac
"Stereo DAC Mixer", "Mono DAC Mixer"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_alg_dac_l2_enum, RT5659_A_DAC_MUX,
RT5659_A_DACL2_SFT, rt5659_alg_dac2_src);
static const struct snd_kcontrol_new rt5659_alg_dac_l2_mux =
SOC_DAPM_ENUM("Analog DAC L2 Source", rt5659_alg_dac_l2_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_alg_dac_r2_enum, RT5659_A_DAC_MUX,
RT5659_A_DACR2_SFT, rt5659_alg_dac2_src);
@@ -2184,7 +2184,7 @@ static const char * const rt5659_if2_adc
"IF_ADC1", "IF_ADC2", "DAC_REF", "IF_ADC3"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_if2_adc_in_enum, RT5659_DIG_INF23_DATA,
RT5659_IF2_ADC_IN_SFT, rt5659_if2_adc_in_src);
@@ -2197,7 +2197,7 @@ static const char * const rt5659_if3_adc
"IF_ADC1", "IF_ADC2", "DAC_REF", "Stereo2_ADC_L/R"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_if3_adc_in_enum, RT5659_DIG_INF23_DATA,
RT5659_IF3_ADC_IN_SFT, rt5659_if3_adc_in_src);
@@ -2210,14 +2210,14 @@ static const char * const rt5659_pdm_src
"Mono DAC", "Stereo DAC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_pdm_l_enum, RT5659_PDM_OUT_CTRL,
RT5659_PDM1_L_SFT, rt5659_pdm_src);
static const struct snd_kcontrol_new rt5659_pdm_l_mux =
SOC_DAPM_ENUM("PDM L Source", rt5659_pdm_l_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_pdm_r_enum, RT5659_PDM_OUT_CTRL,
RT5659_PDM1_R_SFT, rt5659_pdm_src);
@@ -2230,7 +2230,7 @@ static const char * const rt5659_spdif_s
"IF1_DAC1", "IF1_DAC2", "IF2_DAC", "IF3_DAC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_spdif_enum, RT5659_SPDIF_CTRL,
RT5659_SPDIF_SEL_SFT, rt5659_spdif_src);
@@ -2250,7 +2250,7 @@ static const char * const rt5659_rx_adc_
"NUL:AD2:DAC:AD1", "NUL:DAC:DAC:AD2", "NUL:DAC:AD2:DAC"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5659_rx_adc_data_enum, RT5659_TDM_CTRL_2,
RT5659_ADCDAT_SRC_SFT, rt5659_rx_adc_data_src);
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 101/104] ASoC: rt5660: remove double const
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (93 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 100/104] ASoC: rt5659: drop double const Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 102/104] ALSA: au88x0: avoid theoretical uninitialized access Greg Kroah-Hartman
` (6 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Nicholas Mc Guire, Mark Brown
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Mc Guire <hofrat@osadl.org>
commit 4281fcc02ed9f902dfa52d3635ac7f04b1a7341f upstream.
Drop the const qualifier as it is being added by SOC_ENUM_DOUBLE_DECL()
already which is called by SOC_ENUM_SINGLE_DECL() here.
Fixes: commit 2b26dd4c1fc5 ("ASoC: rt5660: add rt5660 codec driver")
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/codecs/rt5660.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/codecs/rt5660.c
+++ b/sound/soc/codecs/rt5660.c
@@ -526,10 +526,10 @@ static const char * const rt5660_data_se
"L/R", "R/L", "L/L", "R/R"
};
-static const SOC_ENUM_SINGLE_DECL(rt5660_if1_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5660_if1_dac_enum,
RT5660_DIG_INF1_DATA, RT5660_IF1_DAC_IN_SFT, rt5660_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5660_if1_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5660_if1_adc_enum,
RT5660_DIG_INF1_DATA, RT5660_IF1_ADC_IN_SFT, rt5660_data_select);
static const struct snd_kcontrol_new rt5660_if1_dac_swap_mux =
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 102/104] ALSA: au88x0: avoid theoretical uninitialized access
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (94 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 101/104] ASoC: rt5660: remove " Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 103/104] [media] ttpci: address stringop overflow warning Greg Kroah-Hartman
` (5 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Takashi Iwai
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit 13f99ebdd602ebdafb909e15ec6ffb1e34690167 upstream.
The latest gcc-7.0.1 snapshot points out that we if nr_ch is zero, we never
initialize some variables:
sound/pci/au88x0/au88x0_core.c: In function 'vortex_adb_allocroute':
sound/pci/au88x0/au88x0_core.c:2304:68: error: 'mix[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
sound/pci/au88x0/au88x0_core.c:2305:58: error: 'src[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
I assume this can never happen in practice, but adding a check here doesn't
hurt either and avoids the warning. The code has been unchanged since
the start of git history.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/au88x0/au88x0_core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/sound/pci/au88x0/au88x0_core.c
+++ b/sound/pci/au88x0/au88x0_core.c
@@ -2279,6 +2279,9 @@ vortex_adb_allocroute(vortex_t *vortex,
} else {
int src[2], mix[2];
+ if (nr_ch < 1)
+ return -EINVAL;
+
/* Get SRC and MIXER hardware resources. */
for (i = 0; i < nr_ch; i++) {
if ((mix[i] =
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 103/104] [media] ttpci: address stringop overflow warning
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (95 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 102/104] ALSA: au88x0: avoid theoretical uninitialized access Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 8:52 ` [PATCH 4.9 104/104] s390/mm: make pmdp_invalidate() do invalidation only Greg Kroah-Hartman
` (4 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Mauro Carvalho Chehab
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit 69d3973af1acd4c0989ec8218c05f12d303cd7cf upstream.
gcc-7.0.1 warns about old code in ttpci:
In file included from drivers/media/pci/ttpci/av7110.c:63:0:
In function 'irdebi.isra.2',
inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:659:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
memcpy(av7110->debi_virt, (char *) &res, count);
In function 'irdebi.isra.2',
inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:668:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
memcpy(av7110->debi_virt, (char *) &res, count);
Apparently, 'count' can be negative here, which will then get turned
into a giant size argument for memcpy. Changing the sizes to 'unsigned
int' instead seems safe as we already check for maximum sizes, and it
also simplifies the code a bit.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/pci/ttpci/av7110_hw.c | 8 ++++----
drivers/media/pci/ttpci/av7110_hw.h | 12 ++++++------
2 files changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/media/pci/ttpci/av7110_hw.c
+++ b/drivers/media/pci/ttpci/av7110_hw.c
@@ -56,11 +56,11 @@
by Nathan Laredo <laredo@gnu.org> */
int av7110_debiwrite(struct av7110 *av7110, u32 config,
- int addr, u32 val, int count)
+ int addr, u32 val, unsigned int count)
{
struct saa7146_dev *dev = av7110->dev;
- if (count <= 0 || count > 32764) {
+ if (count > 32764) {
printk("%s: invalid count %d\n", __func__, count);
return -1;
}
@@ -78,12 +78,12 @@ int av7110_debiwrite(struct av7110 *av71
return 0;
}
-u32 av7110_debiread(struct av7110 *av7110, u32 config, int addr, int count)
+u32 av7110_debiread(struct av7110 *av7110, u32 config, int addr, unsigned int count)
{
struct saa7146_dev *dev = av7110->dev;
u32 result = 0;
- if (count > 32764 || count <= 0) {
+ if (count > 32764) {
printk("%s: invalid count %d\n", __func__, count);
return 0;
}
--- a/drivers/media/pci/ttpci/av7110_hw.h
+++ b/drivers/media/pci/ttpci/av7110_hw.h
@@ -377,14 +377,14 @@ extern int av7110_fw_request(struct av71
/* DEBI (saa7146 data extension bus interface) access */
extern int av7110_debiwrite(struct av7110 *av7110, u32 config,
- int addr, u32 val, int count);
+ int addr, u32 val, unsigned int count);
extern u32 av7110_debiread(struct av7110 *av7110, u32 config,
- int addr, int count);
+ int addr, unsigned int count);
/* DEBI during interrupt */
/* single word writes */
-static inline void iwdebi(struct av7110 *av7110, u32 config, int addr, u32 val, int count)
+static inline void iwdebi(struct av7110 *av7110, u32 config, int addr, u32 val, unsigned int count)
{
av7110_debiwrite(av7110, config, addr, val, count);
}
@@ -397,7 +397,7 @@ static inline void mwdebi(struct av7110
av7110_debiwrite(av7110, config, addr, 0, count);
}
-static inline u32 irdebi(struct av7110 *av7110, u32 config, int addr, u32 val, int count)
+static inline u32 irdebi(struct av7110 *av7110, u32 config, int addr, u32 val, unsigned int count)
{
u32 res;
@@ -408,7 +408,7 @@ static inline u32 irdebi(struct av7110 *
}
/* DEBI outside interrupts, only for count <= 4! */
-static inline void wdebi(struct av7110 *av7110, u32 config, int addr, u32 val, int count)
+static inline void wdebi(struct av7110 *av7110, u32 config, int addr, u32 val, unsigned int count)
{
unsigned long flags;
@@ -417,7 +417,7 @@ static inline void wdebi(struct av7110 *
spin_unlock_irqrestore(&av7110->debilock, flags);
}
-static inline u32 rdebi(struct av7110 *av7110, u32 config, int addr, u32 val, int count)
+static inline u32 rdebi(struct av7110 *av7110, u32 config, int addr, u32 val, unsigned int count)
{
unsigned long flags;
u32 res;
^ permalink raw reply [flat|nested] 144+ messages in thread* [PATCH 4.9 104/104] s390/mm: make pmdp_invalidate() do invalidation only
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (96 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 103/104] [media] ttpci: address stringop overflow warning Greg Kroah-Hartman
@ 2017-10-06 8:52 ` Greg Kroah-Hartman
2017-10-06 14:08 ` [PATCH 4.9 000/104] 4.9.54-stable review Guenter Roeck
` (3 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-06 8:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gerald Schaefer, Martin Schwidefsky
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
commit 91c575b335766effa6103eba42a82aea560c365f upstream.
Commit 227be799c39a ("s390/mm: uninline pmdp_xxx functions from pgtable.h")
inadvertently changed the behavior of pmdp_invalidate(), so that it now
clears the pmd instead of just marking it as invalid. Fix this by restoring
the original behavior.
A possible impact of the misbehaving pmdp_invalidate() would be the
MADV_DONTNEED races (see commits ced10803 and 58ceeb6b), although we
should not have any negative impact on the related dirty/young flags,
since those flags are not set by the hardware on s390.
Fixes: 227be799c39a ("s390/mm: uninline pmdp_xxx functions from pgtable.h")
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/include/asm/pgtable.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1359,7 +1359,9 @@ static inline pmd_t pmdp_huge_clear_flus
static inline void pmdp_invalidate(struct vm_area_struct *vma,
unsigned long addr, pmd_t *pmdp)
{
- pmdp_xchg_direct(vma->vm_mm, addr, pmdp, __pmd(_SEGMENT_ENTRY_INVALID));
+ pmd_t pmd = __pmd(pmd_val(*pmdp) | _SEGMENT_ENTRY_INVALID);
+
+ pmdp_xchg_direct(vma->vm_mm, addr, pmdp, pmd);
}
#define __HAVE_ARCH_PMDP_SET_WRPROTECT
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (97 preceding siblings ...)
2017-10-06 8:52 ` [PATCH 4.9 104/104] s390/mm: make pmdp_invalidate() do invalidation only Greg Kroah-Hartman
@ 2017-10-06 14:08 ` Guenter Roeck
2017-10-07 9:38 ` Greg Kroah-Hartman
2017-10-06 18:06 ` Shuah Khan
` (2 subsequent siblings)
101 siblings, 1 reply; 144+ messages in thread
From: Guenter Roeck @ 2017-10-06 14:08 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On 10/06/2017 01:50 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.54 release.
> There are 104 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 Oct 8 08:37:55 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 142 fail: 3
Failed builds:
arm64:allmodconfig
mips:allmodconfig
mips:ar7_defconfig
Qemu test results:
total: 123 pass: 123 fail: 0
Build failures:
arm64:allmodconfig:
In file included from include/linux/topology.h:32:0,
from include/linux/sched.h:42,
from linux/kasan.h:4,
from arch/arm64/mm/kasan_init.c:14:
arch/arm64/mm/kasan_init.c: In function ‘kasan_init’:
arch/arm64/mm/kasan_init.c:156:28: error: implicit declaration of function ‘lm_alias’
mips:
arch/mips/kernel/setup.c: In function 'mips_parse_crashkernel':
arch/mips/kernel/setup.c:671:2: error: implicit declaration of function 'memory_region_available'
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-06 14:08 ` [PATCH 4.9 000/104] 4.9.54-stable review Guenter Roeck
@ 2017-10-07 9:38 ` Greg Kroah-Hartman
0 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-07 9:38 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Fri, Oct 06, 2017 at 07:08:27AM -0700, Guenter Roeck wrote:
> On 10/06/2017 01:50 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.54 release.
> > There are 104 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 Oct 8 08:37:55 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 145 pass: 142 fail: 3
> Failed builds:
> arm64:allmodconfig
> mips:allmodconfig
> mips:ar7_defconfig
> Qemu test results:
> total: 123 pass: 123 fail: 0
>
> Build failures:
>
> arm64:allmodconfig:
>
> In file included from include/linux/topology.h:32:0,
> from include/linux/sched.h:42,
> from linux/kasan.h:4,
> from arch/arm64/mm/kasan_init.c:14:
> arch/arm64/mm/kasan_init.c: In function ‘kasan_init’:
> arch/arm64/mm/kasan_init.c:156:28: error: implicit declaration of function ‘lm_alias’
>
> mips:
>
> arch/mips/kernel/setup.c: In function 'mips_parse_crashkernel':
> arch/mips/kernel/setup.c:671:2: error: implicit declaration of function 'memory_region_available'
Both of these should now be resolved, thanks.
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (98 preceding siblings ...)
2017-10-06 14:08 ` [PATCH 4.9 000/104] 4.9.54-stable review Guenter Roeck
@ 2017-10-06 18:06 ` Shuah Khan
2017-10-07 9:39 ` Greg Kroah-Hartman
2017-10-07 16:56 ` Tom Gall
101 siblings, 0 replies; 144+ messages in thread
From: Shuah Khan @ 2017-10-06 18:06 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, stable, Shuah Khan
On 10/06/2017 02:50 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.54 release.
> There are 104 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 Oct 8 08:37:55 UTC 2017.
> 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.54-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
>
Compiled and booted on my test system. No dmesg regressions.
No regressions in selftest run (non-root tests only) compared
to 4.9.53 run with 4.14-rc3 selftests.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
` (99 preceding siblings ...)
2017-10-06 18:06 ` Shuah Khan
@ 2017-10-07 9:39 ` Greg Kroah-Hartman
2017-10-07 14:44 ` Guenter Roeck
2017-10-07 16:56 ` Tom Gall
101 siblings, 1 reply; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-07 9:39 UTC (permalink / raw)
To: linux-kernel
Cc: torvalds, akpm, linux, shuahkh, patches, ben.hutchings, stable
On Fri, Oct 06, 2017 at 10:50:38AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.54 release.
> There are 104 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 Oct 8 08:37:55 UTC 2017.
> 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.54-rc1.gz
Ok, that had issues, so -rc2 is now out:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.54-rc2.gz
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-07 9:39 ` Greg Kroah-Hartman
@ 2017-10-07 14:44 ` Guenter Roeck
2017-10-08 7:20 ` Greg Kroah-Hartman
0 siblings, 1 reply; 144+ messages in thread
From: Guenter Roeck @ 2017-10-07 14:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On 10/07/2017 02:39 AM, Greg Kroah-Hartman wrote:
> On Fri, Oct 06, 2017 at 10:50:38AM +0200, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.9.54 release.
>> There are 104 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 Oct 8 08:37:55 UTC 2017.
>> 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.54-rc1.gz
>
> Ok, that had issues, so -rc2 is now out:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.54-rc2.gz
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 123 pass: 123 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-07 14:44 ` Guenter Roeck
@ 2017-10-08 7:20 ` Greg Kroah-Hartman
0 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-08 7:20 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Sat, Oct 07, 2017 at 07:44:24AM -0700, Guenter Roeck wrote:
> On 10/07/2017 02:39 AM, Greg Kroah-Hartman wrote:
> > On Fri, Oct 06, 2017 at 10:50:38AM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.9.54 release.
> > > There are 104 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 Oct 8 08:37:55 UTC 2017.
> > > 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.54-rc1.gz
> >
> > Ok, that had issues, so -rc2 is now out:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.54-rc2.gz
> >
>
>
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 123 pass: 123 fail: 0
>
> Details are available at http://kerneltests.org/builders.
Great, thanks for letting me know.
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-06 8:50 [PATCH 4.9 000/104] 4.9.54-stable review Greg Kroah-Hartman
@ 2017-10-07 16:56 ` Tom Gall
2017-10-06 8:50 ` [PATCH 4.9 002/104] drm: bridge: add DT bindings for TI ths8135 Greg Kroah-Hartman
` (100 subsequent siblings)
101 siblings, 0 replies; 144+ messages in thread
From: Tom Gall @ 2017-10-07 16:56 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, linux- stable
> On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.9.54 release.
> There are 104 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 Oct 8 08:37:55 UTC 2017.
> 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.54-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
>From Linaro’s validation farm we have the following test results for this 4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition. Also this time around more of LTP is being run. There is triage to do and you’ll notice that I’m differentiating between ‘known failures’ and ‘failures’ in the data below. The later obviously will get looked at so we can graduate failures to known failures/fixes and improve finding regressions. (Anyone want to help?) In summary I wouldn’t hold up 4.9.54 based on the failures in the new data below. Given it’s a Sat, the Mrs has plans, I’ve no time to do further digging until later.
kernel: 4.9.54-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 1852eae92c460813692808234da35d142a405ab7
git describe: v4.9.53
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
No regressions (compared to build v4.9.52-65-gaceea42c68d9)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests 964 pass - 136 skip
* ltp-timers-tests - 13 pass
juno-r2 - arm64
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
x15 - arm
* boot - 1 pass
* kselftest - 36 pass - 1 skip - 16 fail
* ltp-syscalls-tests - 1020 pass - 80 skip
dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 53 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests 2 pass
* ltp-commands-tests - 23 pass - 13 skip - 8 fail
* ltp-containers-tests - 63 pass - 18 fail
* ltp-fcntl-locktests-tests 2 pass
* ltp-filecaps-tests 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 3 pass
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures
* ltp-timers-tests - 13 pass
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
^ permalink raw reply [flat|nested] 144+ messages in thread* Re: [PATCH 4.9 000/104] 4.9.54-stable review
@ 2017-10-07 16:56 ` Tom Gall
0 siblings, 0 replies; 144+ messages in thread
From: Tom Gall @ 2017-10-07 16:56 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, linux- stable
> On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.9.54 release.
> There are 104 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 Oct 8 08:37:55 UTC 2017.
> 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.54-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
From Linaro’s validation farm we have the following test results for this 4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition. Also this time around more of LTP is being run. There is triage to do and you’ll notice that I’m differentiating between ‘known failures’ and ‘failures’ in the data below. The later obviously will get looked at so we can graduate failures to known failures/fixes and improve finding regressions. (Anyone want to help?) In summary I wouldn’t hold up 4.9.54 based on the failures in the new data below. Given it’s a Sat, the Mrs has plans, I’ve no time to do further digging until later.
kernel: 4.9.54-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 1852eae92c460813692808234da35d142a405ab7
git describe: v4.9.53
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
No regressions (compared to build v4.9.52-65-gaceea42c68d9)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests 964 pass - 136 skip
* ltp-timers-tests - 13 pass
juno-r2 - arm64
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
x15 - arm
* boot - 1 pass
* kselftest - 36 pass - 1 skip - 16 fail
* ltp-syscalls-tests - 1020 pass - 80 skip
dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 53 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests 2 pass
* ltp-commands-tests - 23 pass - 13 skip - 8 fail
* ltp-containers-tests - 63 pass - 18 fail
* ltp-fcntl-locktests-tests 2 pass
* ltp-filecaps-tests 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 3 pass
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures
* ltp-timers-tests - 13 pass
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-07 16:56 ` Tom Gall
(?)
@ 2017-10-08 7:23 ` Greg Kroah-Hartman
2017-10-09 20:37 ` Tom Gall
-1 siblings, 1 reply; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-08 7:23 UTC (permalink / raw)
To: Tom Gall
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, linux- stable
On Sat, Oct 07, 2017 at 11:56:17AM -0500, Tom Gall wrote:
>
> > On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 4.9.54 release.
> > There are 104 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 Oct 8 08:37:55 UTC 2017.
> > 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.54-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
>
> From Linaro’s validation farm we have the following test results for this 4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition. Also this time around more of LTP is being run. There is triage to do and you’ll notice that I’m differentiating between ‘known failures’ and ‘failures’ in the data below. The later obviously will get looked at so we can graduate failures to known failures/fixes and improve finding regressions. (Anyone want to help?) In summary I wouldn’t hold up 4.9.54 based on the failures in the new data below. Given it’s a Sat, the Mrs has plans, I’ve no time to do further digging until later.
/me hands Tom some '\n' characters...
:)
> kernel: 4.9.54-rc1
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> git branch: linux-4.9.y
> git commit: 1852eae92c460813692808234da35d142a405ab7
> git describe: v4.9.53
> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
>
>
> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
How did your arm64 test build? There was a build regression in the -rc1
release, are you sure you actually ran the correct image?
Thanks for testing this, finding out the root of these problems this
week would be great.
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-08 7:23 ` Greg Kroah-Hartman
@ 2017-10-09 20:37 ` Tom Gall
2017-10-10 7:11 ` Greg Kroah-Hartman
0 siblings, 1 reply; 144+ messages in thread
From: Tom Gall @ 2017-10-09 20:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: LKML, torvalds, akpm, Guenter Roeck, Shuah Khan, patches,
Ben Hutchings, linux- stable
Hi Greg,
On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 07, 2017 at 11:56:17AM -0500, Tom Gall wrote:
>>
>> > On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.9.54 release.
>> > There are 104 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 Oct 8 08:37:55 UTC 2017.
>> > 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.54-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
>>
>> From Linaro’s validation farm we have the following test results for this 4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition. Also this time around more of LTP is being run. There is triage to do and you’ll notice that I’m differentiating between ‘known failures’ and ‘failures’ in the data below. The later obviously will get looked at so we can graduate failures to known failures/fixes and improve finding regressions. (Anyone want to help?) In summary I wouldn’t hold up 4.9.54 based on the failures in the new data below. Given it’s a Sat, the Mrs has plans, I’ve no time to do further digging until later.
>
> /me hands Tom some '\n' characters...
>
> :)
w00t!
>> kernel: 4.9.54-rc1
>> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> git branch: linux-4.9.y
>> git commit: 1852eae92c460813692808234da35d142a405ab7
>> git describe: v4.9.53
>> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
>>
>> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
>
> How did your arm64 test build? There was a build regression in the -rc1
> release, are you sure you actually ran the correct image?
So the header in that report was wrong. That's a c/n/p error on my
part. I was in a rush to get you data before I was going to be gone
for the day on Sat and wanting to get what we had into your hands
before the Sunday deadline.
The test results was for the RC as of commit
0e59436504287cddb9663857ae69c100b55f5e85
If you want to see the 'ugly' raw data it's all here :
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> Thanks for testing this, finding out the root of these problems this
> week would be great.
We are on it.
> greg k-h
--
Regards,
Tom
Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-09 20:37 ` Tom Gall
@ 2017-10-10 7:11 ` Greg Kroah-Hartman
2017-10-10 15:23 ` Dan Rue
2017-10-10 15:23 ` Tom Gall
0 siblings, 2 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-10 7:11 UTC (permalink / raw)
To: Tom Gall
Cc: LKML, torvalds, akpm, Guenter Roeck, Shuah Khan, patches,
Ben Hutchings, linux- stable
On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >> kernel: 4.9.54-rc1
> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> git branch: linux-4.9.y
> >> git commit: 1852eae92c460813692808234da35d142a405ab7
> >> git describe: v4.9.53
> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
>
> >>
> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> >
> > How did your arm64 test build? There was a build regression in the -rc1
> > release, are you sure you actually ran the correct image?
>
> So the header in that report was wrong. That's a c/n/p error on my
> part. I was in a rush to get you data before I was going to be gone
> for the day on Sat and wanting to get what we had into your hands
> before the Sunday deadline.
>
> The test results was for the RC as of commit
> 0e59436504287cddb9663857ae69c100b55f5e85
>
> If you want to see the 'ugly' raw data it's all here :
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
I still don't understand. That _build_ should have failed, how did it
succeed enough to actually run the tests at all?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 7:11 ` Greg Kroah-Hartman
@ 2017-10-10 15:23 ` Dan Rue
2017-10-10 15:33 ` Greg Kroah-Hartman
2017-10-10 15:23 ` Tom Gall
1 sibling, 1 reply; 144+ messages in thread
From: Dan Rue @ 2017-10-10 15:23 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tom Gall, LKML, torvalds, akpm, Guenter Roeck, Shuah Khan,
patches, Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 07:11:55AM +0000, Greg Kroah-Hartman wrote:
> On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> > On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >> kernel: 4.9.54-rc1
> > >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > >> git branch: linux-4.9.y
> > >> git commit: 1852eae92c460813692808234da35d142a405ab7
> > >> git describe: v4.9.53
> > >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> >
> > >>
> > >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> > >
> > > How did your arm64 test build? There was a build regression in the -rc1
> > > release, are you sure you actually ran the correct image?
> >
> > So the header in that report was wrong. That's a c/n/p error on my
> > part. I was in a rush to get you data before I was going to be gone
> > for the day on Sat and wanting to get what we had into your hands
> > before the Sunday deadline.
> >
> > The test results was for the RC as of commit
> > 0e59436504287cddb9663857ae69c100b55f5e85
> >
> > If you want to see the 'ugly' raw data it's all here :
> > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
>
> I still don't understand. That _build_ should have failed, how did it
> succeed enough to actually run the tests at all?
It looks like the build failure shown at
http://arm-soc.lixom.net/buildlogs/stable-rc/v4.9.53-105-g0e59436/
requires CONFIG_KASAN to be set, which we do not set. All the other
configs built, including ours, which can be seen at
http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linux-stable-rc-4.9/67/defconfig
Dan
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 15:23 ` Dan Rue
@ 2017-10-10 15:33 ` Greg Kroah-Hartman
2017-10-10 15:54 ` Dan Rue
2017-10-10 23:11 ` Mark Brown
0 siblings, 2 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-10 15:33 UTC (permalink / raw)
To: Tom Gall, LKML, torvalds, akpm, Guenter Roeck, Shuah Khan,
patches, Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 10:23:00AM -0500, Dan Rue wrote:
> On Tue, Oct 10, 2017 at 07:11:55AM +0000, Greg Kroah-Hartman wrote:
> > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> > > On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >> kernel: 4.9.54-rc1
> > > >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > >> git branch: linux-4.9.y
> > > >> git commit: 1852eae92c460813692808234da35d142a405ab7
> > > >> git describe: v4.9.53
> > > >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> > >
> > > >>
> > > >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> > > >
> > > > How did your arm64 test build? There was a build regression in the -rc1
> > > > release, are you sure you actually ran the correct image?
> > >
> > > So the header in that report was wrong. That's a c/n/p error on my
> > > part. I was in a rush to get you data before I was going to be gone
> > > for the day on Sat and wanting to get what we had into your hands
> > > before the Sunday deadline.
> > >
> > > The test results was for the RC as of commit
> > > 0e59436504287cddb9663857ae69c100b55f5e85
> > >
> > > If you want to see the 'ugly' raw data it's all here :
> > > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> >
> > I still don't understand. That _build_ should have failed, how did it
> > succeed enough to actually run the tests at all?
>
> It looks like the build failure shown at
> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.9.53-105-g0e59436/
> requires CONFIG_KASAN to be set, which we do not set. All the other
> configs built, including ours, which can be seen at
> http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linux-stable-rc-4.9/67/defconfig
Thanks for the explaination.
How come you don't enable KASAN? Any other options you all should be
enabling to get better test coverage that you are not?
Are you doing a 'make allmodconfig' type build for these arches?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 15:33 ` Greg Kroah-Hartman
@ 2017-10-10 15:54 ` Dan Rue
2017-10-10 16:05 ` Greg Kroah-Hartman
2017-10-10 23:11 ` Mark Brown
1 sibling, 1 reply; 144+ messages in thread
From: Dan Rue @ 2017-10-10 15:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tom Gall, LKML, torvalds, akpm, Guenter Roeck, Shuah Khan,
patches, Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 03:33:47PM +0000, Greg Kroah-Hartman wrote:
> On Tue, Oct 10, 2017 at 10:23:00AM -0500, Dan Rue wrote:
> > On Tue, Oct 10, 2017 at 07:11:55AM +0000, Greg Kroah-Hartman wrote:
> > > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> > > > On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >> kernel: 4.9.54-rc1
> > > > >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > >> git branch: linux-4.9.y
> > > > >> git commit: 1852eae92c460813692808234da35d142a405ab7
> > > > >> git describe: v4.9.53
> > > > >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> > > >
> > > > >>
> > > > >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> > > > >
> > > > > How did your arm64 test build? There was a build regression in the -rc1
> > > > > release, are you sure you actually ran the correct image?
> > > >
> > > > So the header in that report was wrong. That's a c/n/p error on my
> > > > part. I was in a rush to get you data before I was going to be gone
> > > > for the day on Sat and wanting to get what we had into your hands
> > > > before the Sunday deadline.
> > > >
> > > > The test results was for the RC as of commit
> > > > 0e59436504287cddb9663857ae69c100b55f5e85
> > > >
> > > > If you want to see the 'ugly' raw data it's all here :
> > > > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> > >
> > > I still don't understand. That _build_ should have failed, how did it
> > > succeed enough to actually run the tests at all?
> >
> > It looks like the build failure shown at
> > http://arm-soc.lixom.net/buildlogs/stable-rc/v4.9.53-105-g0e59436/
> > requires CONFIG_KASAN to be set, which we do not set. All the other
> > configs built, including ours, which can be seen at
> > http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linux-stable-rc-4.9/67/defconfig
>
> Thanks for the explaination.
>
> How come you don't enable KASAN? Any other options you all should be
> enabling to get better test coverage that you are not?
>
> Are you doing a 'make allmodconfig' type build for these arches?
We build what is needed to boot the board and run the test suites.
Others do build testing really well (as noted in this thread), so
there's not a need for redundant efforts there. Incidentally, we are
often limited on things like kernel sizes on embedded boards, so it's
not prudent to try to run unnecessarily large kernels.
Dan
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 15:54 ` Dan Rue
@ 2017-10-10 16:05 ` Greg Kroah-Hartman
0 siblings, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-10 16:05 UTC (permalink / raw)
To: Tom Gall, LKML, torvalds, akpm, Guenter Roeck, Shuah Khan,
patches, Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 10:54:50AM -0500, Dan Rue wrote:
> On Tue, Oct 10, 2017 at 03:33:47PM +0000, Greg Kroah-Hartman wrote:
> > On Tue, Oct 10, 2017 at 10:23:00AM -0500, Dan Rue wrote:
> > > On Tue, Oct 10, 2017 at 07:11:55AM +0000, Greg Kroah-Hartman wrote:
> > > > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> > > > > On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > >> kernel: 4.9.54-rc1
> > > > > >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > > >> git branch: linux-4.9.y
> > > > > >> git commit: 1852eae92c460813692808234da35d142a405ab7
> > > > > >> git describe: v4.9.53
> > > > > >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> > > > >
> > > > > >>
> > > > > >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> > > > > >
> > > > > > How did your arm64 test build? There was a build regression in the -rc1
> > > > > > release, are you sure you actually ran the correct image?
> > > > >
> > > > > So the header in that report was wrong. That's a c/n/p error on my
> > > > > part. I was in a rush to get you data before I was going to be gone
> > > > > for the day on Sat and wanting to get what we had into your hands
> > > > > before the Sunday deadline.
> > > > >
> > > > > The test results was for the RC as of commit
> > > > > 0e59436504287cddb9663857ae69c100b55f5e85
> > > > >
> > > > > If you want to see the 'ugly' raw data it's all here :
> > > > > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> > > >
> > > > I still don't understand. That _build_ should have failed, how did it
> > > > succeed enough to actually run the tests at all?
> > >
> > > It looks like the build failure shown at
> > > http://arm-soc.lixom.net/buildlogs/stable-rc/v4.9.53-105-g0e59436/
> > > requires CONFIG_KASAN to be set, which we do not set. All the other
> > > configs built, including ours, which can be seen at
> > > http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linux-stable-rc-4.9/67/defconfig
> >
> > Thanks for the explaination.
> >
> > How come you don't enable KASAN? Any other options you all should be
> > enabling to get better test coverage that you are not?
> >
> > Are you doing a 'make allmodconfig' type build for these arches?
>
> We build what is needed to boot the board and run the test suites.
Nice start, but:
> Others do build testing really well (as noted in this thread), so
> there's not a need for redundant efforts there.
There is _always_ a need for redundant testing efforts. And how do you
know your platform testing is redundant?
Please add some basic 'build testing' if at all possible, it shouldn't
be much, you don't have to actually boot the images :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 15:33 ` Greg Kroah-Hartman
2017-10-10 15:54 ` Dan Rue
@ 2017-10-10 23:11 ` Mark Brown
1 sibling, 0 replies; 144+ messages in thread
From: Mark Brown @ 2017-10-10 23:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tom Gall, LKML, torvalds, akpm, Guenter Roeck, Shuah Khan,
patches, Ben Hutchings, linux- stable
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
On Tue, Oct 10, 2017 at 05:33:47PM +0200, Greg Kroah-Hartman wrote:
> How come you don't enable KASAN? Any other options you all should be
> enabling to get better test coverage that you are not?
KASAN probably wants to be built as a separate config and have some
subset of the tests run on it, there's a substantial overhead from it so
it'll cause issues when they get round to benchmarking and I'd not be
surprised if it ended up masking some timing issues even in the more
simple functional tests that are being run now.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 7:11 ` Greg Kroah-Hartman
2017-10-10 15:23 ` Dan Rue
@ 2017-10-10 15:23 ` Tom Gall
2017-10-10 15:33 ` Greg Kroah-Hartman
1 sibling, 1 reply; 144+ messages in thread
From: Tom Gall @ 2017-10-10 15:23 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: LKML, torvalds, akpm, Guenter Roeck, Shuah Khan, patches,
Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
>> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> >> kernel: 4.9.54-rc1
>> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> >> git branch: linux-4.9.y
>> >> git commit: 1852eae92c460813692808234da35d142a405ab7
>> >> git describe: v4.9.53
>> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
>>
>> >>
>> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
>> >
>> > How did your arm64 test build? There was a build regression in the -rc1
>> > release, are you sure you actually ran the correct image?
>>
>> So the header in that report was wrong. That's a c/n/p error on my
>> part. I was in a rush to get you data before I was going to be gone
>> for the day on Sat and wanting to get what we had into your hands
>> before the Sunday deadline.
>>
>> The test results was for the RC as of commit
>> 0e59436504287cddb9663857ae69c100b55f5e85
>>
>> If you want to see the 'ugly' raw data it's all here :
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
>
> I still don't understand. That _build_ should have failed, how did it
> succeed enough to actually run the tests at all?
Looks like it's because we don't build with CONFIG_KASAN.
In the case where the build fails, the system won't run tests since there's no
image to run. Likewise if we have a situation where the build fails
for some arches
but not all we'll only get partial test results for the builds that
succeeded and
likewise nothing for what failed.
The results reported were based on commit id
0e59436504287cddb9663857ae69c100b55f5e85
Unfortunately that commit id doesn't exist anymore since it was
replaced by the 4.9.54 release which was commit ID
f37eb7b586f1dd24a86c50278c65322fc6787722
(and yes the release test results == rc test results that were reported)
Things get a little confusing when one can't go back and compare
commit ids. Losing history kinda sucks.
I've thought about some other way to uniquely tie results to an rc
patch maybe working
off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/
But like in this instance if there isn't both the rc1 and rc2 for
posterity it wouldn't help.
Least for now we have commit ids, git describe and kernel version from
the Makefile.
Why wasn't there an rc2 patch file?
> thanks,
>
> greg k-h
--
Regards,
Tom
Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 15:23 ` Tom Gall
@ 2017-10-10 15:33 ` Greg Kroah-Hartman
2017-10-10 18:39 ` Guenter Roeck
0 siblings, 1 reply; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-10 15:33 UTC (permalink / raw)
To: Tom Gall
Cc: LKML, torvalds, akpm, Guenter Roeck, Shuah Khan, patches,
Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 10:23:43AM -0500, Tom Gall wrote:
> On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> >> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> >> kernel: 4.9.54-rc1
> >> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> >> git branch: linux-4.9.y
> >> >> git commit: 1852eae92c460813692808234da35d142a405ab7
> >> >> git describe: v4.9.53
> >> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> >>
> >> >>
> >> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> >> >
> >> > How did your arm64 test build? There was a build regression in the -rc1
> >> > release, are you sure you actually ran the correct image?
> >>
> >> So the header in that report was wrong. That's a c/n/p error on my
> >> part. I was in a rush to get you data before I was going to be gone
> >> for the day on Sat and wanting to get what we had into your hands
> >> before the Sunday deadline.
> >>
> >> The test results was for the RC as of commit
> >> 0e59436504287cddb9663857ae69c100b55f5e85
> >>
> >> If you want to see the 'ugly' raw data it's all here :
> >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> >
> > I still don't understand. That _build_ should have failed, how did it
> > succeed enough to actually run the tests at all?
>
> Looks like it's because we don't build with CONFIG_KASAN.
Ick, not good, why not? Surely you enable all of the options you can
for your hardware, right? And enabling stuff like this is good no
matter what...
> In the case where the build fails, the system won't run tests since there's no
> image to run. Likewise if we have a situation where the build fails
> for some arches
> but not all we'll only get partial test results for the builds that
> succeeded and
> likewise nothing for what failed.
Ok, good (odd line-wrapping, did I give you too many '\n'?)
> The results reported were based on commit id
> 0e59436504287cddb9663857ae69c100b55f5e85
>
> Unfortunately that commit id doesn't exist anymore since it was
> replaced by the 4.9.54 release which was commit ID
> f37eb7b586f1dd24a86c50278c65322fc6787722
>
> (and yes the release test results == rc test results that were reported)
>
> Things get a little confusing when one can't go back and compare
> commit ids. Losing history kinda sucks.
>
> I've thought about some other way to uniquely tie results to an rc
> patch maybe working
> off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/
>
> But like in this instance if there isn't both the rc1 and rc2 for
> posterity it wouldn't help.
> Least for now we have commit ids, git describe and kernel version from
> the Makefile.
>
> Why wasn't there an rc2 patch file?
There was, I announced it. But oh, look, I never pushed it out to
kernel.org, my fault. I guess no one actually tested it except me :)
Going off of the quilt tree might be good, that's what others do today
(hint...)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 15:33 ` Greg Kroah-Hartman
@ 2017-10-10 18:39 ` Guenter Roeck
2017-10-10 18:50 ` Greg Kroah-Hartman
2017-10-10 23:14 ` Mark Brown
0 siblings, 2 replies; 144+ messages in thread
From: Guenter Roeck @ 2017-10-10 18:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tom Gall, LKML, torvalds, akpm, Shuah Khan, patches,
Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 05:33:04PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Oct 10, 2017 at 10:23:43AM -0500, Tom Gall wrote:
> > On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> > >> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> > >> <gregkh@linuxfoundation.org> wrote:
> > >> >> kernel: 4.9.54-rc1
> > >> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > >> >> git branch: linux-4.9.y
> > >> >> git commit: 1852eae92c460813692808234da35d142a405ab7
> > >> >> git describe: v4.9.53
> > >> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> > >>
> > >> >>
> > >> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> > >> >
> > >> > How did your arm64 test build? There was a build regression in the -rc1
> > >> > release, are you sure you actually ran the correct image?
> > >>
> > >> So the header in that report was wrong. That's a c/n/p error on my
> > >> part. I was in a rush to get you data before I was going to be gone
> > >> for the day on Sat and wanting to get what we had into your hands
> > >> before the Sunday deadline.
> > >>
> > >> The test results was for the RC as of commit
> > >> 0e59436504287cddb9663857ae69c100b55f5e85
> > >>
> > >> If you want to see the 'ugly' raw data it's all here :
> > >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> > >
> > > I still don't understand. That _build_ should have failed, how did it
> > > succeed enough to actually run the tests at all?
> >
> > Looks like it's because we don't build with CONFIG_KASAN.
>
> Ick, not good, why not? Surely you enable all of the options you can
> for your hardware, right? And enabling stuff like this is good no
> matter what...
>
FWIW, I don't enable CONFIG_KASAN or my qemu test runs either, simply because
enabling it makes images all but impossible to run in qemu. Whatever KASAN
does, it seems to completely defeat qemu.
> > In the case where the build fails, the system won't run tests since there's no
> > image to run. Likewise if we have a situation where the build fails
> > for some arches
> > but not all we'll only get partial test results for the builds that
> > succeeded and
> > likewise nothing for what failed.
>
> Ok, good (odd line-wrapping, did I give you too many '\n'?)
>
> > The results reported were based on commit id
> > 0e59436504287cddb9663857ae69c100b55f5e85
> >
> > Unfortunately that commit id doesn't exist anymore since it was
> > replaced by the 4.9.54 release which was commit ID
> > f37eb7b586f1dd24a86c50278c65322fc6787722
> >
> > (and yes the release test results == rc test results that were reported)
> >
> > Things get a little confusing when one can't go back and compare
> > commit ids. Losing history kinda sucks.
> >
> > I've thought about some other way to uniquely tie results to an rc
> > patch maybe working
> > off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/
> >
> > But like in this instance if there isn't both the rc1 and rc2 for
> > posterity it wouldn't help.
> > Least for now we have commit ids, git describe and kernel version from
> > the Makefile.
> >
> > Why wasn't there an rc2 patch file?
>
> There was, I announced it. But oh, look, I never pushed it out to
> kernel.org, my fault. I guess no one actually tested it except me :)
>
Hmm, I am pretty sure that my builders picked it up from the git repo
since the previously failing builds started to pass.
Guenter
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 18:39 ` Guenter Roeck
@ 2017-10-10 18:50 ` Greg Kroah-Hartman
2017-10-10 23:14 ` Mark Brown
1 sibling, 0 replies; 144+ messages in thread
From: Greg Kroah-Hartman @ 2017-10-10 18:50 UTC (permalink / raw)
To: Guenter Roeck
Cc: Tom Gall, LKML, torvalds, akpm, Shuah Khan, patches,
Ben Hutchings, linux- stable
On Tue, Oct 10, 2017 at 11:39:09AM -0700, Guenter Roeck wrote:
> On Tue, Oct 10, 2017 at 05:33:04PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Oct 10, 2017 at 10:23:43AM -0500, Tom Gall wrote:
> > > On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> > > >> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> > > >> <gregkh@linuxfoundation.org> wrote:
> > > >> >> kernel: 4.9.54-rc1
> > > >> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > >> >> git branch: linux-4.9.y
> > > >> >> git commit: 1852eae92c460813692808234da35d142a405ab7
> > > >> >> git describe: v4.9.53
> > > >> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> > > >>
> > > >> >>
> > > >> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> > > >> >
> > > >> > How did your arm64 test build? There was a build regression in the -rc1
> > > >> > release, are you sure you actually ran the correct image?
> > > >>
> > > >> So the header in that report was wrong. That's a c/n/p error on my
> > > >> part. I was in a rush to get you data before I was going to be gone
> > > >> for the day on Sat and wanting to get what we had into your hands
> > > >> before the Sunday deadline.
> > > >>
> > > >> The test results was for the RC as of commit
> > > >> 0e59436504287cddb9663857ae69c100b55f5e85
> > > >>
> > > >> If you want to see the 'ugly' raw data it's all here :
> > > >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> > > >
> > > > I still don't understand. That _build_ should have failed, how did it
> > > > succeed enough to actually run the tests at all?
> > >
> > > Looks like it's because we don't build with CONFIG_KASAN.
> >
> > Ick, not good, why not? Surely you enable all of the options you can
> > for your hardware, right? And enabling stuff like this is good no
> > matter what...
> >
> FWIW, I don't enable CONFIG_KASAN or my qemu test runs either, simply because
> enabling it makes images all but impossible to run in qemu. Whatever KASAN
> does, it seems to completely defeat qemu.
>
> > > In the case where the build fails, the system won't run tests since there's no
> > > image to run. Likewise if we have a situation where the build fails
> > > for some arches
> > > but not all we'll only get partial test results for the builds that
> > > succeeded and
> > > likewise nothing for what failed.
> >
> > Ok, good (odd line-wrapping, did I give you too many '\n'?)
> >
> > > The results reported were based on commit id
> > > 0e59436504287cddb9663857ae69c100b55f5e85
> > >
> > > Unfortunately that commit id doesn't exist anymore since it was
> > > replaced by the 4.9.54 release which was commit ID
> > > f37eb7b586f1dd24a86c50278c65322fc6787722
> > >
> > > (and yes the release test results == rc test results that were reported)
> > >
> > > Things get a little confusing when one can't go back and compare
> > > commit ids. Losing history kinda sucks.
> > >
> > > I've thought about some other way to uniquely tie results to an rc
> > > patch maybe working
> > > off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/
> > >
> > > But like in this instance if there isn't both the rc1 and rc2 for
> > > posterity it wouldn't help.
> > > Least for now we have commit ids, git describe and kernel version from
> > > the Makefile.
> > >
> > > Why wasn't there an rc2 patch file?
> >
> > There was, I announced it. But oh, look, I never pushed it out to
> > kernel.org, my fault. I guess no one actually tested it except me :)
> >
> Hmm, I am pretty sure that my builders picked it up from the git repo
> since the previously failing builds started to pass.
Yes, the git trees pushed out properly, but the -rc2 patch has to get
sent up manually with a different script.
It's all patched together here to barely work...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 4.9 000/104] 4.9.54-stable review
2017-10-10 18:39 ` Guenter Roeck
2017-10-10 18:50 ` Greg Kroah-Hartman
@ 2017-10-10 23:14 ` Mark Brown
1 sibling, 0 replies; 144+ messages in thread
From: Mark Brown @ 2017-10-10 23:14 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, Tom Gall, LKML, torvalds, akpm, Shuah Khan,
patches, Ben Hutchings, linux- stable
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Tue, Oct 10, 2017 at 11:39:09AM -0700, Guenter Roeck wrote:
> On Tue, Oct 10, 2017 at 05:33:04PM +0200, Greg Kroah-Hartman wrote:
> > Ick, not good, why not? Surely you enable all of the options you can
> > for your hardware, right? And enabling stuff like this is good no
> > matter what...
What I said about KASAN in the other mail applies more generally - some
of the debug options are very low overhead but that's not always the
case, especially when running on lower end hardware.
> FWIW, I don't enable CONFIG_KASAN or my qemu test runs either, simply because
> enabling it makes images all but impossible to run in qemu. Whatever KASAN
> does, it seems to completely defeat qemu.
It's much slower and uses a lot more memory, I'd guess either of those
could be a big issue.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread