* [PATCH AUTOSEL 4.9 15/30] ISDN: hfcsusb: checking idx of ep configuration
From: Sasha Levin @ 2019-07-26 13:44 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phong Tran, syzbot+8750abbc3a46ef47d509, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190726134432.12993-1-sashal@kernel.org>
From: Phong Tran <tranmanphong@gmail.com>
[ Upstream commit f384e62a82ba5d85408405fdd6aeff89354deaa9 ]
The syzbot test with random endpoint address which made the idx is
overflow in the table of endpoint configuations.
this adds the checking for fixing the error report from
syzbot
KASAN: stack-out-of-bounds Read in hfcsusb_probe [1]
The patch tested by syzbot [2]
Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
[1]:
https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb913522
[2]:
https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 114f3bcba1b0..c60c7998af17 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1963,6 +1963,9 @@ hfcsusb_probe(struct usb_interface *intf, const struct usb_device_id *id)
/* get endpoint base */
idx = ((ep_addr & 0x7f) - 1) * 2;
+ if (idx > 15)
+ return -EIO;
+
if (ep_addr & 0x80)
idx++;
attr = ep->desc.bmAttributes;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 20/37] be2net: Signal that the device cannot transmit during reconfiguration
From: Sasha Levin @ 2019-07-26 13:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Benjamin Poirier, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190726134332.12626-1-sashal@kernel.org>
From: Benjamin Poirier <bpoirier@suse.com>
[ Upstream commit 7429c6c0d9cb086d8e79f0d2a48ae14851d2115e ]
While changing the number of interrupt channels, be2net stops adapter
operation (including netif_tx_disable()) but it doesn't signal that it
cannot transmit. This may lead dev_watchdog() to falsely trigger during
that time.
Add the missing call to netif_carrier_off(), following the pattern used in
many other drivers. netif_carrier_on() is already taken care of in
be_open().
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 39f399741647..cabeb1790db7 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4600,8 +4600,12 @@ int be_update_queues(struct be_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int status;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* device cannot transmit now, avoid dev_watchdog timeouts */
+ netif_carrier_off(netdev);
+
be_close(netdev);
+ }
be_cancel_worker(adapter);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 19/37] ISDN: hfcsusb: checking idx of ep configuration
From: Sasha Levin @ 2019-07-26 13:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phong Tran, syzbot+8750abbc3a46ef47d509, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190726134332.12626-1-sashal@kernel.org>
From: Phong Tran <tranmanphong@gmail.com>
[ Upstream commit f384e62a82ba5d85408405fdd6aeff89354deaa9 ]
The syzbot test with random endpoint address which made the idx is
overflow in the table of endpoint configuations.
this adds the checking for fixing the error report from
syzbot
KASAN: stack-out-of-bounds Read in hfcsusb_probe [1]
The patch tested by syzbot [2]
Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
[1]:
https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb913522
[2]:
https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 17cc879ad2bb..35983c7c3137 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1963,6 +1963,9 @@ hfcsusb_probe(struct usb_interface *intf, const struct usb_device_id *id)
/* get endpoint base */
idx = ((ep_addr & 0x7f) - 1) * 2;
+ if (idx > 15)
+ return -EIO;
+
if (ep_addr & 0x80)
idx++;
attr = ep->desc.bmAttributes;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] vhost: disable metadata prefetch optimization
From: Michael S. Tsirkin @ 2019-07-26 13:52 UTC (permalink / raw)
To: Jason Wang; +Cc: linux-kernel, kvm, virtualization, netdev
In-Reply-To: <ccba99c1-7708-3e55-6fc9-7775415c77a8@redhat.com>
On Fri, Jul 26, 2019 at 07:57:25PM +0800, Jason Wang wrote:
>
> On 2019/7/26 下午7:51, Michael S. Tsirkin wrote:
> > This seems to cause guest and host memory corruption.
> > Disable for now until we get a better handle on that.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > I put this in linux-next, we'll re-enable if we can fix
> > the outstanding issues in a short order.
>
>
> Btw, is this more suitable to e.g revert the
> 842aa64eddacd23adc6ecdbc69cb2030bec47122
Yes I did that too.
> and let syzbot fuzz more on the
> current code?
Current metadata direct access code is known to corrupt guest and host
memory - I don't feel we need more fuzzing.
>
> I think we won't accept that patch eventually, so I suspect what syzbot
> reports today is a false positives.
Today's reports are real, it's a bug in my patch. But I reverted it -
the below is an easier way to make sure at least linux-next is stable
for everyone.
>
> Thanks
>
>
> >
> > drivers/vhost/vhost.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> > index 819296332913..42a8c2a13ab1 100644
> > --- a/drivers/vhost/vhost.h
> > +++ b/drivers/vhost/vhost.h
> > @@ -96,7 +96,7 @@ struct vhost_uaddr {
> > };
> > #if defined(CONFIG_MMU_NOTIFIER) && ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 0
> > -#define VHOST_ARCH_CAN_ACCEL_UACCESS 1
> > +#define VHOST_ARCH_CAN_ACCEL_UACCESS 0
> > #else
> > #define VHOST_ARCH_CAN_ACCEL_UACCESS 0
> > #endif
^ permalink raw reply
* [PATCH AUTOSEL 4.19 41/47] mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed
From: Sasha Levin @ 2019-07-26 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Petr Machata, Alex Veber, Ido Schimmel, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190726134210.12156-1-sashal@kernel.org>
From: Petr Machata <petrm@mellanox.com>
[ Upstream commit dedfde2fe1c4ccf27179fcb234e2112d065c39bb ]
Spectrum systems use DSCP rewrite map to update DSCP field in egressing
packets to correspond to priority that the packet has. Whether rewriting
will take place is determined at the point when the packet ingresses the
switch: if the port is in Trust L3 mode, packet priority is determined from
the DSCP map at the port, and DSCP rewrite will happen. If the port is in
Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
rewrite will happen.
The driver determines the port trust mode based on whether any DSCP
prioritization rules are in effect at given port. If there are any, trust
level is L3, otherwise it's L2. When the last DSCP rule is removed, the
port is switched to trust L2. Under that scenario, if DSCP of a packet
should be rewritten, it should be rewritten to 0.
However, when switching to Trust L2, the driver neglects to also update the
DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
egressing through this port, if they have the right priority, will have
their DSCP set according to this rule.
Fix by first configuring the rewrite map, and only then switching to trust
L2 and bailing out.
Fixes: b2b1dab6884e ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Reported-by: Alex Veber <alexve@mellanox.com>
Tested-by: Alex Veber <alexve@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
index b25048c6c761..21296fa7f7fb 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
@@ -408,14 +408,6 @@ static int mlxsw_sp_port_dcb_app_update(struct mlxsw_sp_port *mlxsw_sp_port)
have_dscp = mlxsw_sp_port_dcb_app_prio_dscp_map(mlxsw_sp_port,
&prio_map);
- if (!have_dscp) {
- err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
- MLXSW_REG_QPTS_TRUST_STATE_PCP);
- if (err)
- netdev_err(mlxsw_sp_port->dev, "Couldn't switch to trust L2\n");
- return err;
- }
-
mlxsw_sp_port_dcb_app_dscp_prio_map(mlxsw_sp_port, default_prio,
&dscp_map);
err = mlxsw_sp_port_dcb_app_update_qpdpm(mlxsw_sp_port,
@@ -432,6 +424,14 @@ static int mlxsw_sp_port_dcb_app_update(struct mlxsw_sp_port *mlxsw_sp_port)
return err;
}
+ if (!have_dscp) {
+ err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
+ MLXSW_REG_QPTS_TRUST_STATE_PCP);
+ if (err)
+ netdev_err(mlxsw_sp_port->dev, "Couldn't switch to trust L2\n");
+ return err;
+ }
+
err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
MLXSW_REG_QPTS_TRUST_STATE_DSCP);
if (err) {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 26/47] ISDN: hfcsusb: checking idx of ep configuration
From: Sasha Levin @ 2019-07-26 13:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phong Tran, syzbot+8750abbc3a46ef47d509, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190726134210.12156-1-sashal@kernel.org>
From: Phong Tran <tranmanphong@gmail.com>
[ Upstream commit f384e62a82ba5d85408405fdd6aeff89354deaa9 ]
The syzbot test with random endpoint address which made the idx is
overflow in the table of endpoint configuations.
this adds the checking for fixing the error report from
syzbot
KASAN: stack-out-of-bounds Read in hfcsusb_probe [1]
The patch tested by syzbot [2]
Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
[1]:
https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb913522
[2]:
https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 6d05946b445e..060dc7fd66c1 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1967,6 +1967,9 @@ hfcsusb_probe(struct usb_interface *intf, const struct usb_device_id *id)
/* get endpoint base */
idx = ((ep_addr & 0x7f) - 1) * 2;
+ if (idx > 15)
+ return -EIO;
+
if (ep_addr & 0x80)
idx++;
attr = ep->desc.bmAttributes;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 27/47] be2net: Signal that the device cannot transmit during reconfiguration
From: Sasha Levin @ 2019-07-26 13:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Benjamin Poirier, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190726134210.12156-1-sashal@kernel.org>
From: Benjamin Poirier <bpoirier@suse.com>
[ Upstream commit 7429c6c0d9cb086d8e79f0d2a48ae14851d2115e ]
While changing the number of interrupt channels, be2net stops adapter
operation (including netif_tx_disable()) but it doesn't signal that it
cannot transmit. This may lead dev_watchdog() to falsely trigger during
that time.
Add the missing call to netif_carrier_off(), following the pattern used in
many other drivers. netif_carrier_on() is already taken care of in
be_open().
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index bff74752cef1..3fe6a28027fe 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4700,8 +4700,12 @@ int be_update_queues(struct be_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int status;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* device cannot transmit now, avoid dev_watchdog timeouts */
+ netif_carrier_off(netdev);
+
be_close(netdev);
+ }
be_cancel_worker(adapter);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 80/85] bnxt_en: Fix VNIC accounting when enabling aRFS on 57500 chips.
From: Sasha Levin @ 2019-07-26 13:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Michael Chan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Michael Chan <michael.chan@broadcom.com>
[ Upstream commit 9b3d15e6b05e0b916be5fbd915f90300a403098b ]
Unlike legacy chips, 57500 chips don't need additional VNIC resources
for aRFS/ntuple. Fix the code accordingly so that we don't reserve
and allocate additional VNICs on 57500 chips. Without this patch,
the driver is failing to initialize when it tries to allocate extra
VNICs.
Fixes: ac33906c67e2 ("bnxt_en: Add support for aRFS on 57500 chips.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index f758b2e0591f..9a2a0d24d20d 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3022,7 +3022,7 @@ static int bnxt_alloc_vnics(struct bnxt *bp)
int num_vnics = 1;
#ifdef CONFIG_RFS_ACCEL
- if (bp->flags & BNXT_FLAG_RFS)
+ if ((bp->flags & (BNXT_FLAG_RFS | BNXT_FLAG_CHIP_P5)) == BNXT_FLAG_RFS)
num_vnics += bp->rx_nr_rings;
#endif
@@ -7124,6 +7124,9 @@ static int bnxt_alloc_rfs_vnics(struct bnxt *bp)
#ifdef CONFIG_RFS_ACCEL
int i, rc = 0;
+ if (bp->flags & BNXT_FLAG_CHIP_P5)
+ return 0;
+
for (i = 0; i < bp->rx_nr_rings; i++) {
struct bnxt_vnic_info *vnic;
u16 vnic_id = i + 1;
@@ -9587,7 +9590,7 @@ int bnxt_check_rings(struct bnxt *bp, int tx, int rx, bool sh, int tcs,
return -ENOMEM;
vnics = 1;
- if (bp->flags & BNXT_FLAG_RFS)
+ if ((bp->flags & (BNXT_FLAG_RFS | BNXT_FLAG_CHIP_P5)) == BNXT_FLAG_RFS)
vnics += rx_rings;
if (bp->flags & BNXT_FLAG_AGG_RINGS)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 71/85] mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed
From: Sasha Levin @ 2019-07-26 13:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Petr Machata, Alex Veber, Ido Schimmel, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Petr Machata <petrm@mellanox.com>
[ Upstream commit dedfde2fe1c4ccf27179fcb234e2112d065c39bb ]
Spectrum systems use DSCP rewrite map to update DSCP field in egressing
packets to correspond to priority that the packet has. Whether rewriting
will take place is determined at the point when the packet ingresses the
switch: if the port is in Trust L3 mode, packet priority is determined from
the DSCP map at the port, and DSCP rewrite will happen. If the port is in
Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
rewrite will happen.
The driver determines the port trust mode based on whether any DSCP
prioritization rules are in effect at given port. If there are any, trust
level is L3, otherwise it's L2. When the last DSCP rule is removed, the
port is switched to trust L2. Under that scenario, if DSCP of a packet
should be rewritten, it should be rewritten to 0.
However, when switching to Trust L2, the driver neglects to also update the
DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
egressing through this port, if they have the right priority, will have
their DSCP set according to this rule.
Fix by first configuring the rewrite map, and only then switching to trust
L2 and bailing out.
Fixes: b2b1dab6884e ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Reported-by: Alex Veber <alexve@mellanox.com>
Tested-by: Alex Veber <alexve@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
index b25048c6c761..21296fa7f7fb 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
@@ -408,14 +408,6 @@ static int mlxsw_sp_port_dcb_app_update(struct mlxsw_sp_port *mlxsw_sp_port)
have_dscp = mlxsw_sp_port_dcb_app_prio_dscp_map(mlxsw_sp_port,
&prio_map);
- if (!have_dscp) {
- err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
- MLXSW_REG_QPTS_TRUST_STATE_PCP);
- if (err)
- netdev_err(mlxsw_sp_port->dev, "Couldn't switch to trust L2\n");
- return err;
- }
-
mlxsw_sp_port_dcb_app_dscp_prio_map(mlxsw_sp_port, default_prio,
&dscp_map);
err = mlxsw_sp_port_dcb_app_update_qpdpm(mlxsw_sp_port,
@@ -432,6 +424,14 @@ static int mlxsw_sp_port_dcb_app_update(struct mlxsw_sp_port *mlxsw_sp_port)
return err;
}
+ if (!have_dscp) {
+ err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
+ MLXSW_REG_QPTS_TRUST_STATE_PCP);
+ if (err)
+ netdev_err(mlxsw_sp_port->dev, "Couldn't switch to trust L2\n");
+ return err;
+ }
+
err = mlxsw_sp_port_dcb_toggle_trust(mlxsw_sp_port,
MLXSW_REG_QPTS_TRUST_STATE_DSCP);
if (err) {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 49/85] be2net: Signal that the device cannot transmit during reconfiguration
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Benjamin Poirier, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Benjamin Poirier <bpoirier@suse.com>
[ Upstream commit 7429c6c0d9cb086d8e79f0d2a48ae14851d2115e ]
While changing the number of interrupt channels, be2net stops adapter
operation (including netif_tx_disable()) but it doesn't signal that it
cannot transmit. This may lead dev_watchdog() to falsely trigger during
that time.
Add the missing call to netif_carrier_off(), following the pattern used in
many other drivers. netif_carrier_on() is already taken care of in
be_open().
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 82015c8a5ed7..b7a246b33599 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4697,8 +4697,12 @@ int be_update_queues(struct be_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int status;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* device cannot transmit now, avoid dev_watchdog timeouts */
+ netif_carrier_off(netdev);
+
be_close(netdev);
+ }
be_cancel_worker(adapter);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 47/85] bpf: fix BTF verifier size resolution logic
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrii Nakryiko, Martin KaFai Lau, Daniel Borkmann, Sasha Levin,
netdev, bpf
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Andrii Nakryiko <andriin@fb.com>
[ Upstream commit 1acc5d5c5832da9a98b22374a8fae08ffe31b3f8 ]
BTF verifier has a size resolution bug which in some circumstances leads to
invalid size resolution for, e.g., TYPEDEF modifier. This happens if we have
[1] PTR -> [2] TYPEDEF -> [3] ARRAY, in which case due to being in pointer
context ARRAY size won't be resolved (because for pointer it doesn't matter, so
it's a sink in pointer context), but it will be permanently remembered as zero
for TYPEDEF and TYPEDEF will be marked as RESOLVED. Eventually ARRAY size will
be resolved correctly, but TYPEDEF resolved_size won't be updated anymore.
This, subsequently, will lead to erroneous map creation failure, if that
TYPEDEF is specified as either key or value, as key_size/value_size won't
correspond to resolved size of TYPEDEF (kernel will believe it's zero).
Note, that if BTF was ordered as [1] ARRAY <- [2] TYPEDEF <- [3] PTR, this
won't be a problem, as by the time we get to TYPEDEF, ARRAY's size is already
calculated and stored.
This bug manifests itself in rejecting BTF-defined maps that use array
typedef as a value type:
typedef int array_t[16];
struct {
__uint(type, BPF_MAP_TYPE_ARRAY);
__type(value, array_t); /* i.e., array_t *value; */
} test_map SEC(".maps");
The fix consists on not relying on modifier's resolved_size and instead using
modifier's resolved_id (type ID for "concrete" type to which modifier
eventually resolves) and doing size determination for that resolved type. This
allow to preserve existing "early DFS termination" logic for PTR or
STRUCT_OR_ARRAY contexts, but still do correct size determination for modifier
types.
Fixes: eb3f595dab40 ("bpf: btf: Validate type reference")
Cc: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/btf.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index cad09858a5f2..8614102971da 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1073,11 +1073,18 @@ const struct btf_type *btf_type_id_size(const struct btf *btf,
!btf_type_is_var(size_type)))
return NULL;
- size = btf->resolved_sizes[size_type_id];
size_type_id = btf->resolved_ids[size_type_id];
size_type = btf_type_by_id(btf, size_type_id);
if (btf_type_nosize_or_null(size_type))
return NULL;
+ else if (btf_type_has_size(size_type))
+ size = size_type->size;
+ else if (btf_type_is_array(size_type))
+ size = btf->resolved_sizes[size_type_id];
+ else if (btf_type_is_ptr(size_type))
+ size = sizeof(void *);
+ else
+ return NULL;
}
*type_id = size_type_id;
@@ -1602,7 +1609,6 @@ static int btf_modifier_resolve(struct btf_verifier_env *env,
const struct btf_type *next_type;
u32 next_type_id = t->type;
struct btf *btf = env->btf;
- u32 next_type_size = 0;
next_type = btf_type_by_id(btf, next_type_id);
if (!next_type || btf_type_is_resolve_source_only(next_type)) {
@@ -1620,7 +1626,7 @@ static int btf_modifier_resolve(struct btf_verifier_env *env,
* save us a few type-following when we use it later (e.g. in
* pretty print).
*/
- if (!btf_type_id_size(btf, &next_type_id, &next_type_size)) {
+ if (!btf_type_id_size(btf, &next_type_id, NULL)) {
if (env_type_is_resolved(env, next_type_id))
next_type = btf_type_id_resolve(btf, &next_type_id);
@@ -1633,7 +1639,7 @@ static int btf_modifier_resolve(struct btf_verifier_env *env,
}
}
- env_stack_pop_resolved(env, next_type_id, next_type_size);
+ env_stack_pop_resolved(env, next_type_id, 0);
return 0;
}
@@ -1645,7 +1651,6 @@ static int btf_var_resolve(struct btf_verifier_env *env,
const struct btf_type *t = v->t;
u32 next_type_id = t->type;
struct btf *btf = env->btf;
- u32 next_type_size;
next_type = btf_type_by_id(btf, next_type_id);
if (!next_type || btf_type_is_resolve_source_only(next_type)) {
@@ -1675,12 +1680,12 @@ static int btf_var_resolve(struct btf_verifier_env *env,
* forward types or similar that would resolve to size of
* zero is allowed.
*/
- if (!btf_type_id_size(btf, &next_type_id, &next_type_size)) {
+ if (!btf_type_id_size(btf, &next_type_id, NULL)) {
btf_verifier_log_type(env, v->t, "Invalid type_id");
return -EINVAL;
}
- env_stack_pop_resolved(env, next_type_id, next_type_size);
+ env_stack_pop_resolved(env, next_type_id, 0);
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 48/85] libbpf: fix another GCC8 warning for strncpy
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrii Nakryiko, Magnus Karlsson, Alexei Starovoitov, Sasha Levin,
netdev, bpf
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Andrii Nakryiko <andriin@fb.com>
[ Upstream commit 763ff0e7d9c72e7094b31e7fb84a859be9325635 ]
Similar issue was fixed in cdfc7f888c2a ("libbpf: fix GCC8 warning for
strncpy") already. This one was missed. Fixing now.
Cc: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/xsk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 38667b62f1fe..aa37005209aa 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -561,7 +561,8 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const char *ifname,
err = -errno;
goto out_socket;
}
- strncpy(xsk->ifname, ifname, IFNAMSIZ);
+ strncpy(xsk->ifname, ifname, IFNAMSIZ - 1);
+ xsk->ifname[IFNAMSIZ - 1] = '\0';
err = xsk_set_xdp_socket_config(&xsk->config, usr_config);
if (err)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 45/85] ISDN: hfcsusb: checking idx of ep configuration
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phong Tran, syzbot+8750abbc3a46ef47d509, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Phong Tran <tranmanphong@gmail.com>
[ Upstream commit f384e62a82ba5d85408405fdd6aeff89354deaa9 ]
The syzbot test with random endpoint address which made the idx is
overflow in the table of endpoint configuations.
this adds the checking for fixing the error report from
syzbot
KASAN: stack-out-of-bounds Read in hfcsusb_probe [1]
The patch tested by syzbot [2]
Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
[1]:
https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb913522
[2]:
https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 4c99739b937e..0e224232f746 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1955,6 +1955,9 @@ hfcsusb_probe(struct usb_interface *intf, const struct usb_device_id *id)
/* get endpoint base */
idx = ((ep_addr & 0x7f) - 1) * 2;
+ if (idx > 15)
+ return -EIO;
+
if (ep_addr & 0x80)
idx++;
attr = ep->desc.bmAttributes;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 39/85] selftests/bpf: do not ignore clang failures
From: Sasha Levin @ 2019-07-26 13:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ilya Leoshkevich, Andrii Nakryiko, Daniel Borkmann, Sasha Levin,
linux-kselftest, netdev, bpf, clang-built-linux
In-Reply-To: <20190726133936.11177-1-sashal@kernel.org>
From: Ilya Leoshkevich <iii@linux.ibm.com>
[ Upstream commit 9cae4ace80ef39005da106fbb89c952b27d7b89e ]
When compiling an eBPF prog fails, make still returns 0, because
failing clang command's output is piped to llc and therefore its
exit status is ignored.
When clang fails, pipe the string "clang failed" to llc. This will make
llc fail with an informative error message. This solution was chosen
over using pipefail, having separate targets or getting rid of llc
invocation due to its simplicity.
In addition, pull Kbuild.include in order to get .DELETE_ON_ERROR target,
which would cause partial .o files to be removed.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/bpf/Makefile | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index e36356e2377e..e375f399b7a6 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+include ../../../../scripts/Kbuild.include
LIBDIR := ../../../lib
BPFDIR := $(LIBDIR)/bpf
@@ -185,8 +186,8 @@ $(ALU32_BUILD_DIR)/test_progs_32: prog_tests/*.c
$(ALU32_BUILD_DIR)/%.o: progs/%.c $(ALU32_BUILD_DIR) \
$(ALU32_BUILD_DIR)/test_progs_32
- $(CLANG) $(CLANG_FLAGS) \
- -O2 -target bpf -emit-llvm -c $< -o - | \
+ ($(CLANG) $(CLANG_FLAGS) -O2 -target bpf -emit-llvm -c $< -o - || \
+ echo "clang failed") | \
$(LLC) -march=bpf -mattr=+alu32 -mcpu=$(CPU) $(LLC_FLAGS) \
-filetype=obj -o $@
ifeq ($(DWARF2BTF),y)
@@ -197,16 +198,16 @@ endif
# Have one program compiled without "-target bpf" to test whether libbpf loads
# it successfully
$(OUTPUT)/test_xdp.o: progs/test_xdp.c
- $(CLANG) $(CLANG_FLAGS) \
- -O2 -emit-llvm -c $< -o - | \
+ ($(CLANG) $(CLANG_FLAGS) -O2 -emit-llvm -c $< -o - || \
+ echo "clang failed") | \
$(LLC) -march=bpf -mcpu=$(CPU) $(LLC_FLAGS) -filetype=obj -o $@
ifeq ($(DWARF2BTF),y)
$(BTF_PAHOLE) -J $@
endif
$(OUTPUT)/%.o: progs/%.c
- $(CLANG) $(CLANG_FLAGS) \
- -O2 -target bpf -emit-llvm -c $< -o - | \
+ ($(CLANG) $(CLANG_FLAGS) -O2 -target bpf -emit-llvm -c $< -o - || \
+ echo "clang failed") | \
$(LLC) -march=bpf -mcpu=$(CPU) $(LLC_FLAGS) -filetype=obj -o $@
ifeq ($(DWARF2BTF),y)
$(BTF_PAHOLE) -J $@
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net/mlx5e: Fix zero table prio set by user.
From: Marcelo Ricardo Leitner @ 2019-07-26 14:01 UTC (permalink / raw)
To: wenxu
Cc: Or Gerlitz, Saeed Mahameed, Roi Dayan, Mark Bloch, Paul Blakey,
pablo, netdev@vger.kernel.org
In-Reply-To: <692b090f-c19e-aa8b-796e-17999ac79df1@ucloud.cn>
On Fri, Jul 26, 2019 at 08:39:43PM +0800, wenxu wrote:
>
> 在 2019/7/26 20:19, Or Gerlitz 写道:
> > On Fri, Jul 26, 2019 at 12:24 AM Saeed Mahameed <saeedm@mellanox.com> wrote:
> >> On Thu, 2019-07-25 at 19:24 +0800, wenxu@ucloud.cn wrote:
> >>> From: wenxu <wenxu@ucloud.cn>
> >>>
> >>> The flow_cls_common_offload prio is zero
> >>>
> >>> It leads the invalid table prio in hw.
> >>>
> >>> Error: Could not process rule: Invalid argument
> >>>
> >>> kernel log:
> >>> mlx5_core 0000:81:00.0: E-Switch: Failed to create FDB Table err -22
> >>> (table prio: 65535, level: 0, size: 4194304)
> >>>
> >>> table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
> >>> should check (chain * FDB_MAX_PRIO) + prio is not 0
> >>>
> >>> Signed-off-by: wenxu <wenxu@ucloud.cn>
> >>> ---
> >>> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git
> >>> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> index 089ae4d..64ca90f 100644
> >>> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> >>> @@ -970,7 +970,9 @@ static int esw_add_fdb_miss_rule(struct
> >> this piece of code isn't in this function, weird how it got to the
> >> diff, patch applies correctly though !
> >>
> >>> mlx5_eswitch *esw)
> >>> flags |= (MLX5_FLOW_TABLE_TUNNEL_EN_REFORMAT |
> >>> MLX5_FLOW_TABLE_TUNNEL_EN_DECAP);
> >>>
> >>> - table_prio = (chain * FDB_MAX_PRIO) + prio - 1;
> >>> + table_prio = (chain * FDB_MAX_PRIO) + prio;
> >>> + if (table_prio)
> >>> + table_prio = table_prio - 1;
> >>>
> >> This is black magic, even before this fix.
> >> this -1 seems to be needed in order to call
> >> create_next_size_table(table_prio) with the previous "table prio" ?
> >> (table_prio - 1) ?
> >>
> >> The whole thing looks wrong to me since when prio is 0 and chain is 0,
> >> there is not such thing table_prio - 1.
> >>
> >> mlnx eswitch guys in the cc, please advise.
> > basically, prio 0 is not something we ever get in the driver, since if
> > user space
> > specifies 0, the kernel generates some random non-zero prio, and we support
> > only prios 1-16 -- Wenxu -- what do you run to get this error?
> >
> >
> I run offload with nfatbles(but not tc), there is no prio for each rule.
>
> prio of flow_cls_common_offload init as 0.
>
> static void nft_flow_offload_common_init(struct flow_cls_common_offload *common,
>
> __be16 proto,
> struct netlink_ext_ack *extack)
> {
> common->protocol = proto;
> common->extack = extack;
> }
>
>
> flow_cls_common_offload
Note that on
[PATCH net-next] netfilter: nf_table_offload: Fix zero prio of flow_cls_common_offload
I asked Pablo on how nftables should behave on this situation.
It's the same issue as in the patch above but being fixed at a
different level.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-26 14:11 UTC (permalink / raw)
To: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Maxime Coquelin, linux-tegra, Giuseppe Cavallaro, Robin Murphy,
David S . Miller
In-Reply-To: <BYAPR12MB3269B4A401E4DA10A07515C7D3C10@BYAPR12MB3269.namprd12.prod.outlook.com>
On 25/07/2019 16:12, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/25/2019, 15:25:59 (UTC+00:00)
>
>>
>> On 25/07/2019 14:26, Jose Abreu wrote:
>>
>> ...
>>
>>> Well, I wasn't expecting that :/
>>>
>>> Per documentation of barriers I think we should set descriptor fields
>>> and then barrier and finally ownership to HW so that remaining fields
>>> are coherent before owner is set.
>>>
>>> Anyway, can you also add a dma_rmb() after the call to
>>> stmmac_rx_status() ?
>>
>> Yes. I removed the debug print added the barrier, but that did not help.
>
> So, I was finally able to setup NFS using your replicated setup and I
> can't see the issue :(
>
> The only difference I have from yours is that I'm using TCP in NFS
> whilst you (I believe from the logs), use UDP.
So I tried TCP by setting the kernel boot params to 'nfsvers=3' and
'proto=tcp' and this does appear to be more stable, but not 100% stable.
It still appears to fail in the same place about 50% of the time.
> You do have flow control active right ? And your HW FIFO size is >= 4k ?
How can I verify if flow control is active?
The documentation for this device indicates a max transfer size of 16kB
for TX and RX.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] brcmsmac: remove three set but not used variables
From: YueHaibing @ 2019-07-26 14:15 UTC (permalink / raw)
To: kvalo, arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng
Cc: linux-kernel, netdev, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c: In function 'brcms_c_set_gmode':
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5257:7: warning: variable 'preamble_restrict' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5256:6: warning: variable 'preamble' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5251:7: warning: variable 'shortslot_restrict' set but not used [-Wunused-but-set-variable]
They are never used so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
index 7d4e8f5..080e829 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
@@ -5248,15 +5248,7 @@ int brcms_c_set_gmode(struct brcms_c_info *wlc, u8 gmode, bool config)
/* Default to 54g Auto */
/* Advertise and use shortslot (-1/0/1 Auto/Off/On) */
s8 shortslot = BRCMS_SHORTSLOT_AUTO;
- bool shortslot_restrict = false; /* Restrict association to stations
- * that support shortslot
- */
bool ofdm_basic = false; /* Make 6, 12, and 24 basic rates */
- /* Advertise and use short preambles (-1/0/1 Auto/Off/On) */
- int preamble = BRCMS_PLCP_LONG;
- bool preamble_restrict = false; /* Restrict association to stations
- * that support short preambles
- */
struct brcms_band *band;
/* if N-support is enabled, allow Gmode set as long as requested
@@ -5297,16 +5289,11 @@ int brcms_c_set_gmode(struct brcms_c_info *wlc, u8 gmode, bool config)
case GMODE_ONLY:
ofdm_basic = true;
- preamble = BRCMS_PLCP_SHORT;
- preamble_restrict = true;
break;
case GMODE_PERFORMANCE:
shortslot = BRCMS_SHORTSLOT_ON;
- shortslot_restrict = true;
ofdm_basic = true;
- preamble = BRCMS_PLCP_SHORT;
- preamble_restrict = true;
break;
default:
--
2.7.4
^ permalink raw reply related
* [PATCH] net: rds: Fix possible null-pointer dereferences in rds_rdma_cm_event_handler_cmn()
From: Jia-Ju Bai @ 2019-07-26 14:17 UTC (permalink / raw)
To: santosh.shilimkar, davem
Cc: netdev, linux-rdma, rds-devel, linux-kernel, Jia-Ju Bai
In rds_rdma_cm_event_handler_cmn(), there are some if statements to
check whether conn is NULL, such as on lines 65, 96 and 112.
But conn is not checked before being used on line 108:
trans->cm_connect_complete(conn, event);
and on lines 140-143:
rdsdebug("DISCONNECT event - dropping connection "
"%pI6c->%pI6c\n", &conn->c_laddr,
&conn->c_faddr);
rds_conn_drop(conn);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, conn is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/rds/rdma_transport.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/rds/rdma_transport.c b/net/rds/rdma_transport.c
index ff74c4bbb9fc..9986d6065c4d 100644
--- a/net/rds/rdma_transport.c
+++ b/net/rds/rdma_transport.c
@@ -105,7 +105,8 @@ static int rds_rdma_cm_event_handler_cmn(struct rdma_cm_id *cm_id,
break;
case RDMA_CM_EVENT_ESTABLISHED:
- trans->cm_connect_complete(conn, event);
+ if (conn)
+ trans->cm_connect_complete(conn, event);
break;
case RDMA_CM_EVENT_REJECTED:
@@ -137,6 +138,8 @@ static int rds_rdma_cm_event_handler_cmn(struct rdma_cm_id *cm_id,
break;
case RDMA_CM_EVENT_DISCONNECTED:
+ if (!conn)
+ break;
rdsdebug("DISCONNECT event - dropping connection "
"%pI6c->%pI6c\n", &conn->c_laddr,
&conn->c_faddr);
--
2.17.0
^ permalink raw reply related
* [PATCH] iwlwifi: mvm: fix old-style declaration
From: YueHaibing @ 2019-07-26 14:18 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
kvalo, sara.sharon
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
There expect the 'static' keyword to come first in a
declaration, and we get a warning for this with "make W=1":
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:427:1: warning:
'static' is not at beginning of declaration [-Wold-style-declaration]
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:434:1: warning:
'static' is not at beginning of declaration [-Wold-style-declaration]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 55cd49c..6ed0c49 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -424,14 +424,14 @@ int iwl_mvm_init_fw_regd(struct iwl_mvm *mvm)
return ret;
}
-const static u8 he_if_types_ext_capa_sta[] = {
+static const u8 he_if_types_ext_capa_sta[] = {
[0] = WLAN_EXT_CAPA1_EXT_CHANNEL_SWITCHING,
[2] = WLAN_EXT_CAPA3_MULTI_BSSID_SUPPORT,
[7] = WLAN_EXT_CAPA8_OPMODE_NOTIF,
[9] = WLAN_EXT_CAPA10_TWT_REQUESTER_SUPPORT,
};
-const static struct wiphy_iftype_ext_capab he_iftypes_ext_capa[] = {
+static const struct wiphy_iftype_ext_capab he_iftypes_ext_capa[] = {
{
.iftype = NL80211_IFTYPE_STATION,
.extended_capabilities = he_if_types_ext_capa_sta,
--
2.7.4
^ permalink raw reply related
* [PATCH] rtw88: pci: remove set but not used variable 'ip_sel'
From: YueHaibing @ 2019-07-26 14:20 UTC (permalink / raw)
To: yhchuang, kvalo; +Cc: linux-kernel, netdev, linux-wireless, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtw88/pci.c: In function 'rtw_pci_phy_cfg':
drivers/net/wireless/realtek/rtw88/pci.c:993:6: warning:
variable 'ip_sel' set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/realtek/rtw88/pci.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 23dd06a..c562515 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -990,7 +990,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
u16 cut;
u16 value;
u16 offset;
- u16 ip_sel;
int i;
cut = BIT(0) << rtwdev->hal.cut_version;
@@ -1003,7 +1002,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
break;
offset = para->offset;
value = para->value;
- ip_sel = para->ip_sel;
if (para->ip_sel == RTW_IP_SEL_PHY)
rtw_mdio_write(rtwdev, offset, value, true);
else
@@ -1018,7 +1016,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
break;
offset = para->offset;
value = para->value;
- ip_sel = para->ip_sel;
if (para->ip_sel == RTW_IP_SEL_PHY)
rtw_mdio_write(rtwdev, offset, value, false);
else
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: tipc: Fix a possible null-pointer dereference in tipc_publ_purge()
From: Ying Xue @ 2019-07-26 14:10 UTC (permalink / raw)
To: Jia-Ju Bai, jon.maloy, davem; +Cc: netdev, tipc-discussion, linux-kernel
In-Reply-To: <20190725092021.15855-1-baijiaju1990@gmail.com>
On 7/25/19 5:20 PM, Jia-Ju Bai wrote:
> In tipc_publ_purge(), there is an if statement on 215 to
> check whether p is NULL:
> if (p)
>
> When p is NULL, it is used on line 226:
> kfree_rcu(p, rcu);
>
> Thus, a possible null-pointer dereference may occur.
>
> To fix this bug, p is checked before being used.
>
> This bug is found by a static analysis tool STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> net/tipc/name_distr.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
> index 44abc8e9c990..241ed2274473 100644
> --- a/net/tipc/name_distr.c
> +++ b/net/tipc/name_distr.c
> @@ -223,7 +223,8 @@ static void tipc_publ_purge(struct net *net, struct publication *publ, u32 addr)
> publ->key);
> }
>
> - kfree_rcu(p, rcu);
> + if (p)
No, I don't think so because kfree_rcu() will internally check if "p"
pointer is NULL or not.
> + kfree_rcu(p, rcu);
> }
>
> /**
>
^ permalink raw reply
* Re: [PATCH] isdn/gigaset: check endpoint null in gigaset_probe
From: Paul Bolle @ 2019-07-26 14:22 UTC (permalink / raw)
To: Phong Tran, isdn, gregkh
Cc: gigaset307x-common, netdev, linux-kernel, linux-kernel-mentees,
syzbot+35b1c403a14f5c89eba7
In-Reply-To: <20190726133528.11063-1-tranmanphong@gmail.com>
Phong Tran schreef op vr 26-07-2019 om 20:35 [+0700]:
> This fixed the potential reference NULL pointer while using variable
> endpoint.
>
> Reported-by: syzbot+35b1c403a14f5c89eba7@syzkaller.appspotmail.com
> Tested by syzbot:
> https://groups.google.com/d/msg/syzkaller-bugs/wnHG8eRNWEA/Qn2HhjNdBgAJ
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> ---
> drivers/isdn/gigaset/usb-gigaset.c | 9 +++++++++
This is now drivers/staging/isdn/gigaset/usb-gigaset.c.
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/isdn/gigaset/usb-gigaset.c b/drivers/isdn/gigaset/usb-gigaset.c
> index 1b9b43659bdf..2e011f3db59e 100644
> --- a/drivers/isdn/gigaset/usb-gigaset.c
> +++ b/drivers/isdn/gigaset/usb-gigaset.c
> @@ -703,6 +703,10 @@ static int gigaset_probe(struct usb_interface *interface,
> usb_set_intfdata(interface, cs);
>
> endpoint = &hostif->endpoint[0].desc;
> + if (!endpoint) {
> + dev_err(cs->dev, "Couldn't get control endpoint\n");
> + return -ENODEV;
> + }
When can this happen? Is this one of those bugs that one can only trigger with
a specially crafted (evil) usb device?
> buffer_size = le16_to_cpu(endpoint->wMaxPacketSize);
> ucs->bulk_out_size = buffer_size;
> @@ -722,6 +726,11 @@ static int gigaset_probe(struct usb_interface *interface,
> }
>
> endpoint = &hostif->endpoint[1].desc;
> + if (!endpoint) {
> + dev_err(cs->dev, "Endpoint not available\n");
> + retval = -ENODEV;
> + goto error;
> + }
>
> ucs->busy = 0;
>
Please note that I'm very close to getting cut off from the ISDN network, so
the chances of being able to testi this on a live system are getting small.
Thanks,
Paul Bolle
^ permalink raw reply
* Re: [PATCH] net: rds: Fix possible null-pointer dereferences in rds_rdma_cm_event_handler_cmn()
From: santosh.shilimkar @ 2019-07-26 14:24 UTC (permalink / raw)
To: Jia-Ju Bai, davem; +Cc: netdev, linux-rdma, rds-devel, linux-kernel
In-Reply-To: <20190726141705.9585-1-baijiaju1990@gmail.com>
On 7/26/19 7:17 AM, Jia-Ju Bai wrote:
> In rds_rdma_cm_event_handler_cmn(), there are some if statements to
> check whether conn is NULL, such as on lines 65, 96 and 112.
> But conn is not checked before being used on line 108:
> trans->cm_connect_complete(conn, event);
> and on lines 140-143:
> rdsdebug("DISCONNECT event - dropping connection "
> "%pI6c->%pI6c\n", &conn->c_laddr,
> &conn->c_faddr);
> rds_conn_drop(conn);
>
> Thus, possible null-pointer dereferences may occur.
>
> To fix these bugs, conn is checked before being used.
>
> These bugs are found by a static analysis tool STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
That's possible. Looks good.
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH net] mvpp2: refactor MTU change code
From: Matteo Croce @ 2019-07-26 14:26 UTC (permalink / raw)
To: Antoine Tenart
Cc: netdev, Maxime Chevallier, Marcin Wojtas, Stefan Chulski, LKML
In-Reply-To: <20190726125053.GA5031@kwain>
On Fri, Jul 26, 2019 at 2:50 PM Antoine Tenart
<antoine.tenart@bootlin.com> wrote:
>
> Hi Matteo,
>
> On Fri, Jul 26, 2019 at 01:19:31AM +0200, Matteo Croce wrote:
> > 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.
> >
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
>
> As this is a fix sent to net, you could add a Fixes: tag.
>
> Otherwise this looks good,
> Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
>
> Thanks!
> Antoine
>
> > ---
> > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 41 ++++++-------------
> > 1 file changed, 13 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index 2f7286bd203b..60eb98f99571 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -3612,6 +3612,7 @@ static int mvpp2_set_mac_address(struct net_device *dev, void *p)
> > 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)) {
> > @@ -3620,40 +3621,24 @@ static int mvpp2_change_mtu(struct net_device *dev, int mtu)
> > 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;
> > - }
> > -
> > - /* Reconfigure BM to the original MTU */
> > - err = mvpp2_bm_update_mtu(dev, dev->mtu);
> > - if (err)
> > - goto log_error;
> > - }
> > -
> > - mvpp2_stop_dev(port);
> > + if (running)
> > + mvpp2_stop_dev(port);
> >
> > err = mvpp2_bm_update_mtu(dev, mtu);
> > - if (!err) {
> > + if (err) {
> > + netdev_err(dev, "failed to change MTU\n");
> > + /* Reconfigure BM to the original MTU */
> > + mvpp2_bm_update_mtu(dev, dev->mtu);
> > + } else {
> > port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
> > - goto out_start;
> > }
> >
> > - /* 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);
> > + if (running) {
> > + 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;
> > }
> >
> > --
> > 2.21.0
> >
>
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
It seems to me that the fixes tag should refer to the driver inclusion:
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375
network unit")
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [PATCH net-next] mvpp2: document HW checksum behaviour
From: Matteo Croce @ 2019-07-26 14:35 UTC (permalink / raw)
To: Antoine Tenart
Cc: netdev, Maxime Chevallier, Marcin Wojtas, Stefan Chulski, LKML
In-Reply-To: <20190726125715.GB5031@kwain>
On Fri, Jul 26, 2019 at 2:57 PM Antoine Tenart
<antoine.tenart@bootlin.com> wrote:
>
> Hi Matteo,
>
> On Fri, Jul 26, 2019 at 01:15:46AM +0200, Matteo Croce wrote:
> > The hardware can only offload checksum calculation on first port due to
> > the Tx FIFO size limitation. Document this in a comment.
> >
> > Fixes: 576193f2d579 ("net: mvpp2: jumbo frames support")
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
>
> Looks good. Please note there's a similar code path in the probe. You
> could also add a comment there (or move this check/comment in a common
> place).
>
> Thanks!
> Antoine
>
> > ---
> > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index d8e5241097a9..2f7286bd203b 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -843,7 +843,10 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, int mtu)
> > /* Add port to new short & long pool */
> > mvpp2_swf_bm_pool_init(port);
> >
> > - /* Update L4 checksum when jumbo enable/disable on port */
> > + /* Update L4 checksum when jumbo enable/disable on port.
> > + * Only port 0 supports hardware checksum offload due to
> > + * the Tx FIFO size limitation.
> > + */
> > if (new_long_pool == MVPP2_BM_JUMBO && port->id != 0) {
> > dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
> > dev->hw_features &= ~(NETIF_F_IP_CSUM |
> > --
> > 2.21.0
> >
>
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
I see, there is a similar statement in mvpp2_port_probe().
What about adding a static function which sets the flag, and add the
comment there instead of duplicating the comment?
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox