* [PATCH 4.14 01/33] scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 02/33] ARM: dts: Add pinmuxing for i2c2 and i2c3 for LogicPD SOM-LV Greg Kroah-Hartman
` (34 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hannes Reinecke, Martin K. Petersen
From: Hannes Reinecke <hare@suse.de>
commit 023358b136d490ca91735ac6490db3741af5a8bd upstream.
Gcc-9 complains for a memset across pointer boundaries, which happens as
the code tries to allocate a flexible array on the stack. Turns out we
cannot do this without relying on gcc-isms, so with this patch we'll embed
the fc_rport_priv structure into fcoe_rport, can use the normal
'container_of' outcast, and will only have to do a memset over one
structure.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/fcoe/fcoe_ctlr.c | 51 ++++++++++++++++--------------------------
drivers/scsi/libfc/fc_rport.c | 5 +++-
include/scsi/libfcoe.h | 1
3 files changed, 25 insertions(+), 32 deletions(-)
--- a/drivers/scsi/fcoe/fcoe_ctlr.c
+++ b/drivers/scsi/fcoe/fcoe_ctlr.c
@@ -2017,7 +2017,7 @@ EXPORT_SYMBOL_GPL(fcoe_wwn_from_mac);
*/
static inline struct fcoe_rport *fcoe_ctlr_rport(struct fc_rport_priv *rdata)
{
- return (struct fcoe_rport *)(rdata + 1);
+ return container_of(rdata, struct fcoe_rport, rdata);
}
/**
@@ -2283,7 +2283,7 @@ static void fcoe_ctlr_vn_start(struct fc
*/
static int fcoe_ctlr_vn_parse(struct fcoe_ctlr *fip,
struct sk_buff *skb,
- struct fc_rport_priv *rdata)
+ struct fcoe_rport *frport)
{
struct fip_header *fiph;
struct fip_desc *desc = NULL;
@@ -2291,16 +2291,12 @@ static int fcoe_ctlr_vn_parse(struct fco
struct fip_wwn_desc *wwn = NULL;
struct fip_vn_desc *vn = NULL;
struct fip_size_desc *size = NULL;
- struct fcoe_rport *frport;
size_t rlen;
size_t dlen;
u32 desc_mask = 0;
u32 dtype;
u8 sub;
- memset(rdata, 0, sizeof(*rdata) + sizeof(*frport));
- frport = fcoe_ctlr_rport(rdata);
-
fiph = (struct fip_header *)skb->data;
frport->flags = ntohs(fiph->fip_flags);
@@ -2363,15 +2359,17 @@ static int fcoe_ctlr_vn_parse(struct fco
if (dlen != sizeof(struct fip_wwn_desc))
goto len_err;
wwn = (struct fip_wwn_desc *)desc;
- rdata->ids.node_name = get_unaligned_be64(&wwn->fd_wwn);
+ frport->rdata.ids.node_name =
+ get_unaligned_be64(&wwn->fd_wwn);
break;
case FIP_DT_VN_ID:
if (dlen != sizeof(struct fip_vn_desc))
goto len_err;
vn = (struct fip_vn_desc *)desc;
memcpy(frport->vn_mac, vn->fd_mac, ETH_ALEN);
- rdata->ids.port_id = ntoh24(vn->fd_fc_id);
- rdata->ids.port_name = get_unaligned_be64(&vn->fd_wwpn);
+ frport->rdata.ids.port_id = ntoh24(vn->fd_fc_id);
+ frport->rdata.ids.port_name =
+ get_unaligned_be64(&vn->fd_wwpn);
break;
case FIP_DT_FC4F:
if (dlen != sizeof(struct fip_fc4_feat))
@@ -2752,10 +2750,7 @@ static int fcoe_ctlr_vn_recv(struct fcoe
{
struct fip_header *fiph;
enum fip_vn2vn_subcode sub;
- struct {
- struct fc_rport_priv rdata;
- struct fcoe_rport frport;
- } buf;
+ struct fcoe_rport frport = { };
int rc, vlan_id = 0;
fiph = (struct fip_header *)skb->data;
@@ -2771,7 +2766,7 @@ static int fcoe_ctlr_vn_recv(struct fcoe
goto drop;
}
- rc = fcoe_ctlr_vn_parse(fip, skb, &buf.rdata);
+ rc = fcoe_ctlr_vn_parse(fip, skb, &frport);
if (rc) {
LIBFCOE_FIP_DBG(fip, "vn_recv vn_parse error %d\n", rc);
goto drop;
@@ -2780,19 +2775,19 @@ static int fcoe_ctlr_vn_recv(struct fcoe
mutex_lock(&fip->ctlr_mutex);
switch (sub) {
case FIP_SC_VN_PROBE_REQ:
- fcoe_ctlr_vn_probe_req(fip, &buf.rdata);
+ fcoe_ctlr_vn_probe_req(fip, &frport.rdata);
break;
case FIP_SC_VN_PROBE_REP:
- fcoe_ctlr_vn_probe_reply(fip, &buf.rdata);
+ fcoe_ctlr_vn_probe_reply(fip, &frport.rdata);
break;
case FIP_SC_VN_CLAIM_NOTIFY:
- fcoe_ctlr_vn_claim_notify(fip, &buf.rdata);
+ fcoe_ctlr_vn_claim_notify(fip, &frport.rdata);
break;
case FIP_SC_VN_CLAIM_REP:
- fcoe_ctlr_vn_claim_resp(fip, &buf.rdata);
+ fcoe_ctlr_vn_claim_resp(fip, &frport.rdata);
break;
case FIP_SC_VN_BEACON:
- fcoe_ctlr_vn_beacon(fip, &buf.rdata);
+ fcoe_ctlr_vn_beacon(fip, &frport.rdata);
break;
default:
LIBFCOE_FIP_DBG(fip, "vn_recv unknown subcode %d\n", sub);
@@ -2816,22 +2811,18 @@ drop:
*/
static int fcoe_ctlr_vlan_parse(struct fcoe_ctlr *fip,
struct sk_buff *skb,
- struct fc_rport_priv *rdata)
+ struct fcoe_rport *frport)
{
struct fip_header *fiph;
struct fip_desc *desc = NULL;
struct fip_mac_desc *macd = NULL;
struct fip_wwn_desc *wwn = NULL;
- struct fcoe_rport *frport;
size_t rlen;
size_t dlen;
u32 desc_mask = 0;
u32 dtype;
u8 sub;
- memset(rdata, 0, sizeof(*rdata) + sizeof(*frport));
- frport = fcoe_ctlr_rport(rdata);
-
fiph = (struct fip_header *)skb->data;
frport->flags = ntohs(fiph->fip_flags);
@@ -2885,7 +2876,8 @@ static int fcoe_ctlr_vlan_parse(struct f
if (dlen != sizeof(struct fip_wwn_desc))
goto len_err;
wwn = (struct fip_wwn_desc *)desc;
- rdata->ids.node_name = get_unaligned_be64(&wwn->fd_wwn);
+ frport->rdata.ids.node_name =
+ get_unaligned_be64(&wwn->fd_wwn);
break;
default:
LIBFCOE_FIP_DBG(fip, "unexpected descriptor type %x "
@@ -2996,22 +2988,19 @@ static int fcoe_ctlr_vlan_recv(struct fc
{
struct fip_header *fiph;
enum fip_vlan_subcode sub;
- struct {
- struct fc_rport_priv rdata;
- struct fcoe_rport frport;
- } buf;
+ struct fcoe_rport frport = { };
int rc;
fiph = (struct fip_header *)skb->data;
sub = fiph->fip_subcode;
- rc = fcoe_ctlr_vlan_parse(fip, skb, &buf.rdata);
+ rc = fcoe_ctlr_vlan_parse(fip, skb, &frport);
if (rc) {
LIBFCOE_FIP_DBG(fip, "vlan_recv vlan_parse error %d\n", rc);
goto drop;
}
mutex_lock(&fip->ctlr_mutex);
if (sub == FIP_SC_VL_REQ)
- fcoe_ctlr_vlan_disc_reply(fip, &buf.rdata);
+ fcoe_ctlr_vlan_disc_reply(fip, &frport.rdata);
mutex_unlock(&fip->ctlr_mutex);
drop:
--- a/drivers/scsi/libfc/fc_rport.c
+++ b/drivers/scsi/libfc/fc_rport.c
@@ -142,12 +142,15 @@ EXPORT_SYMBOL(fc_rport_lookup);
struct fc_rport_priv *fc_rport_create(struct fc_lport *lport, u32 port_id)
{
struct fc_rport_priv *rdata;
+ size_t rport_priv_size = sizeof(*rdata);
rdata = fc_rport_lookup(lport, port_id);
if (rdata)
return rdata;
- rdata = kzalloc(sizeof(*rdata) + lport->rport_priv_size, GFP_KERNEL);
+ if (lport->rport_priv_size > 0)
+ rport_priv_size = lport->rport_priv_size;
+ rdata = kzalloc(rport_priv_size, GFP_KERNEL);
if (!rdata)
return NULL;
--- a/include/scsi/libfcoe.h
+++ b/include/scsi/libfcoe.h
@@ -241,6 +241,7 @@ struct fcoe_fcf {
* @vn_mac: VN_Node assigned MAC address for data
*/
struct fcoe_rport {
+ struct fc_rport_priv rdata;
unsigned long time;
u16 fcoe_len;
u16 flags;
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 02/33] ARM: dts: Add pinmuxing for i2c2 and i2c3 for LogicPD SOM-LV
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 01/33] scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 03/33] ARM: dts: Add pinmuxing for i2c2 and i2c3 for LogicPD torpedo Greg Kroah-Hartman
` (33 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adam Ford, Tony Lindgren, Sasha Levin
[ Upstream commit 5fe3c0fa0d54877c65e7c9b4442aeeb25cdf469a ]
Since I2C1 and I2C4 have explicit pinmuxing set, let's be on the
safe side and set the pin muxing for I2C2 and I2C3.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/logicpd-som-lv.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/logicpd-som-lv.dtsi b/arch/arm/boot/dts/logicpd-som-lv.dtsi
index a7883676f675c..b144a6a5d3523 100644
--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -115,10 +115,14 @@
};
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
clock-frequency = <400000>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
clock-frequency = <400000>;
};
@@ -241,6 +245,18 @@
OMAP3_WKUP_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4) /* sys_boot1.gpio_3 */
>;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21be, PIN_INPUT | MUX_MODE0) /* i2c2_scl */
+ OMAP3_CORE1_IOPAD(0x21c0, PIN_INPUT | MUX_MODE0) /* i2c2_sda */
+ >;
+ };
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0) /* i2c3_scl */
+ OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0) /* i2c3_sda */
+ >;
+ };
};
&omap3_pmx_core2 {
--
2.20.1
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH 4.14 03/33] ARM: dts: Add pinmuxing for i2c2 and i2c3 for LogicPD torpedo
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 01/33] scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 02/33] ARM: dts: Add pinmuxing for i2c2 and i2c3 for LogicPD SOM-LV Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 04/33] tcp: be more careful in tcp_fragment() Greg Kroah-Hartman
` (32 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adam Ford, Tony Lindgren, Sasha Levin
[ Upstream commit a135a392acbec7ecda782981788e8c03767a1571 ]
Since I2C1 and I2C4 have explicit pinmuxing set, let's be on the
safe side and set the pin muxing for I2C2 and I2C3.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index cf22b35f0a289..fe4cbdc72359e 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -121,10 +121,14 @@
};
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
clock-frequency = <400000>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
clock-frequency = <400000>;
at24@50 {
compatible = "atmel,24c64";
@@ -219,6 +223,18 @@
OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
>;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21be, PIN_INPUT | MUX_MODE0) /* i2c2_scl */
+ OMAP3_CORE1_IOPAD(0x21c0, PIN_INPUT | MUX_MODE0) /* i2c2_sda */
+ >;
+ };
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0) /* i2c3_scl */
+ OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0) /* i2c3_sda */
+ >;
+ };
};
&uart2 {
--
2.20.1
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH 4.14 04/33] tcp: be more careful in tcp_fragment()
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 03/33] ARM: dts: Add pinmuxing for i2c2 and i2c3 for LogicPD torpedo Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-20 16:45 ` Matthieu Baerts
2019-08-08 19:05 ` [PATCH 4.14 05/33] arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} Greg Kroah-Hartman
` (31 subsequent siblings)
35 siblings, 1 reply; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, Andrew Prout,
Jonathan Lemon, Michal Kubecek, Neal Cardwell, Yuchung Cheng,
Christoph Paasch, Jonathan Looney, David S. Miller,
Matthieu Baerts, Sasha Levin
commit b617158dc096709d8600c53b6052144d12b89fab upstream.
Some applications set tiny SO_SNDBUF values and expect
TCP to just work. Recent patches to address CVE-2019-11478
broke them in case of losses, since retransmits might
be prevented.
We should allow these flows to make progress.
This patch allows the first and last skb in retransmit queue
to be split even if memory limits are hit.
It also adds the some room due to the fact that tcp_sendmsg()
and tcp_sendpage() might overshoot sk_wmem_queued by about one full
TSO skb (64KB size). Note this allowance was already present
in stable backports for kernels < 4.15
Note for < 4.15 backports :
tcp_rtx_queue_tail() will probably look like :
static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
{
struct sk_buff *skb = tcp_send_head(sk);
return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
}
Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrew Prout <aprout@ll.mit.edu>
Tested-by: Andrew Prout <aprout@ll.mit.edu>
Tested-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Tested-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Christoph Paasch <cpaasch@apple.com>
Cc: Jonathan Looney <jtl@netflix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/tcp.h | 17 +++++++++++++++++
net/ipv4/tcp_output.c | 11 ++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 0b477a1e11770..7994e569644e0 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1688,6 +1688,23 @@ static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unli
tcp_sk(sk)->highest_sack = NULL;
}
+static inline struct sk_buff *tcp_rtx_queue_head(const struct sock *sk)
+{
+ struct sk_buff *skb = tcp_write_queue_head(sk);
+
+ if (skb == tcp_send_head(sk))
+ skb = NULL;
+
+ return skb;
+}
+
+static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
+{
+ struct sk_buff *skb = tcp_send_head(sk);
+
+ return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
+}
+
static inline void __tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb)
{
__skb_queue_tail(&sk->sk_write_queue, skb);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a5960b9b6741c..a99086bf26eaf 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1264,6 +1264,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *buff;
int nsize, old_factor;
+ long limit;
int nlen;
u8 flags;
@@ -1274,7 +1275,15 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
if (nsize < 0)
nsize = 0;
- if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf + 0x20000)) {
+ /* tcp_sendmsg() can overshoot sk_wmem_queued by one full size skb.
+ * We need some allowance to not penalize applications setting small
+ * SO_SNDBUF values.
+ * Also allow first and last skb in retransmit queue to be split.
+ */
+ limit = sk->sk_sndbuf + 2 * SKB_TRUESIZE(GSO_MAX_SIZE);
+ if (unlikely((sk->sk_wmem_queued >> 1) > limit &&
+ skb != tcp_rtx_queue_head(sk) &&
+ skb != tcp_rtx_queue_tail(sk))) {
NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
return -ENOMEM;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 52+ messages in thread* Re: [PATCH 4.14 04/33] tcp: be more careful in tcp_fragment()
2019-08-08 19:05 ` [PATCH 4.14 04/33] tcp: be more careful in tcp_fragment() Greg Kroah-Hartman
@ 2019-08-20 16:45 ` Matthieu Baerts
2019-08-23 12:50 ` [PATCH] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue Tim Froidcoeur
2019-08-24 6:03 ` [PATCH 4.14] " Tim Froidcoeur
0 siblings, 2 replies; 52+ messages in thread
From: Matthieu Baerts @ 2019-08-20 16:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Greg Kroah-Hartman, linux-kernel, stable, Andrew Prout,
Jonathan Lemon, Michal Kubecek, Neal Cardwell, Yuchung Cheng,
Christoph Paasch, Jonathan Looney, David S. Miller, Sasha Levin,
Tim Froidcoeur
Hi Eric,
On 08/08/2019 21:05, Greg Kroah-Hartman wrote:
> commit b617158dc096709d8600c53b6052144d12b89fab upstream.
>
> Some applications set tiny SO_SNDBUF values and expect
> TCP to just work. Recent patches to address CVE-2019-11478
> broke them in case of losses, since retransmits might
> be prevented.
>
> We should allow these flows to make progress.
>
> This patch allows the first and last skb in retransmit queue
> to be split even if memory limits are hit.
>
> It also adds the some room due to the fact that tcp_sendmsg()
> and tcp_sendpage() might overshoot sk_wmem_queued by about one full
> TSO skb (64KB size). Note this allowance was already present
> in stable backports for kernels < 4.15
>
> Note for < 4.15 backports :
> tcp_rtx_queue_tail() will probably look like :
>
> static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
> {
> struct sk_buff *skb = tcp_send_head(sk);
>
> return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
> }
>
> Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrew Prout <aprout@ll.mit.edu>
> Tested-by: Andrew Prout <aprout@ll.mit.edu>
> Tested-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> Tested-by: Michal Kubecek <mkubecek@suse.cz>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
> Acked-by: Christoph Paasch <cpaasch@apple.com>
> Cc: Jonathan Looney <jtl@netflix.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> include/net/tcp.h | 17 +++++++++++++++++
> net/ipv4/tcp_output.c | 11 ++++++++++-
> 2 files changed, 27 insertions(+), 1 deletion(-)
I am sorry to bother you again with the recent modifications in
tcp_fragment() but it seems we have a new kernel BUG with this patch in
v4.14.
Here is the call trace.
[26665.934461] ------------[ cut here ]------------
[26665.936152] kernel BUG at ./include/linux/skbuff.h:1406!
[26665.937941] invalid opcode: 0000 [#1] SMP PTI
[26665.977252] Call Trace:
[26665.978267] <IRQ>
[26665.979163] tcp_fragment+0x9c/0x2cf
[26665.980562] tcp_write_xmit+0x68f/0x988
[26665.982031] __tcp_push_pending_frames+0x3b/0xa0
[26665.983684] tcp_data_snd_check+0x2a/0xc8
[26665.985196] tcp_rcv_established+0x2a8/0x30d
[26665.986736] tcp_v4_do_rcv+0xb2/0x158
[26665.988140] tcp_v4_rcv+0x692/0x956
[26665.989533] ip_local_deliver_finish+0xeb/0x169
[26665.991250] __netif_receive_skb_core+0x51c/0x582
[26665.993028] ? inet_gro_receive+0x239/0x247
[26665.994581] netif_receive_skb_internal+0xab/0xc6
[26665.996340] napi_gro_receive+0x8a/0xc0
[26665.997790] receive_buf+0x9a1/0x9cd
[26665.999232] ? load_balance+0x17a/0x7b7
[26666.000711] ? vring_unmap_one+0x18/0x61
[26666.002196] ? detach_buf+0x60/0xfa
[26666.003526] virtnet_poll+0x128/0x1e1
[26666.004860] net_rx_action+0x12a/0x2b1
[26666.006309] __do_softirq+0x11c/0x26b
[26666.007734] ? handle_irq_event+0x44/0x56
[26666.009275] irq_exit+0x61/0xa0
[26666.010511] do_IRQ+0x9d/0xbb
[26666.011685] common_interrupt+0x85/0x85
We are doing the tests with the MPTCP stack[1], the error might come
from there but the call trace is free of MPTCP functions. We are still
working on having a reproducible setup with MPTCP before doing the same
without MPTCP but please see below the analysis we did so far with some
questions.
[1] https://github.com/multipath-tcp/mptcp/tree/mptcp_v0.94
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 0b477a1e11770..7994e569644e0 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1688,6 +1688,23 @@ static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unli
> tcp_sk(sk)->highest_sack = NULL;
> }
>
> +static inline struct sk_buff *tcp_rtx_queue_head(const struct sock *sk)
> +{
> + struct sk_buff *skb = tcp_write_queue_head(sk);
> +
> + if (skb == tcp_send_head(sk))
> + skb = NULL;
> +
> + return skb;
> +}
> +
> +static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
> +{
> + struct sk_buff *skb = tcp_send_head(sk);
> +
> + return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
> +}
> +
> static inline void __tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb)
> {
> __skb_queue_tail(&sk->sk_write_queue, skb);
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index a5960b9b6741c..a99086bf26eaf 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1264,6 +1264,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
> struct tcp_sock *tp = tcp_sk(sk);
> struct sk_buff *buff;
> int nsize, old_factor;
> + long limit;
> int nlen;
> u8 flags;
>
> @@ -1274,7 +1275,15 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
> if (nsize < 0)
> nsize = 0;
>
> - if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf + 0x20000)) {
> + /* tcp_sendmsg() can overshoot sk_wmem_queued by one full size skb.
> + * We need some allowance to not penalize applications setting small
> + * SO_SNDBUF values.
> + * Also allow first and last skb in retransmit queue to be split.
> + */
> + limit = sk->sk_sndbuf + 2 * SKB_TRUESIZE(GSO_MAX_SIZE);
> + if (unlikely((sk->sk_wmem_queued >> 1) > limit &&
> + skb != tcp_rtx_queue_head(sk) &&
If the skb returned by tcp_rtx_queue_head() is null -- because skb ==
tcp_send_head(sk), please see above -- should we not do something else
than going to the next condition?
> + skb != tcp_rtx_queue_tail(sk))) {
It seems that behind, tcp_write_queue_prev() can be called -- please see
above -- which will directly called skb_queue_prev() which does this:
/* This BUG_ON may seem severe, but if we just return then we
* are going to dereference garbage.
*/
BUG_ON(skb_queue_is_first(list, skb));
return skb->prev;
Should we do the same check before to avoid the BUG_ON()?
Could it be normal to hit this BUG_ON() with regular TCP or is it due to
other changes in MPTCP stack? We hope not having bothered you for
something not in the upstream kernel (yet) :)
Cheers,
Matt
> NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
> return -ENOMEM;
> }
>
--
Matthieu Baerts | R&D Engineer
matthieu.baerts@tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-20 16:45 ` Matthieu Baerts
@ 2019-08-23 12:50 ` Tim Froidcoeur
2019-08-23 16:56 ` Christoph Paasch
2019-08-23 21:46 ` David Miller
2019-08-24 6:03 ` [PATCH 4.14] " Tim Froidcoeur
1 sibling, 2 replies; 52+ messages in thread
From: Tim Froidcoeur @ 2019-08-23 12:50 UTC (permalink / raw)
To: matthieu.baerts
Cc: aprout, cpaasch, davem, edumazet, gregkh, jonathan.lemon, jtl,
linux-kernel, mkubecek, ncardwell, sashal, stable,
tim.froidcoeur, ycheng
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
triggers following stack trace:
[25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
[25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
[25244.888167] Call Trace:
[25244.889182] <IRQ>
[25244.890001] tcp_fragment+0x9c/0x2cf
[25244.891295] tcp_write_xmit+0x68f/0x988
[25244.892732] __tcp_push_pending_frames+0x3b/0xa0
[25244.894347] tcp_data_snd_check+0x2a/0xc8
[25244.895775] tcp_rcv_established+0x2a8/0x30d
[25244.897282] tcp_v4_do_rcv+0xb2/0x158
[25244.898666] tcp_v4_rcv+0x692/0x956
[25244.899959] ip_local_deliver_finish+0xeb/0x169
[25244.901547] __netif_receive_skb_core+0x51c/0x582
[25244.903193] ? inet_gro_receive+0x239/0x247
[25244.904756] netif_receive_skb_internal+0xab/0xc6
[25244.906395] napi_gro_receive+0x8a/0xc0
[25244.907760] receive_buf+0x9a1/0x9cd
[25244.909160] ? load_balance+0x17a/0x7b7
[25244.910536] ? vring_unmap_one+0x18/0x61
[25244.911932] ? detach_buf+0x60/0xfa
[25244.913234] virtnet_poll+0x128/0x1e1
[25244.914607] net_rx_action+0x12a/0x2b1
[25244.915953] __do_softirq+0x11c/0x26b
[25244.917269] ? handle_irq_event+0x44/0x56
[25244.918695] irq_exit+0x61/0xa0
[25244.919947] do_IRQ+0x9d/0xbb
[25244.921065] common_interrupt+0x85/0x85
[25244.922479] </IRQ>
tcp_rtx_queue_tail() (called by tcp_fragment()) can call
tcp_write_queue_prev() on the first packet in the queue, which will trigger
the BUG in tcp_write_queue_prev(), because there is no previous packet.
This happens when the retransmit queue is empty, for example in case of a
zero window.
Patch is needed for 4.4, 4.9 and 4.14 stable branches.
Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
include/net/tcp.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 9de2c8cdcc51..1e70ca75c8bf 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1705,6 +1705,10 @@ static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
{
struct sk_buff *skb = tcp_send_head(sk);
+ /* empty retransmit queue, for example due to zero window */
+ if (skb == tcp_write_queue_head(sk))
+ return NULL;
+
return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
}
--
2.23.0
--
Disclaimer: https://www.tessares.net/mail-disclaimer/
<https://www.tessares.net/mail-disclaimer/>
^ permalink raw reply related [flat|nested] 52+ messages in thread* Re: [PATCH] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-23 12:50 ` [PATCH] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue Tim Froidcoeur
@ 2019-08-23 16:56 ` Christoph Paasch
2019-08-23 21:46 ` David Miller
1 sibling, 0 replies; 52+ messages in thread
From: Christoph Paasch @ 2019-08-23 16:56 UTC (permalink / raw)
To: Tim Froidcoeur
Cc: matthieu.baerts, aprout, davem, edumazet, gregkh, jonathan.lemon,
jtl, linux-kernel, mkubecek, ncardwell, sashal, stable, ycheng
On 23/08/19 - 14:50:54, Tim Froidcoeur wrote:
> Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> triggers following stack trace:
>
> [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
> [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
> [25244.888167] Call Trace:
> [25244.889182] <IRQ>
> [25244.890001] tcp_fragment+0x9c/0x2cf
> [25244.891295] tcp_write_xmit+0x68f/0x988
> [25244.892732] __tcp_push_pending_frames+0x3b/0xa0
> [25244.894347] tcp_data_snd_check+0x2a/0xc8
> [25244.895775] tcp_rcv_established+0x2a8/0x30d
> [25244.897282] tcp_v4_do_rcv+0xb2/0x158
> [25244.898666] tcp_v4_rcv+0x692/0x956
> [25244.899959] ip_local_deliver_finish+0xeb/0x169
> [25244.901547] __netif_receive_skb_core+0x51c/0x582
> [25244.903193] ? inet_gro_receive+0x239/0x247
> [25244.904756] netif_receive_skb_internal+0xab/0xc6
> [25244.906395] napi_gro_receive+0x8a/0xc0
> [25244.907760] receive_buf+0x9a1/0x9cd
> [25244.909160] ? load_balance+0x17a/0x7b7
> [25244.910536] ? vring_unmap_one+0x18/0x61
> [25244.911932] ? detach_buf+0x60/0xfa
> [25244.913234] virtnet_poll+0x128/0x1e1
> [25244.914607] net_rx_action+0x12a/0x2b1
> [25244.915953] __do_softirq+0x11c/0x26b
> [25244.917269] ? handle_irq_event+0x44/0x56
> [25244.918695] irq_exit+0x61/0xa0
> [25244.919947] do_IRQ+0x9d/0xbb
> [25244.921065] common_interrupt+0x85/0x85
> [25244.922479] </IRQ>
>
> tcp_rtx_queue_tail() (called by tcp_fragment()) can call
> tcp_write_queue_prev() on the first packet in the queue, which will trigger
> the BUG in tcp_write_queue_prev(), because there is no previous packet.
>
> This happens when the retransmit queue is empty, for example in case of a
> zero window.
>
> Patch is needed for 4.4, 4.9 and 4.14 stable branches.
>
> Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> ---
> include/net/tcp.h | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Christoph Paasch <cpaasch@apple.com>
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-23 12:50 ` [PATCH] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue Tim Froidcoeur
2019-08-23 16:56 ` Christoph Paasch
@ 2019-08-23 21:46 ` David Miller
1 sibling, 0 replies; 52+ messages in thread
From: David Miller @ 2019-08-23 21:46 UTC (permalink / raw)
To: tim.froidcoeur
Cc: matthieu.baerts, aprout, cpaasch, edumazet, gregkh,
jonathan.lemon, jtl, linux-kernel, mkubecek, ncardwell, sashal,
stable, ycheng
All networking patches must be sent CC:'d to netdev@vger.kernel.org
Thank you.
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-20 16:45 ` Matthieu Baerts
2019-08-23 12:50 ` [PATCH] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue Tim Froidcoeur
@ 2019-08-24 6:03 ` Tim Froidcoeur
2019-08-24 22:05 ` Jonathan Lemon
2019-08-31 12:20 ` Sasha Levin
1 sibling, 2 replies; 52+ messages in thread
From: Tim Froidcoeur @ 2019-08-24 6:03 UTC (permalink / raw)
To: matthieu.baerts
Cc: aprout, cpaasch, davem, edumazet, gregkh, jonathan.lemon, jtl,
linux-kernel, mkubecek, ncardwell, sashal, stable,
tim.froidcoeur, ycheng, netdev
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
triggers following stack trace:
[25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
[25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
[25244.888167] Call Trace:
[25244.889182] <IRQ>
[25244.890001] tcp_fragment+0x9c/0x2cf
[25244.891295] tcp_write_xmit+0x68f/0x988
[25244.892732] __tcp_push_pending_frames+0x3b/0xa0
[25244.894347] tcp_data_snd_check+0x2a/0xc8
[25244.895775] tcp_rcv_established+0x2a8/0x30d
[25244.897282] tcp_v4_do_rcv+0xb2/0x158
[25244.898666] tcp_v4_rcv+0x692/0x956
[25244.899959] ip_local_deliver_finish+0xeb/0x169
[25244.901547] __netif_receive_skb_core+0x51c/0x582
[25244.903193] ? inet_gro_receive+0x239/0x247
[25244.904756] netif_receive_skb_internal+0xab/0xc6
[25244.906395] napi_gro_receive+0x8a/0xc0
[25244.907760] receive_buf+0x9a1/0x9cd
[25244.909160] ? load_balance+0x17a/0x7b7
[25244.910536] ? vring_unmap_one+0x18/0x61
[25244.911932] ? detach_buf+0x60/0xfa
[25244.913234] virtnet_poll+0x128/0x1e1
[25244.914607] net_rx_action+0x12a/0x2b1
[25244.915953] __do_softirq+0x11c/0x26b
[25244.917269] ? handle_irq_event+0x44/0x56
[25244.918695] irq_exit+0x61/0xa0
[25244.919947] do_IRQ+0x9d/0xbb
[25244.921065] common_interrupt+0x85/0x85
[25244.922479] </IRQ>
tcp_rtx_queue_tail() (called by tcp_fragment()) can call
tcp_write_queue_prev() on the first packet in the queue, which will trigger
the BUG in tcp_write_queue_prev(), because there is no previous packet.
This happens when the retransmit queue is empty, for example in case of a
zero window.
Patch is needed for 4.4, 4.9 and 4.14 stable branches.
Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
Change-Id: I839bde7167ae59e2f7d916c913507372445765c5
Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Reviewed-by: Christoph Paasch <cpaasch@apple.com>
---
include/net/tcp.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 9de2c8cdcc51..1e70ca75c8bf 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1705,6 +1705,10 @@ static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
{
struct sk_buff *skb = tcp_send_head(sk);
+ /* empty retransmit queue, for example due to zero window */
+ if (skb == tcp_write_queue_head(sk))
+ return NULL;
+
return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
}
--
2.23.0
--
Disclaimer: https://www.tessares.net/mail-disclaimer/
<https://www.tessares.net/mail-disclaimer/>
^ permalink raw reply related [flat|nested] 52+ messages in thread* Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-24 6:03 ` [PATCH 4.14] " Tim Froidcoeur
@ 2019-08-24 22:05 ` Jonathan Lemon
2019-08-30 23:26 ` Christoph Paasch
2019-08-31 12:20 ` Sasha Levin
1 sibling, 1 reply; 52+ messages in thread
From: Jonathan Lemon @ 2019-08-24 22:05 UTC (permalink / raw)
To: Tim Froidcoeur
Cc: matthieu.baerts, aprout, cpaasch, davem, edumazet, gregkh, jtl,
linux-kernel, mkubecek, ncardwell, sashal, stable, ycheng,
netdev
On 23 Aug 2019, at 23:03, Tim Froidcoeur wrote:
> Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> triggers following stack trace:
>
> [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
> [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
> [25244.888167] Call Trace:
> [25244.889182] <IRQ>
> [25244.890001] tcp_fragment+0x9c/0x2cf
> [25244.891295] tcp_write_xmit+0x68f/0x988
> [25244.892732] __tcp_push_pending_frames+0x3b/0xa0
> [25244.894347] tcp_data_snd_check+0x2a/0xc8
> [25244.895775] tcp_rcv_established+0x2a8/0x30d
> [25244.897282] tcp_v4_do_rcv+0xb2/0x158
> [25244.898666] tcp_v4_rcv+0x692/0x956
> [25244.899959] ip_local_deliver_finish+0xeb/0x169
> [25244.901547] __netif_receive_skb_core+0x51c/0x582
> [25244.903193] ? inet_gro_receive+0x239/0x247
> [25244.904756] netif_receive_skb_internal+0xab/0xc6
> [25244.906395] napi_gro_receive+0x8a/0xc0
> [25244.907760] receive_buf+0x9a1/0x9cd
> [25244.909160] ? load_balance+0x17a/0x7b7
> [25244.910536] ? vring_unmap_one+0x18/0x61
> [25244.911932] ? detach_buf+0x60/0xfa
> [25244.913234] virtnet_poll+0x128/0x1e1
> [25244.914607] net_rx_action+0x12a/0x2b1
> [25244.915953] __do_softirq+0x11c/0x26b
> [25244.917269] ? handle_irq_event+0x44/0x56
> [25244.918695] irq_exit+0x61/0xa0
> [25244.919947] do_IRQ+0x9d/0xbb
> [25244.921065] common_interrupt+0x85/0x85
> [25244.922479] </IRQ>
>
> tcp_rtx_queue_tail() (called by tcp_fragment()) can call
> tcp_write_queue_prev() on the first packet in the queue, which will trigger
> the BUG in tcp_write_queue_prev(), because there is no previous packet.
>
> This happens when the retransmit queue is empty, for example in case of a
> zero window.
>
> Patch is needed for 4.4, 4.9 and 4.14 stable branches.
>
> Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> Change-Id: I839bde7167ae59e2f7d916c913507372445765c5
> Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> Reviewed-by: Christoph Paasch <cpaasch@apple.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-24 22:05 ` Jonathan Lemon
@ 2019-08-30 23:26 ` Christoph Paasch
2019-08-31 2:20 ` David Miller
0 siblings, 1 reply; 52+ messages in thread
From: Christoph Paasch @ 2019-08-30 23:26 UTC (permalink / raw)
To: Jonathan Lemon, stable, gregkh
Cc: Tim Froidcoeur, matthieu.baerts, aprout, davem, edumazet, jtl,
linux-kernel, mkubecek, ncardwell, sashal, ycheng, netdev
Hello,
On 24/08/19 - 15:05:20, Jonathan Lemon wrote:
>
>
> On 23 Aug 2019, at 23:03, Tim Froidcoeur wrote:
>
> > Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> > triggers following stack trace:
> >
> > [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
> > [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
> > [25244.888167] Call Trace:
> > [25244.889182] <IRQ>
> > [25244.890001] tcp_fragment+0x9c/0x2cf
> > [25244.891295] tcp_write_xmit+0x68f/0x988
> > [25244.892732] __tcp_push_pending_frames+0x3b/0xa0
> > [25244.894347] tcp_data_snd_check+0x2a/0xc8
> > [25244.895775] tcp_rcv_established+0x2a8/0x30d
> > [25244.897282] tcp_v4_do_rcv+0xb2/0x158
> > [25244.898666] tcp_v4_rcv+0x692/0x956
> > [25244.899959] ip_local_deliver_finish+0xeb/0x169
> > [25244.901547] __netif_receive_skb_core+0x51c/0x582
> > [25244.903193] ? inet_gro_receive+0x239/0x247
> > [25244.904756] netif_receive_skb_internal+0xab/0xc6
> > [25244.906395] napi_gro_receive+0x8a/0xc0
> > [25244.907760] receive_buf+0x9a1/0x9cd
> > [25244.909160] ? load_balance+0x17a/0x7b7
> > [25244.910536] ? vring_unmap_one+0x18/0x61
> > [25244.911932] ? detach_buf+0x60/0xfa
> > [25244.913234] virtnet_poll+0x128/0x1e1
> > [25244.914607] net_rx_action+0x12a/0x2b1
> > [25244.915953] __do_softirq+0x11c/0x26b
> > [25244.917269] ? handle_irq_event+0x44/0x56
> > [25244.918695] irq_exit+0x61/0xa0
> > [25244.919947] do_IRQ+0x9d/0xbb
> > [25244.921065] common_interrupt+0x85/0x85
> > [25244.922479] </IRQ>
> >
> > tcp_rtx_queue_tail() (called by tcp_fragment()) can call
> > tcp_write_queue_prev() on the first packet in the queue, which will trigger
> > the BUG in tcp_write_queue_prev(), because there is no previous packet.
> >
> > This happens when the retransmit queue is empty, for example in case of a
> > zero window.
> >
> > Patch is needed for 4.4, 4.9 and 4.14 stable branches.
> >
> > Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> > Change-Id: I839bde7167ae59e2f7d916c913507372445765c5
> > Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
> > Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> > Reviewed-by: Christoph Paasch <cpaasch@apple.com>
>
> Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
just checking in, if the patch is getting picked up for -stable ?
(I don't see it in the stable-queue)
Thanks,
Christoph
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-30 23:26 ` Christoph Paasch
@ 2019-08-31 2:20 ` David Miller
2019-08-31 10:53 ` maowenan
2019-08-31 11:44 ` maowenan
0 siblings, 2 replies; 52+ messages in thread
From: David Miller @ 2019-08-31 2:20 UTC (permalink / raw)
To: cpaasch
Cc: jonathan.lemon, stable, gregkh, tim.froidcoeur, matthieu.baerts,
aprout, edumazet, jtl, linux-kernel, mkubecek, ncardwell, sashal,
ycheng, netdev
From: Christoph Paasch <cpaasch@apple.com>
Date: Fri, 30 Aug 2019 16:26:57 -0700
> (I don't see it in the stable-queue)
I don't handle any stable branch before the most recent two, so this isn't
my territory.
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-31 2:20 ` David Miller
@ 2019-08-31 10:53 ` maowenan
2019-08-31 11:44 ` maowenan
1 sibling, 0 replies; 52+ messages in thread
From: maowenan @ 2019-08-31 10:53 UTC (permalink / raw)
To: David Miller, cpaasch
Cc: jonathan.lemon, stable, gregkh, tim.froidcoeur, matthieu.baerts,
aprout, edumazet, jtl, linux-kernel, mkubecek, ncardwell, sashal,
ycheng, netdev
[<ffffff90094930dc>] skb_peek_tail include/linux/skbuff.h:1516 [inline]
[<ffffff90094930dc>] tcp_write_queue_tail include/net/tcp.h:1478 [inline]
[<ffffff90094930dc>] tcp_rtx_queue_tail include/net/tcp.h:1543 [inline]
[<ffffff90094930dc>] tcp_fragment+0xc64/0xce8 net/ipv4/tcp_output.c:1175
[<ffffff90094a37f0>] tcp_write_wakeup+0x3f8/0x4a0 net/ipv4/tcp_output.c:3496
[<ffffff90094a38d0>] tcp_send_probe0+0x38/0x2d8 net/ipv4/tcp_output.c:3523
[<ffffff90094a75a0>] tcp_probe_timer net/ipv4/tcp_timer.c:343 [inline]
[<ffffff90094a75a0>] tcp_write_timer_handler+0x640/0x720 net/ipv4/tcp_timer.c:548
[<ffffff90094a76f8>] tcp_write_timer+0x78/0x1d0 net/ipv4/tcp_timer.c:562
[<ffffff90082610b0>] call_timer_fn.isra.1+0x58/0x180 kernel/time/timer.c:1144
[<ffffff90082616ec>] __run_timers kernel/time/timer.c:1218 [inline]
[<ffffff90082616ec>] run_timer_softirq+0x514/0x848 kernel/time/timer.c:1401
[<ffffff9008141a28>] __do_softirq+0x340/0x878 kernel/softirq.c:273
[<ffffff9008142890>] do_softirq_own_stack include/linux/interrupt.h:498 [inline]
[<ffffff9008142890>] invoke_softirq kernel/softirq.c:357 [inline]
[<ffffff9008142890>] irq_exit+0x170/0x370 kernel/softirq.c:391
[<ffffff900821d550>] __handle_domain_irq+0x100/0x1c0 kernel/irq/irqdesc.c:459
[<ffffff90080914a0>] handle_domain_irq include/linux/irqdesc.h:168 [inline]
[<ffffff90080914a0>] gic_handle_irq+0xd0/0x1f0 drivers/irqchip/irq-gic.c:377
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-31 2:20 ` David Miller
2019-08-31 10:53 ` maowenan
@ 2019-08-31 11:44 ` maowenan
[not found] ` <CAOj+RUsqTUF9fuetskRRw26Z=sBM-mELSMcV21Ch06007aP5yQ@mail.gmail.com>
1 sibling, 1 reply; 52+ messages in thread
From: maowenan @ 2019-08-31 11:44 UTC (permalink / raw)
To: David Miller, cpaasch
Cc: jonathan.lemon, stable, gregkh, tim.froidcoeur, matthieu.baerts,
aprout, edumazet, jtl, linux-kernel, mkubecek, ncardwell, sashal,
ycheng, netdev
Tim
Can you share the reproduce steps for this issue? C or syzkaller is ok.
Thanks a lot.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-24 6:03 ` [PATCH 4.14] " Tim Froidcoeur
2019-08-24 22:05 ` Jonathan Lemon
@ 2019-08-31 12:20 ` Sasha Levin
2019-08-31 13:14 ` Matthieu Baerts
1 sibling, 1 reply; 52+ messages in thread
From: Sasha Levin @ 2019-08-31 12:20 UTC (permalink / raw)
To: Tim Froidcoeur
Cc: matthieu.baerts, aprout, cpaasch, davem, edumazet, gregkh,
jonathan.lemon, jtl, linux-kernel, mkubecek, ncardwell, stable,
ycheng, netdev
On Sat, Aug 24, 2019 at 08:03:51AM +0200, Tim Froidcoeur wrote:
>Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
>triggers following stack trace:
>
>[25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
>[25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
>[25244.888167] Call Trace:
>[25244.889182] <IRQ>
>[25244.890001] tcp_fragment+0x9c/0x2cf
>[25244.891295] tcp_write_xmit+0x68f/0x988
>[25244.892732] __tcp_push_pending_frames+0x3b/0xa0
>[25244.894347] tcp_data_snd_check+0x2a/0xc8
>[25244.895775] tcp_rcv_established+0x2a8/0x30d
>[25244.897282] tcp_v4_do_rcv+0xb2/0x158
>[25244.898666] tcp_v4_rcv+0x692/0x956
>[25244.899959] ip_local_deliver_finish+0xeb/0x169
>[25244.901547] __netif_receive_skb_core+0x51c/0x582
>[25244.903193] ? inet_gro_receive+0x239/0x247
>[25244.904756] netif_receive_skb_internal+0xab/0xc6
>[25244.906395] napi_gro_receive+0x8a/0xc0
>[25244.907760] receive_buf+0x9a1/0x9cd
>[25244.909160] ? load_balance+0x17a/0x7b7
>[25244.910536] ? vring_unmap_one+0x18/0x61
>[25244.911932] ? detach_buf+0x60/0xfa
>[25244.913234] virtnet_poll+0x128/0x1e1
>[25244.914607] net_rx_action+0x12a/0x2b1
>[25244.915953] __do_softirq+0x11c/0x26b
>[25244.917269] ? handle_irq_event+0x44/0x56
>[25244.918695] irq_exit+0x61/0xa0
>[25244.919947] do_IRQ+0x9d/0xbb
>[25244.921065] common_interrupt+0x85/0x85
>[25244.922479] </IRQ>
>
>tcp_rtx_queue_tail() (called by tcp_fragment()) can call
>tcp_write_queue_prev() on the first packet in the queue, which will trigger
>the BUG in tcp_write_queue_prev(), because there is no previous packet.
>
>This happens when the retransmit queue is empty, for example in case of a
>zero window.
>
>Patch is needed for 4.4, 4.9 and 4.14 stable branches.
There needs to be a better explanation of why it's not needed
upstream...
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-31 12:20 ` Sasha Levin
@ 2019-08-31 13:14 ` Matthieu Baerts
2019-09-01 0:07 ` Sasha Levin
0 siblings, 1 reply; 52+ messages in thread
From: Matthieu Baerts @ 2019-08-31 13:14 UTC (permalink / raw)
To: Sasha Levin, Tim Froidcoeur
Cc: aprout, cpaasch, davem, edumazet, gregkh, jonathan.lemon, jtl,
linux-kernel, mkubecek, ncardwell, stable, ycheng, netdev
Hi Sasha,
Thank you for your reply!
On 31/08/2019 14:20, Sasha Levin wrote:
> On Sat, Aug 24, 2019 at 08:03:51AM +0200, Tim Froidcoeur wrote:
>> Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
>> triggers following stack trace:
>>
>> [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
>> [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
>> [25244.888167] Call Trace:
>> [25244.889182] <IRQ>
>> [25244.890001] tcp_fragment+0x9c/0x2cf
>> [25244.891295] tcp_write_xmit+0x68f/0x988
>> [25244.892732] __tcp_push_pending_frames+0x3b/0xa0
>> [25244.894347] tcp_data_snd_check+0x2a/0xc8
>> [25244.895775] tcp_rcv_established+0x2a8/0x30d
>> [25244.897282] tcp_v4_do_rcv+0xb2/0x158
>> [25244.898666] tcp_v4_rcv+0x692/0x956
>> [25244.899959] ip_local_deliver_finish+0xeb/0x169
>> [25244.901547] __netif_receive_skb_core+0x51c/0x582
>> [25244.903193] ? inet_gro_receive+0x239/0x247
>> [25244.904756] netif_receive_skb_internal+0xab/0xc6
>> [25244.906395] napi_gro_receive+0x8a/0xc0
>> [25244.907760] receive_buf+0x9a1/0x9cd
>> [25244.909160] ? load_balance+0x17a/0x7b7
>> [25244.910536] ? vring_unmap_one+0x18/0x61
>> [25244.911932] ? detach_buf+0x60/0xfa
>> [25244.913234] virtnet_poll+0x128/0x1e1
>> [25244.914607] net_rx_action+0x12a/0x2b1
>> [25244.915953] __do_softirq+0x11c/0x26b
>> [25244.917269] ? handle_irq_event+0x44/0x56
>> [25244.918695] irq_exit+0x61/0xa0
>> [25244.919947] do_IRQ+0x9d/0xbb
>> [25244.921065] common_interrupt+0x85/0x85
>> [25244.922479] </IRQ>
>>
>> tcp_rtx_queue_tail() (called by tcp_fragment()) can call
>> tcp_write_queue_prev() on the first packet in the queue, which will
>> trigger
>> the BUG in tcp_write_queue_prev(), because there is no previous packet.
>>
>> This happens when the retransmit queue is empty, for example in case of a
>> zero window.
>>
>> Patch is needed for 4.4, 4.9 and 4.14 stable branches.
>
> There needs to be a better explanation of why it's not needed
> upstream...
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()") was not a
simple cherry-pick of the original one from master (b617158dc096)
because there is a specific TCP rtx queue only since v4.15. For more
details, please see the commit message of b617158dc096 ("tcp: be more
careful in tcp_fragment()").
The BUG() is hit due to the specific code added to versions older than
v4.15. The comment in skb_queue_prev() (include/linux/skbuff.h:1406),
just before the BUG_ON() somehow suggests to add a check before using
it, what Tim did.
In master, this code path causing the issue will not be taken because
the implementation of tcp_rtx_queue_tail() is different:
tcp_fragment() → tcp_rtx_queue_tail() → tcp_write_queue_prev() →
skb_queue_prev() → BUG_ON()
Because this patch is specific to versions older than the two last
stable ones but still linked to the network architecture, who can review
and approve it? :)
Cheers,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts@tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
2019-08-31 13:14 ` Matthieu Baerts
@ 2019-09-01 0:07 ` Sasha Levin
0 siblings, 0 replies; 52+ messages in thread
From: Sasha Levin @ 2019-09-01 0:07 UTC (permalink / raw)
To: Matthieu Baerts
Cc: Tim Froidcoeur, aprout, cpaasch, davem, edumazet, gregkh,
jonathan.lemon, jtl, linux-kernel, mkubecek, ncardwell, stable,
ycheng, netdev
On Sat, Aug 31, 2019 at 03:14:35PM +0200, Matthieu Baerts wrote:
>Hi Sasha,
>
>Thank you for your reply!
>
>On 31/08/2019 14:20, Sasha Levin wrote:
>> On Sat, Aug 24, 2019 at 08:03:51AM +0200, Tim Froidcoeur wrote:
>>> Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
>>> triggers following stack trace:
>>>
>>> [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
>>> [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
>>> [25244.888167] Call Trace:
>>> [25244.889182] <IRQ>
>>> [25244.890001] tcp_fragment+0x9c/0x2cf
>>> [25244.891295] tcp_write_xmit+0x68f/0x988
>>> [25244.892732] __tcp_push_pending_frames+0x3b/0xa0
>>> [25244.894347] tcp_data_snd_check+0x2a/0xc8
>>> [25244.895775] tcp_rcv_established+0x2a8/0x30d
>>> [25244.897282] tcp_v4_do_rcv+0xb2/0x158
>>> [25244.898666] tcp_v4_rcv+0x692/0x956
>>> [25244.899959] ip_local_deliver_finish+0xeb/0x169
>>> [25244.901547] __netif_receive_skb_core+0x51c/0x582
>>> [25244.903193] ? inet_gro_receive+0x239/0x247
>>> [25244.904756] netif_receive_skb_internal+0xab/0xc6
>>> [25244.906395] napi_gro_receive+0x8a/0xc0
>>> [25244.907760] receive_buf+0x9a1/0x9cd
>>> [25244.909160] ? load_balance+0x17a/0x7b7
>>> [25244.910536] ? vring_unmap_one+0x18/0x61
>>> [25244.911932] ? detach_buf+0x60/0xfa
>>> [25244.913234] virtnet_poll+0x128/0x1e1
>>> [25244.914607] net_rx_action+0x12a/0x2b1
>>> [25244.915953] __do_softirq+0x11c/0x26b
>>> [25244.917269] ? handle_irq_event+0x44/0x56
>>> [25244.918695] irq_exit+0x61/0xa0
>>> [25244.919947] do_IRQ+0x9d/0xbb
>>> [25244.921065] common_interrupt+0x85/0x85
>>> [25244.922479] </IRQ>
>>>
>>> tcp_rtx_queue_tail() (called by tcp_fragment()) can call
>>> tcp_write_queue_prev() on the first packet in the queue, which will
>>> trigger
>>> the BUG in tcp_write_queue_prev(), because there is no previous packet.
>>>
>>> This happens when the retransmit queue is empty, for example in case of a
>>> zero window.
>>>
>>> Patch is needed for 4.4, 4.9 and 4.14 stable branches.
>>
>> There needs to be a better explanation of why it's not needed
>> upstream...
>
>Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()") was not a
>simple cherry-pick of the original one from master (b617158dc096)
>because there is a specific TCP rtx queue only since v4.15. For more
>details, please see the commit message of b617158dc096 ("tcp: be more
>careful in tcp_fragment()").
>
>The BUG() is hit due to the specific code added to versions older than
>v4.15. The comment in skb_queue_prev() (include/linux/skbuff.h:1406),
>just before the BUG_ON() somehow suggests to add a check before using
>it, what Tim did.
>
>In master, this code path causing the issue will not be taken because
>the implementation of tcp_rtx_queue_tail() is different:
>
> tcp_fragment() → tcp_rtx_queue_tail() → tcp_write_queue_prev() →
>skb_queue_prev() → BUG_ON()
>
>Because this patch is specific to versions older than the two last
>stable ones but still linked to the network architecture, who can review
>and approve it? :)
Thanks for the explanation. I've changed the commit message to include
this explanation and queued it for 4.4, 4.9 and 4.14.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 4.14 05/33] arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG}
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 04/33] tcp: be more careful in tcp_fragment() Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 06/33] HID: wacom: fix bit shift for Cintiq Companion 2 Greg Kroah-Hartman
` (30 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Suzuki K Poulose, Mark Rutland,
Will Deacon, Catalin Marinas
From: Will Deacon <will@kernel.org>
commit 147b9635e6347104b91f48ca9dca61eb0fbf2a54 upstream.
If CTR_EL0.{CWG,ERG} are 0b0000 then they must be interpreted to have
their architecturally maximum values, which defeats the use of
FTR_HIGHER_SAFE when sanitising CPU ID registers on heterogeneous
machines.
Introduce FTR_HIGHER_OR_ZERO_SAFE so that these fields effectively
saturate at zero.
Fixes: 3c739b571084 ("arm64: Keep track of CPU feature registers")
Cc: <stable@vger.kernel.org> # 4.4.x-
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/cpufeature.h | 7 ++++---
arch/arm64/kernel/cpufeature.c | 8 ++++++--
2 files changed, 10 insertions(+), 5 deletions(-)
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -44,9 +44,10 @@
*/
enum ftr_type {
- FTR_EXACT, /* Use a predefined safe value */
- FTR_LOWER_SAFE, /* Smaller value is safe */
- FTR_HIGHER_SAFE,/* Bigger value is safe */
+ FTR_EXACT, /* Use a predefined safe value */
+ FTR_LOWER_SAFE, /* Smaller value is safe */
+ FTR_HIGHER_SAFE, /* Bigger value is safe */
+ FTR_HIGHER_OR_ZERO_SAFE, /* Bigger value is safe, but 0 is biggest */
};
#define FTR_STRICT true /* SANITY check strict matching required */
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -178,8 +178,8 @@ static const struct arm64_ftr_bits ftr_c
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 29, 1, 1), /* DIC */
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 28, 1, 1), /* IDC */
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, 24, 4, 0), /* CWG */
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, 20, 4, 0), /* ERG */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 24, 4, 0), /* CWG */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 20, 4, 0), /* ERG */
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DMINLINE_SHIFT, 4, 1),
/*
* Linux can handle differing I-cache policies. Userspace JITs will
@@ -411,6 +411,10 @@ static s64 arm64_ftr_safe_value(const st
case FTR_LOWER_SAFE:
ret = new < cur ? new : cur;
break;
+ case FTR_HIGHER_OR_ZERO_SAFE:
+ if (!cur || !new)
+ break;
+ /* Fallthrough */
case FTR_HIGHER_SAFE:
ret = new > cur ? new : cur;
break;
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 06/33] HID: wacom: fix bit shift for Cintiq Companion 2
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 05/33] arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 07/33] HID: Add quirk for HP X1200 PIXART OEM mouse Greg Kroah-Hartman
` (29 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aaron Armstrong Skomra, Ping Cheng,
Jiri Kosina
From: Aaron Armstrong Skomra <skomra@gmail.com>
commit 693c3dab4e50403f91bca4b52fc6d8562a3180f6 upstream.
The bit indicating BTN_6 on this device is overshifted
by 2 bits, resulting in the incorrect button being
reported.
Also fix copy-paste mistake in comments.
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Link: https://github.com/linuxwacom/xf86-input-wacom/issues/71
Fixes: c7f0522a1ad1 ("HID: wacom: Slim down wacom_intuos_pad processing")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/wacom_wac.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -537,14 +537,14 @@ static int wacom_intuos_pad(struct wacom
*/
buttons = (data[4] << 1) | (data[3] & 0x01);
} else if (features->type == CINTIQ_COMPANION_2) {
- /* d-pad right -> data[4] & 0x10
- * d-pad up -> data[4] & 0x20
- * d-pad left -> data[4] & 0x40
- * d-pad down -> data[4] & 0x80
- * d-pad center -> data[3] & 0x01
+ /* d-pad right -> data[2] & 0x10
+ * d-pad up -> data[2] & 0x20
+ * d-pad left -> data[2] & 0x40
+ * d-pad down -> data[2] & 0x80
+ * d-pad center -> data[1] & 0x01
*/
buttons = ((data[2] >> 4) << 7) |
- ((data[1] & 0x04) << 6) |
+ ((data[1] & 0x04) << 4) |
((data[2] & 0x0F) << 2) |
(data[1] & 0x03);
} else if (features->type >= INTUOS5S && features->type <= INTUOSPL) {
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 07/33] HID: Add quirk for HP X1200 PIXART OEM mouse
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 06/33] HID: wacom: fix bit shift for Cintiq Companion 2 Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 08/33] RDMA: Directly cast the sockaddr union to sockaddr Greg Kroah-Hartman
` (28 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sebastian Parschauer, Jiri Kosina
From: Sebastian Parschauer <s.parschauer@gmx.de>
commit 49869d2ea9eecc105a10724c1abf035151a3c4e2 upstream.
The PixArt OEM mice are known for disconnecting every minute in
runlevel 1 or 3 if they are not always polled. So add quirk
ALWAYS_POLL for this one as well.
Jonathan Teh (@jonathan-teh) reported and tested the quirk.
Reference: https://github.com/sriemer/fix-linux-mouse/issues/15
Signed-off-by: Sebastian Parschauer <s.parschauer@gmx.de>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -537,6 +537,7 @@
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A 0x094a
+#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_0641 0x0641
#define USB_VENDOR_ID_HUION 0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -100,6 +100,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A, HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_0641, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_IDEACOM, USB_DEVICE_ID_IDEACOM_IDC6680, HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C007, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077, HID_QUIRK_ALWAYS_POLL },
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 08/33] RDMA: Directly cast the sockaddr union to sockaddr
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 07/33] HID: Add quirk for HP X1200 PIXART OEM mouse Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 09/33] [PATCH] IB: directly cast the sockaddr union to aockaddr Greg Kroah-Hartman
` (27 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jason Gunthorpe
From: Jason Gunthorpe <jgg@mellanox.com>
commit 641114d2af312d39ca9bbc2369d18a5823da51c6 upstream.
gcc 9 now does allocation size tracking and thinks that passing the member
of a union and then accessing beyond that member's bounds is an overflow.
Instead of using the union member, use the entire union with a cast to
get to the sockaddr. gcc will now know that the memory extends the full
size of the union.
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 15 +++++++--------
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 5 ++---
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 5 ++---
3 files changed, 11 insertions(+), 14 deletions(-)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -794,14 +794,13 @@ int rdma_addr_find_l2_eth_by_grh(const u
struct net_device *dev;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
- rdma_gid2ip(&sgid_addr._sockaddr, sgid);
- rdma_gid2ip(&dgid_addr._sockaddr, dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, sgid);
+ rdma_gid2ip((struct sockaddr *)&dgid_addr, dgid);
memset(&dev_addr, 0, sizeof(dev_addr));
if (if_index)
@@ -810,8 +809,9 @@ int rdma_addr_find_l2_eth_by_grh(const u
ctx.addr = &dev_addr;
init_completion(&ctx.comp);
- ret = rdma_resolve_ip(&self, &sgid_addr._sockaddr, &dgid_addr._sockaddr,
- &dev_addr, 1000, resolve_cb, &ctx);
+ ret = rdma_resolve_ip(&self, (struct sockaddr *)&sgid_addr,
+ (struct sockaddr *)&dgid_addr, &dev_addr, 1000,
+ resolve_cb, &ctx);
if (ret)
return ret;
@@ -841,16 +841,15 @@ int rdma_addr_find_smac_by_sgid(union ib
int ret = 0;
struct rdma_dev_addr dev_addr;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} gid_addr;
- rdma_gid2ip(&gid_addr._sockaddr, sgid);
+ rdma_gid2ip((struct sockaddr *)&gid_addr, sgid);
memset(&dev_addr, 0, sizeof(dev_addr));
dev_addr.net = &init_net;
- ret = rdma_translate_ip(&gid_addr._sockaddr, &dev_addr, vlan_id);
+ ret = rdma_translate_ip((struct sockaddr *)&gid_addr, &dev_addr, vlan_id);
if (ret)
return ret;
--- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
@@ -83,7 +83,6 @@ static inline int set_av_attr(struct ocr
struct iphdr ipv4;
const struct ib_global_route *ib_grh;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
@@ -133,9 +132,9 @@ static inline int set_av_attr(struct ocr
ipv4.tot_len = htons(0);
ipv4.ttl = ib_grh->hop_limit;
ipv4.protocol = nxthdr;
- rdma_gid2ip(&sgid_addr._sockaddr, sgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, sgid);
ipv4.saddr = sgid_addr._sockaddr_in.sin_addr.s_addr;
- rdma_gid2ip(&dgid_addr._sockaddr, &ib_grh->dgid);
+ rdma_gid2ip((struct sockaddr*)&dgid_addr, &ib_grh->dgid);
ipv4.daddr = dgid_addr._sockaddr_in.sin_addr.s_addr;
memcpy((u8 *)ah->av + eth_sz, &ipv4, sizeof(struct iphdr));
} else {
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -2508,7 +2508,6 @@ static int ocrdma_set_av_params(struct o
u32 vlan_id = 0xFFFF;
u8 mac_addr[6], hdr_type;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
@@ -2556,8 +2555,8 @@ static int ocrdma_set_av_params(struct o
hdr_type = ib_gid_to_network_type(sgid_attr.gid_type, &sgid);
if (hdr_type == RDMA_NETWORK_IPV4) {
- rdma_gid2ip(&sgid_addr._sockaddr, &sgid);
- rdma_gid2ip(&dgid_addr._sockaddr, &grh->dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, &sgid);
+ rdma_gid2ip((struct sockaddr *)&dgid_addr, &grh->dgid);
memcpy(&cmd->params.dgid[0],
&dgid_addr._sockaddr_in.sin_addr.s_addr, 4);
memcpy(&cmd->params.sgid[0],
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 09/33] [PATCH] IB: directly cast the sockaddr union to aockaddr
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 08/33] RDMA: Directly cast the sockaddr union to sockaddr Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 10/33] objtool: Add machine_real_restart() to the noreturn list Greg Kroah-Hartman
` (26 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jason Gunthorpe
Like commit 641114d2af31 ("RDMA: Directly cast the sockaddr union to
sockaddr") we need to quiet gcc 9 from warning about this crazy union.
That commit did not fix all of the warnings in 4.19 and older kernels
because the logic in roce_resolve_route_from_path() was rewritten
between 4.19 and 5.2 when that change happened.
Cc: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/sa_query.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -1263,7 +1263,6 @@ int ib_init_ah_from_path(struct ib_devic
&init_net
};
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
@@ -1271,12 +1270,13 @@ int ib_init_ah_from_path(struct ib_devic
if (!device->get_netdev)
return -EOPNOTSUPP;
- rdma_gid2ip(&sgid_addr._sockaddr, &rec->sgid);
- rdma_gid2ip(&dgid_addr._sockaddr, &rec->dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, &rec->sgid);
+ rdma_gid2ip((struct sockaddr *)&dgid_addr, &rec->dgid);
/* validate the route */
- ret = rdma_resolve_ip_route(&sgid_addr._sockaddr,
- &dgid_addr._sockaddr, &dev_addr);
+ ret = rdma_resolve_ip_route((struct sockaddr *)&sgid_addr,
+ (struct sockaddr *)&dgid_addr,
+ &dev_addr);
if (ret)
return ret;
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 10/33] objtool: Add machine_real_restart() to the noreturn list
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 09/33] [PATCH] IB: directly cast the sockaddr union to aockaddr Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 11/33] objtool: Add rewind_stack_do_exit() " Greg Kroah-Hartman
` (25 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matthias Kaehlcke, Josh Poimboeuf,
Thomas Gleixner
From: Josh Poimboeuf <jpoimboe@redhat.com>
commit 684fb246578b9e81fc7b4ca5c71eae22edb650b2 upstream.
machine_real_restart() is annotated as '__noreturn", so add it to the
objtool noreturn list. This fixes the following warning with clang and
CONFIG_CC_OPTIMIZE_FOR_SIZE=y:
arch/x86/kernel/reboot.o: warning: objtool: native_machine_emergency_restart() falls through to next function machine_power_off()
Reported-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lkml.kernel.org/r/791712792aa4431bdd55bf1beb33a169ddf3b4a2.1529423255.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/objtool/check.c | 1 +
1 file changed, 1 insertion(+)
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -165,6 +165,7 @@ static int __dead_end_function(struct ob
"__reiserfs_panic",
"lbug_with_loc",
"fortify_panic",
+ "machine_real_restart",
};
if (func->bind == STB_WEAK)
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 11/33] objtool: Add rewind_stack_do_exit() to the noreturn list
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 10/33] objtool: Add machine_real_restart() to the noreturn list Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 12/33] atm: iphase: Fix Spectre v1 vulnerability Greg Kroah-Hartman
` (24 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, kbuild test robot, Josh Poimboeuf,
Thomas Gleixner, Peter Zijlstra
From: Josh Poimboeuf <jpoimboe@redhat.com>
commit 4fa5ecda2bf96be7464eb406df8aba9d89260227 upstream.
This fixes the following warning seen on GCC 7.3:
arch/x86/kernel/dumpstack.o: warning: objtool: oops_end() falls through to next function show_regs()
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lkml.kernel.org/r/3418ebf5a5a9f6ed7e80954c741c0b904b67b5dc.1554398240.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/objtool/check.c | 1 +
1 file changed, 1 insertion(+)
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -166,6 +166,7 @@ static int __dead_end_function(struct ob
"lbug_with_loc",
"fortify_panic",
"machine_real_restart",
+ "rewind_stack_do_exit",
};
if (func->bind == STB_WEAK)
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 12/33] atm: iphase: Fix Spectre v1 vulnerability
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 11/33] objtool: Add rewind_stack_do_exit() " Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 13/33] ife: error out when nla attributes are empty Greg Kroah-Hartman
` (23 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gustavo A. R. Silva, David S. Miller
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
[ Upstream commit ea443e5e98b5b74e317ef3d26bcaea54931ccdee ]
board is controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/atm/iphase.c:2765 ia_ioctl() warn: potential spectre issue 'ia_dev' [r] (local cap)
drivers/atm/iphase.c:2774 ia_ioctl() warn: possible spectre second half. 'iadev'
drivers/atm/iphase.c:2782 ia_ioctl() warn: possible spectre second half. 'iadev'
drivers/atm/iphase.c:2816 ia_ioctl() warn: possible spectre second half. 'iadev'
drivers/atm/iphase.c:2823 ia_ioctl() warn: possible spectre second half. 'iadev'
drivers/atm/iphase.c:2830 ia_ioctl() warn: potential spectre issue '_ia_dev' [r] (local cap)
drivers/atm/iphase.c:2845 ia_ioctl() warn: possible spectre second half. 'iadev'
drivers/atm/iphase.c:2856 ia_ioctl() warn: possible spectre second half. 'iadev'
Fix this by sanitizing board before using it to index ia_dev and _ia_dev
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/atm/iphase.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -63,6 +63,7 @@
#include <asm/byteorder.h>
#include <linux/vmalloc.h>
#include <linux/jiffies.h>
+#include <linux/nospec.h>
#include "iphase.h"
#include "suni.h"
#define swap_byte_order(x) (((x & 0xff) << 8) | ((x & 0xff00) >> 8))
@@ -2760,8 +2761,11 @@ static int ia_ioctl(struct atm_dev *dev,
}
if (copy_from_user(&ia_cmds, arg, sizeof ia_cmds)) return -EFAULT;
board = ia_cmds.status;
- if ((board < 0) || (board > iadev_count))
- board = 0;
+
+ if ((board < 0) || (board > iadev_count))
+ board = 0;
+ board = array_index_nospec(board, iadev_count + 1);
+
iadev = ia_dev[board];
switch (ia_cmds.cmd) {
case MEMDUMP:
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 13/33] ife: error out when nla attributes are empty
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 12/33] atm: iphase: Fix Spectre v1 vulnerability Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 14/33] ip6_tunnel: fix possible use-after-free on xmit Greg Kroah-Hartman
` (22 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+fbb5b288c9cb6a2eeac4,
Jamal Hadi Salim, Jiri Pirko, Cong Wang, David S. Miller
From: Cong Wang <xiyou.wangcong@gmail.com>
[ Upstream commit c8ec4632c6ac9cda0e8c3d51aa41eeab66585bd5 ]
act_ife at least requires TCA_IFE_PARMS, so we have to bail out
when there is no attribute passed in.
Reported-by: syzbot+fbb5b288c9cb6a2eeac4@syzkaller.appspotmail.com
Fixes: ef6980b6becb ("introduce IFE action")
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sched/act_ife.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -459,6 +459,9 @@ static int tcf_ife_init(struct net *net,
int ret = 0;
int err;
+ if (!nla)
+ return -EINVAL;
+
err = nla_parse_nested(tb, TCA_IFE_MAX, nla, ife_policy, NULL);
if (err < 0)
return err;
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 14/33] ip6_tunnel: fix possible use-after-free on xmit
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 13/33] ife: error out when nla attributes are empty Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 15/33] net: bridge: delete local fdb on device init failure Greg Kroah-Hartman
` (21 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Haishuang Yan, David S. Miller
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
[ Upstream commit 01f5bffad555f8e22a61f4b1261fe09cf1b96994 ]
ip4ip6/ip6ip6 tunnels run iptunnel_handle_offloads on xmit which
can cause a possible use-after-free accessing iph/ipv6h pointer
since the packet will be 'uncloned' running pskb_expand_head if
it is a cloned gso skb.
Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets")
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ip6_tunnel.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1280,12 +1280,11 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, str
}
fl6.flowi6_uid = sock_net_uid(dev_net(dev), NULL);
+ dsfield = INET_ECN_encapsulate(dsfield, ipv4_get_dsfield(iph));
if (iptunnel_handle_offloads(skb, SKB_GSO_IPXIP6))
return -1;
- dsfield = INET_ECN_encapsulate(dsfield, ipv4_get_dsfield(iph));
-
skb_set_inner_ipproto(skb, IPPROTO_IPIP);
err = ip6_tnl_xmit(skb, dev, dsfield, &fl6, encap_limit, &mtu,
@@ -1371,12 +1370,11 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
}
fl6.flowi6_uid = sock_net_uid(dev_net(dev), NULL);
+ dsfield = INET_ECN_encapsulate(dsfield, ipv6_get_dsfield(ipv6h));
if (iptunnel_handle_offloads(skb, SKB_GSO_IPXIP6))
return -1;
- dsfield = INET_ECN_encapsulate(dsfield, ipv6_get_dsfield(ipv6h));
-
skb_set_inner_ipproto(skb, IPPROTO_IPV6);
err = ip6_tnl_xmit(skb, dev, dsfield, &fl6, encap_limit, &mtu,
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 15/33] net: bridge: delete local fdb on device init failure
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 14/33] ip6_tunnel: fix possible use-after-free on xmit Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 16/33] net: bridge: mcast: dont delete permanent entries when fast leave is enabled Greg Kroah-Hartman
` (20 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+88533dc8b582309bf3ee,
Nikolay Aleksandrov, David S. Miller
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
[ Upstream commit d7bae09fa008c6c9a489580db0a5a12063b97f97 ]
On initialization failure we have to delete the local fdb which was
inserted due to the default pvid creation. This problem has been present
since the inception of default_pvid. Note that currently there are 2 cases:
1) in br_dev_init() when br_multicast_init() fails
2) if register_netdevice() fails after calling ndo_init()
This patch takes care of both since br_vlan_flush() is called on both
occasions. Also the new fdb delete would be a no-op on normal bridge
device destruction since the local fdb would've been already flushed by
br_dev_delete(). This is not an issue for ports since nbp_vlan_init() is
called last when adding a port thus nothing can fail after it.
Reported-by: syzbot+88533dc8b582309bf3ee@syzkaller.appspotmail.com
Fixes: 5be5a2df40f0 ("bridge: Add filtering support for default_pvid")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bridge/br_vlan.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -636,6 +636,11 @@ void br_vlan_flush(struct net_bridge *br
ASSERT_RTNL();
+ /* delete auto-added default pvid local fdb before flushing vlans
+ * otherwise it will be leaked on bridge device init failure
+ */
+ br_fdb_delete_by_port(br, NULL, 0, 1);
+
vg = br_vlan_group(br);
__vlan_flush(vg);
RCU_INIT_POINTER(br->vlgrp, NULL);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 16/33] net: bridge: mcast: dont delete permanent entries when fast leave is enabled
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 15/33] net: bridge: delete local fdb on device init failure Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 17/33] net: fix ifindex collision during namespace removal Greg Kroah-Hartman
` (19 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikolay Aleksandrov, David S. Miller
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
[ Upstream commit 5c725b6b65067909548ac9ca9bc777098ec9883d ]
When permanent entries were introduced by the commit below, they were
exempt from timing out and thus igmp leave wouldn't affect them unless
fast leave was enabled on the port which was added before permanent
entries existed. It shouldn't matter if fast leave is enabled or not
if the user added a permanent entry it shouldn't be deleted on igmp
leave.
Before:
$ echo 1 > /sys/class/net/eth4/brport/multicast_fast_leave
$ bridge mdb add dev br0 port eth4 grp 229.1.1.1 permanent
$ bridge mdb show
dev br0 port eth4 grp 229.1.1.1 permanent
< join and leave 229.1.1.1 on eth4 >
$ bridge mdb show
$
After:
$ echo 1 > /sys/class/net/eth4/brport/multicast_fast_leave
$ bridge mdb add dev br0 port eth4 grp 229.1.1.1 permanent
$ bridge mdb show
dev br0 port eth4 grp 229.1.1.1 permanent
< join and leave 229.1.1.1 on eth4 >
$ bridge mdb show
dev br0 port eth4 grp 229.1.1.1 permanent
Fixes: ccb1c31a7a87 ("bridge: add flags to distinguish permanent mdb entires")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bridge/br_multicast.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1593,6 +1593,9 @@ br_multicast_leave_group(struct net_brid
if (!br_port_group_equal(p, port, src))
continue;
+ if (p->flags & MDB_PG_FLAGS_PERMANENT)
+ break;
+
rcu_assign_pointer(*pp, p->next);
hlist_del_init(&p->mglist);
del_timer(&p->timer);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 17/33] net: fix ifindex collision during namespace removal
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 16/33] net: bridge: mcast: dont delete permanent entries when fast leave is enabled Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 18/33] net/mlx5: Use reversed order when unregister devices Greg Kroah-Hartman
` (18 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jiri Pirko, David S. Miller
From: Jiri Pirko <jiri@mellanox.com>
[ Upstream commit 55b40dbf0e76b4bfb9d8b3a16a0208640a9a45df ]
Commit aca51397d014 ("netns: Fix arbitrary net_device-s corruptions
on net_ns stop.") introduced a possibility to hit a BUG in case device
is returning back to init_net and two following conditions are met:
1) dev->ifindex value is used in a name of another "dev%d"
device in init_net.
2) dev->name is used by another device in init_net.
Under real life circumstances this is hard to get. Therefore this has
been present happily for over 10 years. To reproduce:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 86:89:3f:86:61:29 brd ff:ff:ff:ff:ff:ff
3: enp0s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
$ ip netns add ns1
$ ip -n ns1 link add dummy1ns1 type dummy
$ ip -n ns1 link add dummy2ns1 type dummy
$ ip link set enp0s2 netns ns1
$ ip -n ns1 link set enp0s2 name dummy0
[ 100.858894] virtio_net virtio0 dummy0: renamed from enp0s2
$ ip link add dev4 type dummy
$ ip -n ns1 a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy1ns1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 16:63:4c:38:3e:ff brd ff:ff:ff:ff:ff:ff
3: dummy2ns1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether aa:9e:86:dd:6b:5d brd ff:ff:ff:ff:ff:ff
4: dummy0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 86:89:3f:86:61:29 brd ff:ff:ff:ff:ff:ff
4: dev4: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 5a:e1:4a:b6:ec:f8 brd ff:ff:ff:ff:ff:ff
$ ip netns del ns1
[ 158.717795] default_device_exit: failed to move dummy0 to init_net: -17
[ 158.719316] ------------[ cut here ]------------
[ 158.720591] kernel BUG at net/core/dev.c:9824!
[ 158.722260] invalid opcode: 0000 [#1] SMP KASAN PTI
[ 158.723728] CPU: 0 PID: 56 Comm: kworker/u2:1 Not tainted 5.3.0-rc1+ #18
[ 158.725422] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
[ 158.727508] Workqueue: netns cleanup_net
[ 158.728915] RIP: 0010:default_device_exit.cold+0x1d/0x1f
[ 158.730683] Code: 84 e8 18 c9 3e fe 0f 0b e9 70 90 ff ff e8 36 e4 52 fe 89 d9 4c 89 e2 48 c7 c6 80 d6 25 84 48 c7 c7 20 c0 25 84 e8 f4 c8 3e
[ 158.736854] RSP: 0018:ffff8880347e7b90 EFLAGS: 00010282
[ 158.738752] RAX: 000000000000003b RBX: 00000000ffffffef RCX: 0000000000000000
[ 158.741369] RDX: 0000000000000000 RSI: ffffffff8128013d RDI: ffffed10068fcf64
[ 158.743418] RBP: ffff888033550170 R08: 000000000000003b R09: fffffbfff0b94b9c
[ 158.745626] R10: fffffbfff0b94b9b R11: ffffffff85ca5cdf R12: ffff888032f28000
[ 158.748405] R13: dffffc0000000000 R14: ffff8880335501b8 R15: 1ffff110068fcf72
[ 158.750638] FS: 0000000000000000(0000) GS:ffff888036000000(0000) knlGS:0000000000000000
[ 158.752944] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 158.755245] CR2: 00007fe8b45d21d0 CR3: 00000000340b4005 CR4: 0000000000360ef0
[ 158.757654] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 158.760012] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 158.762758] Call Trace:
[ 158.763882] ? dev_change_net_namespace+0xbb0/0xbb0
[ 158.766148] ? devlink_nl_cmd_set_doit+0x520/0x520
[ 158.768034] ? dev_change_net_namespace+0xbb0/0xbb0
[ 158.769870] ops_exit_list.isra.0+0xa8/0x150
[ 158.771544] cleanup_net+0x446/0x8f0
[ 158.772945] ? unregister_pernet_operations+0x4a0/0x4a0
[ 158.775294] process_one_work+0xa1a/0x1740
[ 158.776896] ? pwq_dec_nr_in_flight+0x310/0x310
[ 158.779143] ? do_raw_spin_lock+0x11b/0x280
[ 158.780848] worker_thread+0x9e/0x1060
[ 158.782500] ? process_one_work+0x1740/0x1740
[ 158.784454] kthread+0x31b/0x420
[ 158.786082] ? __kthread_create_on_node+0x3f0/0x3f0
[ 158.788286] ret_from_fork+0x3a/0x50
[ 158.789871] ---[ end trace defd6c657c71f936 ]---
[ 158.792273] RIP: 0010:default_device_exit.cold+0x1d/0x1f
[ 158.795478] Code: 84 e8 18 c9 3e fe 0f 0b e9 70 90 ff ff e8 36 e4 52 fe 89 d9 4c 89 e2 48 c7 c6 80 d6 25 84 48 c7 c7 20 c0 25 84 e8 f4 c8 3e
[ 158.804854] RSP: 0018:ffff8880347e7b90 EFLAGS: 00010282
[ 158.807865] RAX: 000000000000003b RBX: 00000000ffffffef RCX: 0000000000000000
[ 158.811794] RDX: 0000000000000000 RSI: ffffffff8128013d RDI: ffffed10068fcf64
[ 158.816652] RBP: ffff888033550170 R08: 000000000000003b R09: fffffbfff0b94b9c
[ 158.820930] R10: fffffbfff0b94b9b R11: ffffffff85ca5cdf R12: ffff888032f28000
[ 158.825113] R13: dffffc0000000000 R14: ffff8880335501b8 R15: 1ffff110068fcf72
[ 158.829899] FS: 0000000000000000(0000) GS:ffff888036000000(0000) knlGS:0000000000000000
[ 158.834923] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 158.838164] CR2: 00007fe8b45d21d0 CR3: 00000000340b4005 CR4: 0000000000360ef0
[ 158.841917] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 158.845149] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Fix this by checking if a device with the same name exists in init_net
and fallback to original code - dev%d to allocate name - in case it does.
This was found using syzkaller.
Fixes: aca51397d014 ("netns: Fix arbitrary net_device-s corruptions on net_ns stop.")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/dev.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8652,6 +8652,8 @@ static void __net_exit default_device_ex
/* Push remaining network devices to init_net */
snprintf(fb_name, IFNAMSIZ, "dev%d", dev->ifindex);
+ if (__dev_get_by_name(&init_net, fb_name))
+ snprintf(fb_name, IFNAMSIZ, "dev%%d");
err = dev_change_net_namespace(dev, &init_net, fb_name);
if (err) {
pr_emerg("%s: failed to move %s to init_net: %d\n",
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 18/33] net/mlx5: Use reversed order when unregister devices
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 17/33] net: fix ifindex collision during namespace removal Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 19/33] net: phylink: Fix flow control for fixed-link Greg Kroah-Hartman
` (17 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Parav Pandit, Leon Romanovsky,
Mark Zhang, Saeed Mahameed
From: Mark Zhang <markz@mellanox.com>
[ Upstream commit 08aa5e7da6bce1a1963f63cf32c2e7ad434ad578 ]
When lag is active, which is controlled by the bonded mlx5e netdev, mlx5
interface unregestering must happen in the reverse order where rdma is
unregistered (unloaded) first, to guarantee all references to the lag
context in hardware is removed, then remove mlx5e netdev interface which
will cleanup the lag context from hardware.
Without this fix during destroy of LAG interface, we observed following
errors:
* mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed,
status bad parameter(0x3), syndrome (0xe4ac33)
* mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed,
status bad parameter(0x3), syndrome (0xa5aee8).
Fixes: a31208b1e11d ("net/mlx5_core: New init and exit flow for mlx5_core")
Reviewed-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Mark Zhang <markz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/dev.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/dev.c
@@ -307,7 +307,7 @@ void mlx5_unregister_device(struct mlx5_
struct mlx5_interface *intf;
mutex_lock(&mlx5_intf_mutex);
- list_for_each_entry(intf, &intf_list, list)
+ list_for_each_entry_reverse(intf, &intf_list, list)
mlx5_remove_device(intf, priv);
list_del(&priv->dev_list);
mutex_unlock(&mlx5_intf_mutex);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 19/33] net: phylink: Fix flow control for fixed-link
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 18/33] net/mlx5: Use reversed order when unregister devices Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 20/33] net: sched: Fix a possible null-pointer dereference in dequeue_func() Greg Kroah-Hartman
` (16 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, René van Dorst, Russell King,
David S. Miller
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1700 bytes --]
From: "René van Dorst" <opensource@vdorst.com>
[ Upstream commit 8aace4f3eba2a3ceb431e18683ea0e1ecbade5cd ]
In phylink_parse_fixedlink() the pl->link_config.advertising bits are AND
with pl->supported, pl->supported is zeroed and only the speed/duplex
modes and MII bits are set.
So pl->link_config.advertising always loses the flow control/pause bits.
By setting Pause and Asym_Pause bits in pl->supported, the flow control
work again when devicetree "pause" is set in fixes-link node and the MAC
advertise that is supports pause.
Results with this patch.
Legend:
- DT = 'Pause' is set in the fixed-link in devicetree.
- validate() = ‘Yes’ means phylink_set(mask, Pause) is set in the
validate().
- flow = results reported my link is Up line.
+-----+------------+-------+
| DT | validate() | flow |
+-----+------------+-------+
| Yes | Yes | rx/tx |
| No | Yes | off |
| Yes | No | off |
+-----+------------+-------+
Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: René van Dorst <opensource@vdorst.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/phy/phylink.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -203,6 +203,8 @@ static int phylink_parse_fixedlink(struc
__ETHTOOL_LINK_MODE_MASK_NBITS, true);
linkmode_zero(pl->supported);
phylink_set(pl->supported, MII);
+ phylink_set(pl->supported, Pause);
+ phylink_set(pl->supported, Asym_Pause);
if (s) {
__set_bit(s->bit, pl->supported);
} else {
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 20/33] net: sched: Fix a possible null-pointer dereference in dequeue_func()
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 19/33] net: phylink: Fix flow control for fixed-link Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 21/33] NFC: nfcmrvl: fix gpio-handling regression Greg Kroah-Hartman
` (15 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jia-Ju Bai, Jiri Pirko, David S. Miller
From: Jia-Ju Bai <baijiaju1990@gmail.com>
[ Upstream commit 051c7b39be4a91f6b7d8c4548444e4b850f1f56c ]
In dequeue_func(), there is an if statement on line 74 to check whether
skb is NULL:
if (skb)
When skb is NULL, it is used on line 77:
prefetch(&skb->end);
Thus, a possible null-pointer dereference may occur.
To fix this bug, skb->end is used when skb is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM")
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sched/sch_codel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/sched/sch_codel.c
+++ b/net/sched/sch_codel.c
@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(stru
struct Qdisc *sch = ctx;
struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
- if (skb)
+ if (skb) {
sch->qstats.backlog -= qdisc_pkt_len(skb);
-
- prefetch(&skb->end); /* we'll need skb_shinfo() */
+ prefetch(&skb->end); /* we'll need skb_shinfo() */
+ }
return skb;
}
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 21/33] NFC: nfcmrvl: fix gpio-handling regression
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 20/33] net: sched: Fix a possible null-pointer dereference in dequeue_func() Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 22/33] tipc: compat: allow tipc commands without arguments Greg Kroah-Hartman
` (14 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+cf35b76f35e068a1107f, Johan Hovold
From: Johan Hovold <johan@kernel.org>
[ Upstream commit c3953a3c2d3175d2f9f0304c9a1ba89e7743c5e4 ]
Fix two reset-gpio sanity checks which were never converted to use
gpio_is_valid(), and make sure to use -EINVAL to indicate a missing
reset line also for the UART-driver module parameter and for the USB
driver.
This specifically prevents the UART and USB drivers from incidentally
trying to request and use gpio 0, and also avoids triggering a WARN() in
gpio_to_desc() during probe when no valid reset line has been specified.
Fixes: e33a3f84f88f ("NFC: nfcmrvl: allow gpio 0 for reset signalling")
Reported-by: syzbot+cf35b76f35e068a1107f@syzkaller.appspotmail.com
Tested-by: syzbot+cf35b76f35e068a1107f@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nfc/nfcmrvl/main.c | 4 ++--
drivers/nfc/nfcmrvl/uart.c | 4 ++--
drivers/nfc/nfcmrvl/usb.c | 1 +
3 files changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/nfc/nfcmrvl/main.c
+++ b/drivers/nfc/nfcmrvl/main.c
@@ -244,7 +244,7 @@ void nfcmrvl_chip_reset(struct nfcmrvl_p
/* Reset possible fault of previous session */
clear_bit(NFCMRVL_PHY_ERROR, &priv->flags);
- if (priv->config.reset_n_io) {
+ if (gpio_is_valid(priv->config.reset_n_io)) {
nfc_info(priv->dev, "reset the chip\n");
gpio_set_value(priv->config.reset_n_io, 0);
usleep_range(5000, 10000);
@@ -255,7 +255,7 @@ void nfcmrvl_chip_reset(struct nfcmrvl_p
void nfcmrvl_chip_halt(struct nfcmrvl_private *priv)
{
- if (priv->config.reset_n_io)
+ if (gpio_is_valid(priv->config.reset_n_io))
gpio_set_value(priv->config.reset_n_io, 0);
}
--- a/drivers/nfc/nfcmrvl/uart.c
+++ b/drivers/nfc/nfcmrvl/uart.c
@@ -26,7 +26,7 @@
static unsigned int hci_muxed;
static unsigned int flow_control;
static unsigned int break_control;
-static unsigned int reset_n_io;
+static int reset_n_io = -EINVAL;
/*
** NFCMRVL NCI OPS
@@ -231,5 +231,5 @@ MODULE_PARM_DESC(break_control, "Tell if
module_param(hci_muxed, uint, 0);
MODULE_PARM_DESC(hci_muxed, "Tell if transport is muxed in HCI one.");
-module_param(reset_n_io, uint, 0);
+module_param(reset_n_io, int, 0);
MODULE_PARM_DESC(reset_n_io, "GPIO that is wired to RESET_N signal.");
--- a/drivers/nfc/nfcmrvl/usb.c
+++ b/drivers/nfc/nfcmrvl/usb.c
@@ -304,6 +304,7 @@ static int nfcmrvl_probe(struct usb_inte
/* No configuration for USB */
memset(&config, 0, sizeof(config));
+ config.reset_n_io = -EINVAL;
nfc_info(&udev->dev, "intf %p id %p\n", intf, id);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 22/33] tipc: compat: allow tipc commands without arguments
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 21/33] NFC: nfcmrvl: fix gpio-handling regression Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 23/33] compat_ioctl: pppoe: fix PPPOEIOCSFWD handling Greg Kroah-Hartman
` (13 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Taras Kondratiuk, Ying Xue, David S. Miller
From: Taras Kondratiuk <takondra@cisco.com>
[ Upstream commit 4da5f0018eef4c0de31675b670c80e82e13e99d1 ]
Commit 2753ca5d9009 ("tipc: fix uninit-value in tipc_nl_compat_doit")
broke older tipc tools that use compat interface (e.g. tipc-config from
tipcutils package):
% tipc-config -p
operation not supported
The commit started to reject TIPC netlink compat messages that do not
have attributes. It is too restrictive because some of such messages are
valid (they don't need any arguments):
% grep 'tx none' include/uapi/linux/tipc_config.h
#define TIPC_CMD_NOOP 0x0000 /* tx none, rx none */
#define TIPC_CMD_GET_MEDIA_NAMES 0x0002 /* tx none, rx media_name(s) */
#define TIPC_CMD_GET_BEARER_NAMES 0x0003 /* tx none, rx bearer_name(s) */
#define TIPC_CMD_SHOW_PORTS 0x0006 /* tx none, rx ultra_string */
#define TIPC_CMD_GET_REMOTE_MNG 0x4003 /* tx none, rx unsigned */
#define TIPC_CMD_GET_MAX_PORTS 0x4004 /* tx none, rx unsigned */
#define TIPC_CMD_GET_NETID 0x400B /* tx none, rx unsigned */
#define TIPC_CMD_NOT_NET_ADMIN 0xC001 /* tx none, rx none */
This patch relaxes the original fix and rejects messages without
arguments only if such arguments are expected by a command (reg_type is
non zero).
Fixes: 2753ca5d9009 ("tipc: fix uninit-value in tipc_nl_compat_doit")
Cc: stable@vger.kernel.org
Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/tipc/netlink_compat.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -55,6 +55,7 @@ struct tipc_nl_compat_msg {
int rep_type;
int rep_size;
int req_type;
+ int req_size;
struct net *net;
struct sk_buff *rep;
struct tlv_desc *req;
@@ -252,7 +253,8 @@ static int tipc_nl_compat_dumpit(struct
int err;
struct sk_buff *arg;
- if (msg->req_type && !TLV_CHECK_TYPE(msg->req, msg->req_type))
+ if (msg->req_type && (!msg->req_size ||
+ !TLV_CHECK_TYPE(msg->req, msg->req_type)))
return -EINVAL;
msg->rep = tipc_tlv_alloc(msg->rep_size);
@@ -345,7 +347,8 @@ static int tipc_nl_compat_doit(struct ti
{
int err;
- if (msg->req_type && !TLV_CHECK_TYPE(msg->req, msg->req_type))
+ if (msg->req_type && (!msg->req_size ||
+ !TLV_CHECK_TYPE(msg->req, msg->req_type)))
return -EINVAL;
err = __tipc_nl_compat_doit(cmd, msg);
@@ -1267,8 +1270,8 @@ static int tipc_nl_compat_recv(struct sk
goto send;
}
- len = nlmsg_attrlen(req_nlh, GENL_HDRLEN + TIPC_GENL_HDRLEN);
- if (!len || !TLV_OK(msg.req, len)) {
+ msg.req_size = nlmsg_attrlen(req_nlh, GENL_HDRLEN + TIPC_GENL_HDRLEN);
+ if (msg.req_size && !TLV_OK(msg.req, msg.req_size)) {
msg.rep = tipc_get_err_tlv(TIPC_CFG_NOT_SUPPORTED);
err = -EOPNOTSUPP;
goto send;
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 23/33] compat_ioctl: pppoe: fix PPPOEIOCSFWD handling
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 22/33] tipc: compat: allow tipc commands without arguments Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 24/33] net/mlx5e: Prevent encap flow counter update async to user query Greg Kroah-Hartman
` (12 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Guillaume Nault, Arnd Bergmann,
David S. Miller
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 055d88242a6046a1ceac3167290f054c72571cd9 ]
Support for handling the PPPOEIOCSFWD ioctl in compat mode was added in
linux-2.5.69 along with hundreds of other commands, but was always broken
sincen only the structure is compatible, but the command number is not,
due to the size being sizeof(size_t), or at first sizeof(sizeof((struct
sockaddr_pppox)), which is different on 64-bit architectures.
Guillaume Nault adds:
And the implementation was broken until 2016 (see 29e73269aa4d ("pppoe:
fix reference counting in PPPoE proxy")), and nobody ever noticed. I
should probably have removed this ioctl entirely instead of fixing it.
Clearly, it has never been used.
Fix it by adding a compat_ioctl handler for all pppoe variants that
translates the command number and then calls the regular ioctl function.
All other ioctl commands handled by pppoe are compatible between 32-bit
and 64-bit, and require compat_ptr() conversion.
This should apply to all stable kernels.
Acked-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ppp/pppoe.c | 3 +++
drivers/net/ppp/pppox.c | 13 +++++++++++++
drivers/net/ppp/pptp.c | 3 +++
fs/compat_ioctl.c | 3 ---
include/linux/if_pppox.h | 3 +++
net/l2tp/l2tp_ppp.c | 3 +++
6 files changed, 25 insertions(+), 3 deletions(-)
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -1137,6 +1137,9 @@ static const struct proto_ops pppoe_ops
.recvmsg = pppoe_recvmsg,
.mmap = sock_no_mmap,
.ioctl = pppox_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = pppox_compat_ioctl,
+#endif
};
static const struct pppox_proto pppoe_proto = {
--- a/drivers/net/ppp/pppox.c
+++ b/drivers/net/ppp/pppox.c
@@ -22,6 +22,7 @@
#include <linux/string.h>
#include <linux/module.h>
#include <linux/kernel.h>
+#include <linux/compat.h>
#include <linux/errno.h>
#include <linux/netdevice.h>
#include <linux/net.h>
@@ -103,6 +104,18 @@ int pppox_ioctl(struct socket *sock, uns
EXPORT_SYMBOL(pppox_ioctl);
+#ifdef CONFIG_COMPAT
+int pppox_compat_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
+{
+ if (cmd == PPPOEIOCSFWD32)
+ cmd = PPPOEIOCSFWD;
+
+ return pppox_ioctl(sock, cmd, (unsigned long)compat_ptr(arg));
+}
+
+EXPORT_SYMBOL(pppox_compat_ioctl);
+#endif
+
static int pppox_create(struct net *net, struct socket *sock, int protocol,
int kern)
{
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -636,6 +636,9 @@ static const struct proto_ops pptp_ops =
.recvmsg = sock_no_recvmsg,
.mmap = sock_no_mmap,
.ioctl = pppox_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = pppox_compat_ioctl,
+#endif
};
static const struct pppox_proto pppox_pptp_proto = {
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -1032,9 +1032,6 @@ COMPATIBLE_IOCTL(PPPIOCDISCONN)
COMPATIBLE_IOCTL(PPPIOCATTCHAN)
COMPATIBLE_IOCTL(PPPIOCGCHAN)
COMPATIBLE_IOCTL(PPPIOCGL2TPSTATS)
-/* PPPOX */
-COMPATIBLE_IOCTL(PPPOEIOCSFWD)
-COMPATIBLE_IOCTL(PPPOEIOCDFWD)
/* Big A */
/* sparc only */
/* Big Q for sound/OSS */
--- a/include/linux/if_pppox.h
+++ b/include/linux/if_pppox.h
@@ -84,6 +84,9 @@ extern int register_pppox_proto(int prot
extern void unregister_pppox_proto(int proto_num);
extern void pppox_unbind_sock(struct sock *sk);/* delete ppp-channel binding */
extern int pppox_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg);
+extern int pppox_compat_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg);
+
+#define PPPOEIOCSFWD32 _IOW(0xB1 ,0, compat_size_t)
/* PPPoX socket states */
enum {
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -1793,6 +1793,9 @@ static const struct proto_ops pppol2tp_o
.recvmsg = pppol2tp_recvmsg,
.mmap = sock_no_mmap,
.ioctl = pppox_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = pppox_compat_ioctl,
+#endif
};
static const struct pppox_proto pppol2tp_proto = {
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 24/33] net/mlx5e: Prevent encap flow counter update async to user query
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 23/33] compat_ioctl: pppoe: fix PPPOEIOCSFWD handling Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 25/33] tun: mark small packets as owned by the tap sock Greg Kroah-Hartman
` (11 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ariel Levkovich, Roi Dayan, Saeed Mahameed
From: Ariel Levkovich <lariel@mellanox.com>
[ Upstream commit 90bb769291161cf25a818d69cf608c181654473e ]
This patch prevents a race between user invoked cached counters
query and a neighbor last usage updater.
The cached flow counter stats can be queried by calling
"mlx5_fc_query_cached" which provides the number of bytes and
packets that passed via this flow since the last time this counter
was queried.
It does so by reducting the last saved stats from the current, cached
stats and then updating the last saved stats with the cached stats.
It also provide the lastuse value for that flow.
Since "mlx5e_tc_update_neigh_used_value" needs to retrieve the
last usage time of encapsulation flows, it calls the flow counter
query method periodically and async to user queries of the flow counter
using cls_flower.
This call is causing the driver to update the last reported bytes and
packets from the cache and therefore, future user queries of the flow
stats will return lower than expected number for bytes and packets
since the last saved stats in the driver was updated async to the last
saved stats in cls_flower.
This causes wrong stats presentation of encapsulation flows to user.
Since the neighbor usage updater only needs the lastuse stats from the
cached counter, the fix is to use a dedicated lastuse query call that
returns the lastuse value without synching between the cached stats and
the last saved stats.
Fixes: f6dfb4c3f216 ("net/mlx5e: Update neighbour 'used' state using HW flow rules counters")
Signed-off-by: Ariel Levkovich <lariel@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++--
drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c | 5 +++++
include/linux/mlx5/fs.h | 1 +
3 files changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -473,13 +473,13 @@ void mlx5e_tc_encap_flows_del(struct mlx
void mlx5e_tc_update_neigh_used_value(struct mlx5e_neigh_hash_entry *nhe)
{
struct mlx5e_neigh *m_neigh = &nhe->m_neigh;
- u64 bytes, packets, lastuse = 0;
struct mlx5e_tc_flow *flow;
struct mlx5e_encap_entry *e;
struct mlx5_fc *counter;
struct neigh_table *tbl;
bool neigh_used = false;
struct neighbour *n;
+ u64 lastuse;
if (m_neigh->family == AF_INET)
tbl = &arp_tbl;
@@ -496,7 +496,7 @@ void mlx5e_tc_update_neigh_used_value(st
list_for_each_entry(flow, &e->flows, encap) {
if (flow->flags & MLX5E_TC_FLOW_OFFLOADED) {
counter = mlx5_flow_rule_counter(flow->rule);
- mlx5_fc_query_cached(counter, &bytes, &packets, &lastuse);
+ lastuse = mlx5_fc_query_lastuse(counter);
if (time_after((unsigned long)lastuse, nhe->reported_lastuse)) {
neigh_used = true;
break;
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
@@ -312,6 +312,11 @@ void mlx5_cleanup_fc_stats(struct mlx5_c
}
}
+u64 mlx5_fc_query_lastuse(struct mlx5_fc *counter)
+{
+ return counter->cache.lastuse;
+}
+
void mlx5_fc_query_cached(struct mlx5_fc *counter,
u64 *bytes, u64 *packets, u64 *lastuse)
{
--- a/include/linux/mlx5/fs.h
+++ b/include/linux/mlx5/fs.h
@@ -164,6 +164,7 @@ int mlx5_modify_rule_destination(struct
struct mlx5_fc *mlx5_flow_rule_counter(struct mlx5_flow_handle *handler);
struct mlx5_fc *mlx5_fc_create(struct mlx5_core_dev *dev, bool aging);
void mlx5_fc_destroy(struct mlx5_core_dev *dev, struct mlx5_fc *counter);
+u64 mlx5_fc_query_lastuse(struct mlx5_fc *counter);
void mlx5_fc_query_cached(struct mlx5_fc *counter,
u64 *bytes, u64 *packets, u64 *lastuse);
int mlx5_fs_add_rx_underlay_qpn(struct mlx5_core_dev *dev, u32 underlay_qpn);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 25/33] tun: mark small packets as owned by the tap sock
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 24/33] net/mlx5e: Prevent encap flow counter update async to user query Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 26/33] mvpp2: refactor MTU change code Greg Kroah-Hartman
` (10 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexis Bauvin, Jason Wang, David S. Miller
From: Alexis Bauvin <abauvin@scaleway.com>
[ Upstream commit 4b663366246be1d1d4b1b8b01245b2e88ad9e706 ]
- v1 -> v2: Move skb_set_owner_w to __tun_build_skb to reduce patch size
Small packets going out of a tap device go through an optimized code
path that uses build_skb() rather than sock_alloc_send_pskb(). The
latter calls skb_set_owner_w(), but the small packet code path does not.
The net effect is that small packets are not owned by the userland
application's socket (e.g. QEMU), while large packets are.
This can be seen with a TCP session, where packets are not owned when
the window size is small enough (around PAGE_SIZE), while they are once
the window grows (note that this requires the host to support virtio
tso for the guest to offload segmentation).
All this leads to inconsistent behaviour in the kernel, especially on
netfilter modules that uses sk->socket (e.g. xt_owner).
Fixes: 66ccbc9c87c2 ("tap: use build_skb() for small packet")
Signed-off-by: Alexis Bauvin <abauvin@scaleway.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/tun.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1350,6 +1350,7 @@ static struct sk_buff *tun_build_skb(str
skb_reserve(skb, pad - delta);
skb_put(skb, len + delta);
+ skb_set_owner_w(skb, tfile->socket.sk);
get_page(alloc_frag->page);
alloc_frag->offset += buflen;
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 26/33] mvpp2: refactor MTU change code
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 25/33] tun: mark small packets as owned by the tap sock Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 27/33] bnx2x: Disable multi-cos feature Greg Kroah-Hartman
` (9 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Matteo Croce, David S. Miller
From: Matteo Croce <mcroce@redhat.com>
[ Upstream commit 230bd958c2c846ee292aa38bc6b006296c24ca01 ]
The MTU change code can call napi_disable() with the device already down,
leading to a deadlock. Also, lot of code is duplicated unnecessarily.
Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/marvell/mvpp2.c | 41 +++++++++++------------------------
1 file changed, 13 insertions(+), 28 deletions(-)
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6952,6 +6952,7 @@ log_error:
static int mvpp2_change_mtu(struct net_device *dev, int mtu)
{
struct mvpp2_port *port = netdev_priv(dev);
+ bool running = netif_running(dev);
int err;
if (!IS_ALIGNED(MVPP2_RX_PKT_SIZE(mtu), 8)) {
@@ -6960,40 +6961,24 @@ static int mvpp2_change_mtu(struct net_d
mtu = ALIGN(MVPP2_RX_PKT_SIZE(mtu), 8);
}
- if (!netif_running(dev)) {
- err = mvpp2_bm_update_mtu(dev, mtu);
- if (!err) {
- port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
- return 0;
- }
+ if (running)
+ mvpp2_stop_dev(port);
+ err = mvpp2_bm_update_mtu(dev, mtu);
+ if (err) {
+ netdev_err(dev, "failed to change MTU\n");
/* Reconfigure BM to the original MTU */
- err = mvpp2_bm_update_mtu(dev, dev->mtu);
- if (err)
- goto log_error;
+ mvpp2_bm_update_mtu(dev, dev->mtu);
+ } else {
+ port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
}
- mvpp2_stop_dev(port);
-
- err = mvpp2_bm_update_mtu(dev, mtu);
- if (!err) {
- port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
- goto out_start;
+ if (running) {
+ mvpp2_start_dev(port);
+ mvpp2_egress_enable(port);
+ mvpp2_ingress_enable(port);
}
- /* Reconfigure BM to the original MTU */
- err = mvpp2_bm_update_mtu(dev, dev->mtu);
- if (err)
- goto log_error;
-
-out_start:
- mvpp2_start_dev(port);
- mvpp2_egress_enable(port);
- mvpp2_ingress_enable(port);
-
- return 0;
-log_error:
- netdev_err(dev, "failed to change MTU\n");
return err;
}
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 27/33] bnx2x: Disable multi-cos feature.
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 26/33] mvpp2: refactor MTU change code Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 28/33] cgroup: Call cgroup_release() before __exit_signal() Greg Kroah-Hartman
` (8 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sudarsana Reddy Kalluru,
Manish Chopra, David S. Miller
From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
[ Upstream commit d1f0b5dce8fda09a7f5f04c1878f181d548e42f5 ]
Commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") which enabled multi-cos
feature after prolonged time in driver added some regression causing
numerous issues (sudden reboots, tx timeout etc.) reported by customers.
We plan to backout this commit and submit proper fix once we have root
cause of issues reported with this feature enabled.
Fixes: 3968d38917eb ("bnx2x: Fix Multi-Cos.")
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -1934,7 +1934,7 @@ u16 bnx2x_select_queue(struct net_device
}
/* select a non-FCoE queue */
- return fallback(dev, skb) % (BNX2X_NUM_ETH_QUEUES(bp) * bp->max_cos);
+ return fallback(dev, skb) % (BNX2X_NUM_ETH_QUEUES(bp));
}
void bnx2x_set_num_queues(struct bnx2x *bp)
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 28/33] cgroup: Call cgroup_release() before __exit_signal()
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 27/33] bnx2x: Disable multi-cos feature Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 29/33] cgroup: Implement css_task_iter_skip() Greg Kroah-Hartman
` (7 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tejun Heo, Oleg Nesterov
From: Tejun Heo <tj@kernel.org>
commit 6b115bf58e6f013ca75e7115aabcbd56c20ff31d upstream.
cgroup_release() calls cgroup_subsys->release() which is used by the
pids controller to uncharge its pid. We want to use it to manage
iteration of dying tasks which requires putting it before
__unhash_process(). Move cgroup_release() above __exit_signal().
While this makes it uncharge before the pid is freed, pid is RCU freed
anyway and the window is very narrow.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/exit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -193,6 +193,7 @@ repeat:
rcu_read_unlock();
proc_flush_task(p);
+ cgroup_release(p);
write_lock_irq(&tasklist_lock);
ptrace_release_task(p);
@@ -218,7 +219,6 @@ repeat:
}
write_unlock_irq(&tasklist_lock);
- cgroup_release(p);
release_thread(p);
call_rcu(&p->rcu, delayed_put_task_struct);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 29/33] cgroup: Implement css_task_iter_skip()
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 28/33] cgroup: Call cgroup_release() before __exit_signal() Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 30/33] cgroup: Include dying leaders with live threads in PROCS iterations Greg Kroah-Hartman
` (6 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tejun Heo, Oleg Nesterov
From: Tejun Heo <tj@kernel.org>
commit b636fd38dc40113f853337a7d2a6885ad23b8811 upstream.
When a task is moved out of a cset, task iterators pointing to the
task are advanced using the normal css_task_iter_advance() call. This
is fine but we'll be tracking dying tasks on csets and thus moving
tasks from cset->tasks to (to be added) cset->dying_tasks. When we
remove a task from cset->tasks, if we advance the iterators, they may
move over to the next cset before we had the chance to add the task
back on the dying list, which can allow the task to escape iteration.
This patch separates out skipping from advancing. Skipping only moves
the affected iterators to the next pointer rather than fully advancing
it and the following advancing will recognize that the cursor has
already been moved forward and do the rest of advancing. This ensures
that when a task moves from one list to another in its cset, as long
as it moves in the right direction, it's always visible to iteration.
This doesn't cause any visible behavior changes.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/cgroup.h | 3 ++
kernel/cgroup/cgroup.c | 60 +++++++++++++++++++++++++++++--------------------
2 files changed, 39 insertions(+), 24 deletions(-)
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -42,6 +42,9 @@
/* walk all threaded css_sets in the domain */
#define CSS_TASK_ITER_THREADED (1U << 1)
+/* internal flags */
+#define CSS_TASK_ITER_SKIPPED (1U << 16)
+
/* a css_task_iter should be treated as an opaque object */
struct css_task_iter {
struct cgroup_subsys *ss;
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -204,7 +204,8 @@ static struct cftype cgroup_base_files[]
static int cgroup_apply_control(struct cgroup *cgrp);
static void cgroup_finalize_control(struct cgroup *cgrp, int ret);
-static void css_task_iter_advance(struct css_task_iter *it);
+static void css_task_iter_skip(struct css_task_iter *it,
+ struct task_struct *task);
static int cgroup_destroy_locked(struct cgroup *cgrp);
static struct cgroup_subsys_state *css_create(struct cgroup *cgrp,
struct cgroup_subsys *ss);
@@ -737,6 +738,21 @@ static void css_set_update_populated(str
cgroup_update_populated(link->cgrp, populated);
}
+/*
+ * @task is leaving, advance task iterators which are pointing to it so
+ * that they can resume at the next position. Advancing an iterator might
+ * remove it from the list, use safe walk. See css_task_iter_skip() for
+ * details.
+ */
+static void css_set_skip_task_iters(struct css_set *cset,
+ struct task_struct *task)
+{
+ struct css_task_iter *it, *pos;
+
+ list_for_each_entry_safe(it, pos, &cset->task_iters, iters_node)
+ css_task_iter_skip(it, task);
+}
+
/**
* css_set_move_task - move a task from one css_set to another
* @task: task being moved
@@ -762,22 +778,9 @@ static void css_set_move_task(struct tas
css_set_update_populated(to_cset, true);
if (from_cset) {
- struct css_task_iter *it, *pos;
-
WARN_ON_ONCE(list_empty(&task->cg_list));
- /*
- * @task is leaving, advance task iterators which are
- * pointing to it so that they can resume at the next
- * position. Advancing an iterator might remove it from
- * the list, use safe walk. See css_task_iter_advance*()
- * for details.
- */
- list_for_each_entry_safe(it, pos, &from_cset->task_iters,
- iters_node)
- if (it->task_pos == &task->cg_list)
- css_task_iter_advance(it);
-
+ css_set_skip_task_iters(from_cset, task);
list_del_init(&task->cg_list);
if (!css_set_populated(from_cset))
css_set_update_populated(from_cset, false);
@@ -4077,10 +4080,19 @@ static void css_task_iter_advance_css_se
list_add(&it->iters_node, &cset->task_iters);
}
-static void css_task_iter_advance(struct css_task_iter *it)
+static void css_task_iter_skip(struct css_task_iter *it,
+ struct task_struct *task)
{
- struct list_head *next;
+ lockdep_assert_held(&css_set_lock);
+
+ if (it->task_pos == &task->cg_list) {
+ it->task_pos = it->task_pos->next;
+ it->flags |= CSS_TASK_ITER_SKIPPED;
+ }
+}
+static void css_task_iter_advance(struct css_task_iter *it)
+{
lockdep_assert_held(&css_set_lock);
repeat:
if (it->task_pos) {
@@ -4089,15 +4101,15 @@ repeat:
* consumed first and then ->mg_tasks. After ->mg_tasks,
* we move onto the next cset.
*/
- next = it->task_pos->next;
-
- if (next == it->tasks_head)
- next = it->mg_tasks_head->next;
+ if (it->flags & CSS_TASK_ITER_SKIPPED)
+ it->flags &= ~CSS_TASK_ITER_SKIPPED;
+ else
+ it->task_pos = it->task_pos->next;
- if (next == it->mg_tasks_head)
+ if (it->task_pos == it->tasks_head)
+ it->task_pos = it->mg_tasks_head->next;
+ if (it->task_pos == it->mg_tasks_head)
css_task_iter_advance_css_set(it);
- else
- it->task_pos = next;
} else {
/* called from start, proceed to the first cset */
css_task_iter_advance_css_set(it);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 30/33] cgroup: Include dying leaders with live threads in PROCS iterations
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 29/33] cgroup: Implement css_task_iter_skip() Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 31/33] cgroup: css_task_iter_skip()d iterators must be advanced before accessed Greg Kroah-Hartman
` (5 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tejun Heo, Oleg Nesterov, Topi Miettinen
From: Tejun Heo <tj@kernel.org>
commit c03cd7738a83b13739f00546166969342c8ff014 upstream.
CSS_TASK_ITER_PROCS currently iterates live group leaders; however,
this means that a process with dying leader and live threads will be
skipped. IOW, cgroup.procs might be empty while cgroup.threads isn't,
which is confusing to say the least.
Fix it by making cset track dying tasks and include dying leaders with
live threads in PROCS iteration.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Topi Miettinen <toiwoton@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/cgroup-defs.h | 1 +
include/linux/cgroup.h | 1 +
kernel/cgroup/cgroup.c | 44 +++++++++++++++++++++++++++++++++++++-------
3 files changed, 39 insertions(+), 7 deletions(-)
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -201,6 +201,7 @@ struct css_set {
*/
struct list_head tasks;
struct list_head mg_tasks;
+ struct list_head dying_tasks;
/* all css_task_iters currently walking this cset */
struct list_head task_iters;
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -59,6 +59,7 @@ struct css_task_iter {
struct list_head *task_pos;
struct list_head *tasks_head;
struct list_head *mg_tasks_head;
+ struct list_head *dying_tasks_head;
struct css_set *cur_cset;
struct css_set *cur_dcset;
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -643,6 +643,7 @@ struct css_set init_css_set = {
.dom_cset = &init_css_set,
.tasks = LIST_HEAD_INIT(init_css_set.tasks),
.mg_tasks = LIST_HEAD_INIT(init_css_set.mg_tasks),
+ .dying_tasks = LIST_HEAD_INIT(init_css_set.dying_tasks),
.task_iters = LIST_HEAD_INIT(init_css_set.task_iters),
.threaded_csets = LIST_HEAD_INIT(init_css_set.threaded_csets),
.cgrp_links = LIST_HEAD_INIT(init_css_set.cgrp_links),
@@ -1107,6 +1108,7 @@ static struct css_set *find_css_set(stru
cset->dom_cset = cset;
INIT_LIST_HEAD(&cset->tasks);
INIT_LIST_HEAD(&cset->mg_tasks);
+ INIT_LIST_HEAD(&cset->dying_tasks);
INIT_LIST_HEAD(&cset->task_iters);
INIT_LIST_HEAD(&cset->threaded_csets);
INIT_HLIST_NODE(&cset->hlist);
@@ -4046,15 +4048,18 @@ static void css_task_iter_advance_css_se
it->task_pos = NULL;
return;
}
- } while (!css_set_populated(cset));
+ } while (!css_set_populated(cset) && !list_empty(&cset->dying_tasks));
if (!list_empty(&cset->tasks))
it->task_pos = cset->tasks.next;
- else
+ else if (!list_empty(&cset->mg_tasks))
it->task_pos = cset->mg_tasks.next;
+ else
+ it->task_pos = cset->dying_tasks.next;
it->tasks_head = &cset->tasks;
it->mg_tasks_head = &cset->mg_tasks;
+ it->dying_tasks_head = &cset->dying_tasks;
/*
* We don't keep css_sets locked across iteration steps and thus
@@ -4093,6 +4098,8 @@ static void css_task_iter_skip(struct cs
static void css_task_iter_advance(struct css_task_iter *it)
{
+ struct task_struct *task;
+
lockdep_assert_held(&css_set_lock);
repeat:
if (it->task_pos) {
@@ -4109,17 +4116,32 @@ repeat:
if (it->task_pos == it->tasks_head)
it->task_pos = it->mg_tasks_head->next;
if (it->task_pos == it->mg_tasks_head)
+ it->task_pos = it->dying_tasks_head->next;
+ if (it->task_pos == it->dying_tasks_head)
css_task_iter_advance_css_set(it);
} else {
/* called from start, proceed to the first cset */
css_task_iter_advance_css_set(it);
}
- /* if PROCS, skip over tasks which aren't group leaders */
- if ((it->flags & CSS_TASK_ITER_PROCS) && it->task_pos &&
- !thread_group_leader(list_entry(it->task_pos, struct task_struct,
- cg_list)))
- goto repeat;
+ if (!it->task_pos)
+ return;
+
+ task = list_entry(it->task_pos, struct task_struct, cg_list);
+
+ if (it->flags & CSS_TASK_ITER_PROCS) {
+ /* if PROCS, skip over tasks which aren't group leaders */
+ if (!thread_group_leader(task))
+ goto repeat;
+
+ /* and dying leaders w/o live member threads */
+ if (!atomic_read(&task->signal->live))
+ goto repeat;
+ } else {
+ /* skip all dying ones */
+ if (task->flags & PF_EXITING)
+ goto repeat;
+ }
}
/**
@@ -5552,6 +5574,7 @@ void cgroup_exit(struct task_struct *tsk
if (!list_empty(&tsk->cg_list)) {
spin_lock_irq(&css_set_lock);
css_set_move_task(tsk, cset, NULL, false);
+ list_add_tail(&tsk->cg_list, &cset->dying_tasks);
cset->nr_tasks--;
spin_unlock_irq(&css_set_lock);
} else {
@@ -5572,6 +5595,13 @@ void cgroup_release(struct task_struct *
do_each_subsys_mask(ss, ssid, have_release_callback) {
ss->release(task);
} while_each_subsys_mask();
+
+ if (use_task_css_set_links) {
+ spin_lock_irq(&css_set_lock);
+ css_set_skip_task_iters(task_css_set(task), task);
+ list_del_init(&task->cg_list);
+ spin_unlock_irq(&css_set_lock);
+ }
}
void cgroup_free(struct task_struct *task)
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 31/33] cgroup: css_task_iter_skip()d iterators must be advanced before accessed
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 30/33] cgroup: Include dying leaders with live threads in PROCS iterations Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 32/33] cgroup: Fix css_task_iter_advance_css_set() cset skip condition Greg Kroah-Hartman
` (4 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tejun Heo
From: Tejun Heo <tj@kernel.org>
commit cee0c33c546a93957a52ae9ab6bebadbee765ec5 upstream.
b636fd38dc40 ("cgroup: Implement css_task_iter_skip()") introduced
css_task_iter_skip() which is used to fix task iterations skipping
dying threadgroup leaders with live threads. Skipping is implemented
as a subportion of full advancing but css_task_iter_next() forgot to
fully advance a skipped iterator before determining the next task to
visit causing it to return invalid task pointers.
Fix it by making css_task_iter_next() fully advance the iterator if it
has been skipped since the previous iteration.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: syzbot
Link: http://lkml.kernel.org/r/00000000000097025d058a7fd785@google.com
Fixes: b636fd38dc40 ("cgroup: Implement css_task_iter_skip()")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup/cgroup.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -4197,6 +4197,10 @@ struct task_struct *css_task_iter_next(s
spin_lock_irq(&css_set_lock);
+ /* @it may be half-advanced by skips, finish advancing */
+ if (it->flags & CSS_TASK_ITER_SKIPPED)
+ css_task_iter_advance(it);
+
if (it->task_pos) {
it->cur_task = list_entry(it->task_pos, struct task_struct,
cg_list);
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 32/33] cgroup: Fix css_task_iter_advance_css_set() cset skip condition
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 31/33] cgroup: css_task_iter_skip()d iterators must be advanced before accessed Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-08 19:05 ` [PATCH 4.14 33/33] spi: bcm2835: Fix 3-wire mode if DMA is enabled Greg Kroah-Hartman
` (3 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tejun Heo, syzbot+d4bba5ccd4f9a2a68681
From: Tejun Heo <tj@kernel.org>
commit c596687a008b579c503afb7a64fcacc7270fae9e upstream.
While adding handling for dying task group leaders c03cd7738a83
("cgroup: Include dying leaders with live threads in PROCS
iterations") added an inverted cset skip condition to
css_task_iter_advance_css_set(). It should skip cset if it's
completely empty but was incorrectly testing for the inverse condition
for the dying_tasks list. Fix it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: c03cd7738a83 ("cgroup: Include dying leaders with live threads in PROCS iterations")
Reported-by: syzbot+d4bba5ccd4f9a2a68681@syzkaller.appspotmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -4048,7 +4048,7 @@ static void css_task_iter_advance_css_se
it->task_pos = NULL;
return;
}
- } while (!css_set_populated(cset) && !list_empty(&cset->dying_tasks));
+ } while (!css_set_populated(cset) && list_empty(&cset->dying_tasks));
if (!list_empty(&cset->tasks))
it->task_pos = cset->tasks.next;
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH 4.14 33/33] spi: bcm2835: Fix 3-wire mode if DMA is enabled
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 32/33] cgroup: Fix css_task_iter_advance_css_set() cset skip condition Greg Kroah-Hartman
@ 2019-08-08 19:05 ` Greg Kroah-Hartman
2019-08-09 0:41 ` [PATCH 4.14 00/33] 4.14.138-stable review shuah
` (2 subsequent siblings)
35 siblings, 0 replies; 52+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-08 19:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nuno Sá,
Lukas Wunner, Martin Sperl, Stefan Wahren, Mark Brown
From: Lukas Wunner <lukas@wunner.de>
commit 8d8bef50365847134b51c1ec46786bc2873e4e47 upstream.
Commit 6935224da248 ("spi: bcm2835: enable support of 3-wire mode")
added 3-wire support to the BCM2835 SPI driver by setting the REN bit
(Read Enable) in the CS register when receiving data. The REN bit puts
the transmitter in high-impedance state. The driver recognizes that
data is to be received by checking whether the rx_buf of a transfer is
non-NULL.
Commit 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers
meeting certain conditions") subsequently broke 3-wire support because
it set the SPI_MASTER_MUST_RX flag which causes spi_map_msg() to replace
rx_buf with a dummy buffer if it is NULL. As a result, rx_buf is
*always* non-NULL if DMA is enabled.
Reinstate 3-wire support by not only checking whether rx_buf is non-NULL,
but also checking that it is not the dummy buffer.
Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions")
Reported-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.2+
Cc: Martin Sperl <kernel@martin.sperl.org>
Acked-by: Stefan Wahren <wahrenst@gmx.net>
Link: https://lore.kernel.org/r/328318841455e505370ef8ecad97b646c033dc8a.1562148527.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm2835.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -554,7 +554,8 @@ static int bcm2835_spi_transfer_one(stru
bcm2835_wr(bs, BCM2835_SPI_CLK, cdiv);
/* handle all the 3-wire mode */
- if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf))
+ if (spi->mode & SPI_3WIRE && tfr->rx_buf &&
+ tfr->rx_buf != master->dummy_rx)
cs |= BCM2835_SPI_CS_REN;
else
cs &= ~BCM2835_SPI_CS_REN;
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH 4.14 00/33] 4.14.138-stable review
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2019-08-08 19:05 ` [PATCH 4.14 33/33] spi: bcm2835: Fix 3-wire mode if DMA is enabled Greg Kroah-Hartman
@ 2019-08-09 0:41 ` shuah
2019-08-09 3:16 ` Naresh Kamboju
2019-08-09 15:36 ` Guenter Roeck
35 siblings, 0 replies; 52+ messages in thread
From: shuah @ 2019-08-09 0:41 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 8/8/19 1:05 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.138 release.
> There are 33 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 10 Aug 2019 07:03:19 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.138-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH 4.14 00/33] 4.14.138-stable review
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2019-08-09 0:41 ` [PATCH 4.14 00/33] 4.14.138-stable review shuah
@ 2019-08-09 3:16 ` Naresh Kamboju
2019-08-09 15:36 ` Guenter Roeck
35 siblings, 0 replies; 52+ messages in thread
From: Naresh Kamboju @ 2019-08-09 3:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Fri, 9 Aug 2019 at 00:41, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.14.138 release.
> There are 33 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 10 Aug 2019 07:03:19 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.138-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.14.138-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 4ec3ef9505a33da8c993347fc2e178b46356bb92
git describe: v4.14.136-94-g4ec3ef9505a3
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.136-94-g4ec3ef9505a3
No regressions (compared to build v4.14.136)
No fixes (compared to build v4.14.136)
Ran 23722 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-containers-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH 4.14 00/33] 4.14.138-stable review
2019-08-08 19:05 [PATCH 4.14 00/33] 4.14.138-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2019-08-09 3:16 ` Naresh Kamboju
@ 2019-08-09 15:36 ` Guenter Roeck
35 siblings, 0 replies; 52+ messages in thread
From: Guenter Roeck @ 2019-08-09 15:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Thu, Aug 08, 2019 at 09:05:07PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.138 release.
> There are 33 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 10 Aug 2019 07:03:19 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 172 pass: 172 fail: 0
Qemu test results:
total: 372 pass: 372 fail: 0
Guenter
^ permalink raw reply [flat|nested] 52+ messages in thread