* Re: [PATCH 04/14] net: sched: implement unlocked action init API
From: Marcelo Ricardo Leitner @ 2018-05-19 21:11 UTC (permalink / raw)
To: Jiri Pirko
Cc: Vlad Buslov, netdev, davem, jhs, xiyou.wangcong, pablo, kadlec,
fw, ast, daniel, edumazet, keescook, linux-kernel,
netfilter-devel, coreteam, kliteyn
In-Reply-To: <20180514151641.GD1848@nanopsycho>
On Mon, May 14, 2018 at 05:16:41PM +0200, Jiri Pirko wrote:
> Mon, May 14, 2018 at 04:27:05PM CEST, vladbu@mellanox.com wrote:
> >Add additional 'unlocked' argument to act API init functions.
> >Argument is true when rtnl lock is not taken and false otherwise.
> >It is required to implement actions that need to release rtnl lock before
> >loading kernel module and reacquire if afterwards.
> >
> >Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
>
> [...]
>
>
> >@@ -721,9 +722,11 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
> > a_o = tc_lookup_action_n(act_name);
> > if (a_o == NULL) {
> > #ifdef CONFIG_MODULES
> >- rtnl_unlock();
> >+ if (!unlocked)
> >+ rtnl_unlock();
> > request_module("act_%s", act_name);
> >- rtnl_lock();
> >+ if (!unlocked)
> >+ rtnl_lock();
>
> Although I don't like this conditional locking scheme, I see no other
> way to solve this :/ But I think would be better perhaps to rename
> "unlocked" to something like "rtnl_held".
Agreed. "rtnl_held" also removes the double negation, "!un...".
^ permalink raw reply
* [PATCH 3/3] sh_eth: fix typo in comment to BCULR write
From: Sergei Shtylyov @ 2018-05-19 21:05 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <d47afee4-6fd5-af6d-885c-5b07996749fc@cogentembedded.com>
Simon has noticed a typo in the comment accompaining the BCULR write --
fix it and move the comment before the write (following the style of
the other comments), while at it...
Reported-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1481,8 +1481,9 @@ static int sh_eth_dev_init(struct net_de
if (mdp->cd->nbst)
sh_eth_modify(ndev, EDMR, EDMR_NBST, EDMR_NBST);
+ /* Burst cycle count upper-limit */
if (mdp->cd->bculr)
- sh_eth_write(ndev, 0x800, BCULR); /* Burst sycle set */
+ sh_eth_write(ndev, 0x800, BCULR);
sh_eth_write(ndev, mdp->cd->fcftr_value, FCFTR);
^ permalink raw reply
* Re: [PATCH 02/14] net: sched: change type of reference and bind counters
From: Marcelo Ricardo Leitner @ 2018-05-19 21:04 UTC (permalink / raw)
To: Vlad Buslov
Cc: netdev, davem, jhs, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, keescook, linux-kernel, netfilter-devel,
coreteam, kliteyn
In-Reply-To: <1526308035-12484-3-git-send-email-vladbu@mellanox.com>
On Mon, May 14, 2018 at 05:27:03PM +0300, Vlad Buslov wrote:
> Change type of action reference counter to refcount_t.
>
> Change type of action bind counter to atomic_t.
> This type is used to allow decrementing bind counter without testing
> for 0 result.
... and in what does not testing for 0 result helps?
Marcelo
^ permalink raw reply
* [PATCH 2/3] sh_eth: fix comment grammar in 'struct sh_eth_cpu_data'
From: Sergei Shtylyov @ 2018-05-19 21:03 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <d47afee4-6fd5-af6d-885c-5b07996749fc@cogentembedded.com>
All the verbs in the comments to the 'struct sh_eth_cpu_data' declaration
should be in a 3rd person singular, to match the nouns.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.h | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -499,21 +499,21 @@ struct sh_eth_cpu_data {
/* hardware features */
unsigned long irq_flags; /* IRQ configuration flags */
- unsigned no_psr:1; /* EtherC DO NOT have PSR */
- unsigned apr:1; /* EtherC have APR */
- unsigned mpr:1; /* EtherC have MPR */
- unsigned tpauser:1; /* EtherC have TPAUSER */
- unsigned bculr:1; /* EtherC have BCULR */
- unsigned tsu:1; /* EtherC have TSU */
- unsigned hw_swap:1; /* E-DMAC have DE bit in EDMR */
+ unsigned no_psr:1; /* EtherC DOES NOT have PSR */
+ unsigned apr:1; /* EtherC has APR */
+ unsigned mpr:1; /* EtherC has MPR */
+ unsigned tpauser:1; /* EtherC has TPAUSER */
+ unsigned bculr:1; /* EtherC has BCULR */
+ unsigned tsu:1; /* EtherC has TSU */
+ unsigned hw_swap:1; /* E-DMAC has DE bit in EDMR */
unsigned nbst:1; /* E-DMAC has NBST bit in EDMR */
- unsigned rpadir:1; /* E-DMAC have RPADIR */
- unsigned no_trimd:1; /* E-DMAC DO NOT have TRIMD */
- unsigned no_ade:1; /* E-DMAC DO NOT have ADE bit in EESR */
+ unsigned rpadir:1; /* E-DMAC has RPADIR */
+ unsigned no_trimd:1; /* E-DMAC DOES NOT have TRIMD */
+ unsigned no_ade:1; /* E-DMAC DOES NOT have ADE bit in EESR */
unsigned no_xdfar:1; /* E-DMAC DOES NOT have RDFAR/TDFAR */
unsigned xdfar_rw:1; /* E-DMAC has writeable RDFAR/TDFAR */
unsigned hw_checksum:1; /* E-DMAC has CSMR */
- unsigned select_mii:1; /* EtherC have RMII_MII (MII select register) */
+ unsigned select_mii:1; /* EtherC has RMII_MII (MII select register) */
unsigned rmiimode:1; /* EtherC has RMIIMODE register */
unsigned rtrate:1; /* EtherC has RTRATE register */
unsigned magic:1; /* EtherC has ECMR.MPDE and ECSR.MPD */
^ permalink raw reply
* [PATCH 1/3] sh_eth: fix typo in EESR.TRO bit name
From: Sergei Shtylyov @ 2018-05-19 21:02 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <d47afee4-6fd5-af6d-885c-5b07996749fc@cogentembedded.com>
The correct name of the EESR bit 8 is TRO (transmit retry over), not RTO.
Note that EESIPR bit 8, TROIP remained correct...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 10 +++++-----
drivers/net/ethernet/renesas/sh_eth.h | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -706,7 +706,7 @@ static struct sh_eth_cpu_data rcar_gen1_
EESIPR_RTLFIP | EESIPR_RTSFIP |
EESIPR_PREIP | EESIPR_CERFIP,
- .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_TRO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE,
.fdr_value = 0x00000f0f,
@@ -738,7 +738,7 @@ static struct sh_eth_cpu_data rcar_gen2_
EESIPR_RTLFIP | EESIPR_RTSFIP |
EESIPR_PREIP | EESIPR_CERFIP,
- .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_TRO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE,
.fdr_value = 0x00000f0f,
@@ -774,7 +774,7 @@ static struct sh_eth_cpu_data r8a77980_d
EESIPR_RTLFIP | EESIPR_RTSFIP |
EESIPR_PREIP | EESIPR_CERFIP,
- .tx_check = EESR_FTC | EESR_CD | EESR_RTO,
+ .tx_check = EESR_FTC | EESR_CD | EESR_TRO,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
EESR_RFE | EESR_RDE | EESR_RFRMER |
EESR_TFE | EESR_TDE | EESR_ECI,
@@ -831,7 +831,7 @@ static struct sh_eth_cpu_data sh7724_dat
EESIPR_RTLFIP | EESIPR_RTSFIP |
EESIPR_PREIP | EESIPR_CERFIP,
- .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_TRO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE,
@@ -876,7 +876,7 @@ static struct sh_eth_cpu_data sh7757_dat
EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
EESIPR_PREIP | EESIPR_CERFIP,
- .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_TRO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE,
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -243,7 +243,7 @@ enum EESR_BIT {
EESR_CND = 0x00000800,
EESR_DLC = 0x00000400,
EESR_CD = 0x00000200,
- EESR_RTO = 0x00000100,
+ EESR_TRO = 0x00000100,
EESR_RMAF = 0x00000080,
EESR_CEEF = 0x00000040,
EESR_CELF = 0x00000020,
@@ -263,7 +263,7 @@ enum EESR_BIT {
EESR_CERF) /* Recv frame CRC error */
#define DEFAULT_TX_CHECK (EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | \
- EESR_RTO)
+ EESR_TRO)
#define DEFAULT_EESR_ERR_CHECK (EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE | \
EESR_RDE | EESR_RFRMER | EESR_ADE | \
EESR_TFE | EESR_TDE)
^ permalink raw reply
* Re: [PATCH RFC net-next 1/1] tcp: close socket without reset on incoming data
From: David Miller @ 2018-05-19 21:00 UTC (permalink / raw)
To: dbanerje; +Cc: netdev, kuznet, yoshfuji
In-Reply-To: <20180518190141.899-2-dbanerje@akamai.com>
From: Debabrata Banerjee <dbanerje@akamai.com>
Date: Fri, 18 May 2018 15:01:41 -0400
> When TCP_CLOSE_NORST is set before a close(), offload sinking of
> unwanted data to the kernel with low resource usage, with a timeout of
> TCP_LINGER2. The socket will transition to FIN_WAIT1 and then FIN_WAIT2
> where it will ack data until either the timeout is hit, or a RST or FIN
> is received.
>
> Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
This is a very serious protocol violation.
You're telling the remote end that you received the data even though
the socket was closed and nothing actually "sunk" the bytes.
This doesn't even go into the issues of sending cumulative ACKs in
response to data which is arbitrarily out-of-order.
The whole problem is that the post data is sent before the client
looks to see if the server is willing to accept the post data or not.
A: I'd like to send you 200MB of crap
[ 200MB of craaaa...
B: Sorry I won't be accepting that, please don't send it.
CLOSE, send reset since some of crap is queued up and
was never read
A: aaaaapp... received RESET
A: Why didn't B accept my 200MB of crap?
Sorry, you'll need to deal with this issue in another way.
Thanks.
^ permalink raw reply
* [PATCH 0/3] sh_eth: fix typos/grammar
From: Sergei Shtylyov @ 2018-05-19 20:57 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
Hello!
Here's a set of 3 patches against DaveM's 'net-next.git' repo plus the R8A77980
support patches posted earlier. They fix the comments typos/grammar and another
typo in the EESR bit...
[1/1] sh_eth: fix typo in EESR.TRO bit name
[2/3] sh_eth: fix comment grammar in 'struct sh_eth_cpu_data'
[3/3] sh_eth: fix typo in comment to BCULR write
MBR, Sergei
^ permalink raw reply
* [PATCH net-next 1/3] net: dsa: mv88e6xxx: Remove OF check for IRQ domain
From: Andrew Lunn @ 2018-05-19 20:31 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, Florian Fainelli, netdev, Andrew Lunn
In-Reply-To: <1526761895-15839-1-git-send-email-andrew@lunn.ch>
An IRQ domain will work without an OF node. It is not possible to
reference interrupts via a phandle, but C code can still use
irq_find_mapping() to get an interrupt from the domain.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/global2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/global2.c b/drivers/net/dsa/mv88e6xxx/global2.c
index f9bde011a3e6..91a3cb2452ac 100644
--- a/drivers/net/dsa/mv88e6xxx/global2.c
+++ b/drivers/net/dsa/mv88e6xxx/global2.c
@@ -1047,9 +1047,6 @@ int mv88e6xxx_g2_irq_setup(struct mv88e6xxx_chip *chip)
{
int err, irq, virq;
- if (!chip->dev->of_node)
- return -EINVAL;
-
chip->g2_irq.domain = irq_domain_add_simple(
chip->dev->of_node, 16, 0, &mv88e6xxx_g2_irq_domain_ops, chip);
if (!chip->g2_irq.domain)
--
2.17.0
^ permalink raw reply related
* [PATCH net-next 3/3] net: dsa: mv88e6xxx: Add support for EEPROM via platform data
From: Andrew Lunn @ 2018-05-19 20:31 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, Florian Fainelli, netdev, Andrew Lunn
In-Reply-To: <1526761895-15839-1-git-send-email-andrew@lunn.ch>
Add the size of the EEPROM to the platform data, so it can also be
instantiated by a platform device.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 11 +++++++----
drivers/net/dsa/mv88e6xxx/chip.h | 2 +-
include/linux/platform_data/mv88e6xxx.h | 1 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5b40382036ea..1fa1f820a437 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4386,7 +4386,6 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
struct device_node *np = dev->of_node;
const struct mv88e6xxx_info *compat_info;
struct mv88e6xxx_chip *chip;
- u32 eeprom_len;
int port;
int err;
@@ -4436,9 +4435,13 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
mv88e6xxx_phy_init(chip);
- if (chip->info->ops->get_eeprom &&
- !of_property_read_u32(np, "eeprom-length", &eeprom_len))
- chip->eeprom_len = eeprom_len;
+ if (chip->info->ops->get_eeprom) {
+ if (np)
+ of_property_read_u32(np, "eeprom-length",
+ &chip->eeprom_len);
+ else
+ chip->eeprom_len = pdata->eeprom_len;
+ }
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_switch_reset(chip);
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index 012268046442..8ac3fbb15352 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -238,7 +238,7 @@ struct mv88e6xxx_chip {
struct gpio_desc *reset;
/* set to size of eeprom if supported by the switch */
- int eeprom_len;
+ u32 eeprom_len;
/* List of mdio busses */
struct list_head mdios;
diff --git a/include/linux/platform_data/mv88e6xxx.h b/include/linux/platform_data/mv88e6xxx.h
index 88e91e05f48f..f63af2955ea0 100644
--- a/include/linux/platform_data/mv88e6xxx.h
+++ b/include/linux/platform_data/mv88e6xxx.h
@@ -12,6 +12,7 @@ struct dsa_mv88e6xxx_pdata {
const char *compatible;
unsigned int enabled_ports;
struct net_device *netdev;
+ u32 eeprom_len;
};
#endif
--
2.17.0
^ permalink raw reply related
* [PATCH net-next 2/3] net: dsa: mv88e6xxx: Add minimal platform_data support
From: Andrew Lunn @ 2018-05-19 20:31 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, Florian Fainelli, netdev, Andrew Lunn
In-Reply-To: <1526761895-15839-1-git-send-email-andrew@lunn.ch>
Not all the world uses device tree. Some parts of the world still use
platform devices and platform data. Add basic support for probing a
Marvell switch via platform data.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
MAINTAINERS | 1 +
drivers/net/dsa/mv88e6xxx/chip.c | 56 +++++++++++++++++++++----
include/linux/platform_data/mv88e6xxx.h | 17 ++++++++
3 files changed, 67 insertions(+), 7 deletions(-)
create mode 100644 include/linux/platform_data/mv88e6xxx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 658880464b9d..9f2045a5adac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8466,6 +8466,7 @@ M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/dsa/mv88e6xxx/
+F: linux/platform_data/mv88e6xxx.h
F: Documentation/devicetree/bindings/net/dsa/marvell.txt
MARVELL ARMADA DRM SUPPORT
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 2bb3f03ee1cb..5b40382036ea 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -28,6 +28,7 @@
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/of_mdio.h>
+#include <linux/platform_data/mv88e6xxx.h>
#include <linux/netdevice.h>
#include <linux/gpio/consumer.h>
#include <linux/phy.h>
@@ -4350,6 +4351,7 @@ static int mv88e6xxx_register_switch(struct mv88e6xxx_chip *chip)
return -ENOMEM;
ds->priv = chip;
+ ds->dev = dev;
ds->ops = &mv88e6xxx_switch_ops;
ds->ageing_time_min = chip->info->age_time_coeff;
ds->ageing_time_max = chip->info->age_time_coeff * U8_MAX;
@@ -4364,36 +4366,73 @@ static void mv88e6xxx_unregister_switch(struct mv88e6xxx_chip *chip)
dsa_unregister_switch(chip->ds);
}
+static const void *pdata_device_get_match_data(struct device *dev)
+{
+ const struct of_device_id *matches = dev->driver->of_match_table;
+ const struct dsa_mv88e6xxx_pdata *pdata = dev->platform_data;
+
+ for (; matches->name[0] || matches->type[0] || matches->compatible[0];
+ matches++) {
+ if (!strcmp(pdata->compatible, matches->compatible))
+ return matches->data;
+ }
+ return NULL;
+}
+
static int mv88e6xxx_probe(struct mdio_device *mdiodev)
{
+ struct dsa_mv88e6xxx_pdata *pdata = mdiodev->dev.platform_data;
struct device *dev = &mdiodev->dev;
struct device_node *np = dev->of_node;
const struct mv88e6xxx_info *compat_info;
struct mv88e6xxx_chip *chip;
u32 eeprom_len;
+ int port;
int err;
- compat_info = of_device_get_match_data(dev);
+ if (np)
+ compat_info = of_device_get_match_data(dev);
+
+ if (pdata) {
+ compat_info = pdata_device_get_match_data(dev);
+
+ if (!pdata->netdev)
+ return -EINVAL;
+
+ for (port = 0; port < DSA_MAX_PORTS; port++) {
+ if (!(pdata->enabled_ports & (1 << port)))
+ continue;
+ if (strcmp(pdata->cd.port_names[port], "cpu"))
+ continue;
+ pdata->cd.netdev[port] = &pdata->netdev->dev;
+ break;
+ }
+ }
+
if (!compat_info)
return -EINVAL;
chip = mv88e6xxx_alloc_chip(dev);
- if (!chip)
- return -ENOMEM;
+ if (!chip) {
+ err = -ENOMEM;
+ goto out;
+ }
chip->info = compat_info;
err = mv88e6xxx_smi_init(chip, mdiodev->bus, mdiodev->addr);
if (err)
- return err;
+ goto out;
chip->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(chip->reset))
- return PTR_ERR(chip->reset);
+ if (IS_ERR(chip->reset)) {
+ err = PTR_ERR(chip->reset);
+ goto out;
+ }
err = mv88e6xxx_detect(chip);
if (err)
- return err;
+ goto out;
mv88e6xxx_phy_init(chip);
@@ -4468,6 +4507,9 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
mv88e6xxx_irq_poll_free(chip);
mutex_unlock(&chip->reg_lock);
out:
+ if (pdata)
+ dev_put(pdata->netdev);
+
return err;
}
diff --git a/include/linux/platform_data/mv88e6xxx.h b/include/linux/platform_data/mv88e6xxx.h
new file mode 100644
index 000000000000..88e91e05f48f
--- /dev/null
+++ b/include/linux/platform_data/mv88e6xxx.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DSA_MV88E6XXX_H
+#define __DSA_MV88E6XXX_H
+
+#include <net/dsa.h>
+
+struct dsa_mv88e6xxx_pdata {
+ /* Must be first, such that dsa_register_switch() can access this
+ * without gory pointer manipulations
+ */
+ struct dsa_chip_data cd;
+ const char *compatible;
+ unsigned int enabled_ports;
+ struct net_device *netdev;
+};
+
+#endif
--
2.17.0
^ permalink raw reply related
* [PATCH net-next 0/3] Platform data support for mv88exxx
From: Andrew Lunn @ 2018-05-19 20:31 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, Florian Fainelli, netdev, Andrew Lunn
There are a few Intel based platforms making use of the mv88exxx.
These don't easily have access to device tree in order to instantiate
the switch driver. These patches allow the use of platform data to
hold the configuration.
Andrew Lunn (3):
net: dsa: mv88e6xxx: Remove OF check for IRQ domain
net: dsa: mv88e6xxx: Add minimal platform_data support
net: dsa: mv88e6xxx: Add support for EEPROM via platform data
MAINTAINERS | 1 +
drivers/net/dsa/mv88e6xxx/chip.c | 67 +++++++++++++++++++++----
drivers/net/dsa/mv88e6xxx/chip.h | 2 +-
drivers/net/dsa/mv88e6xxx/global2.c | 3 --
include/linux/platform_data/mv88e6xxx.h | 18 +++++++
5 files changed, 76 insertions(+), 15 deletions(-)
create mode 100644 include/linux/platform_data/mv88e6xxx.h
--
2.17.0
^ permalink raw reply
* Re: [patch net-next 0/5] devlink: introduce port flavours and common phys_port_name generation
From: David Miller @ 2018-05-19 20:31 UTC (permalink / raw)
To: f.fainelli
Cc: jiri, netdev, idosch, jakub.kicinski, mlxsw, andrew,
vivien.didelot, michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, dsahern, vijaya.guvva,
satananda.burla, raghu.vatsavayi, felix.manlunas, gospo,
sathya.perla, vasundhara-v.volam, tariqt, eranbe,
jeffrey.t.kirsher, roopa
In-Reply-To: <c7cfe96a-46c1-57c4-02cc-92e6dcaebc05@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 18 May 2018 20:34:25 -0700
> On 05/18/2018 12:28 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> This patchset resolves 2 issues we have right now:
>> 1) There are many netdevices / ports in the system, for port, pf, vf
>> represenatation but the user has no way to see which is which
>> 2) The ndo_get_phys_port_name is implemented in each driver separatelly,
>> which may lead to inconsistent names between drivers.
>>
>> This patchset introduces port flavours which should address the first
>> problem. In this initial patchset, I focus on DSA and their port
>> flavours. As a follow-up, I plan to add PF and VF representor flavours.
>> However, that needs additional dependencies in drivers (nfp, mlx5).
>>
>> The common phys_port_name generation is used by mlxsw. An example output
>> for mlxsw looks like this:
...
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Series applied, thanks everyone.
^ permalink raw reply
* Re: [net-next PATCH v2 2/4] net: Enable Tx queue selection based on Rx queues
From: Willem de Bruijn @ 2018-05-19 20:27 UTC (permalink / raw)
To: Tom Herbert
Cc: Amritha Nambiar, Linux Kernel Network Developers, David S. Miller,
Alexander Duyck, Sridhar Samudrala, Eric Dumazet,
Hannes Frederic Sowa
In-Reply-To: <CAF=yD-JXpiJwxM_mHvAgJ6qhsgq4uOZYbsMBVvcOmZawbueayQ@mail.gmail.com>
On Sat, May 19, 2018 at 4:13 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, May 18, 2018 at 12:03 AM, Tom Herbert <tom@herbertland.com> wrote:
>> On Tue, May 15, 2018 at 6:26 PM, Amritha Nambiar
>> <amritha.nambiar@intel.com> wrote:
>>> This patch adds support to pick Tx queue based on the Rx queue map
>>> configuration set by the admin through the sysfs attribute
>>> for each Tx queue. If the user configuration for receive
>>> queue map does not apply, then the Tx queue selection falls back
>>> to CPU map based selection and finally to hashing.
>>>
>>> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>> ---
>>> +static int get_xps_queue(struct net_device *dev, struct sk_buff *skb)
>>> +{
>>> +#ifdef CONFIG_XPS
>>> + enum xps_map_type i = XPS_MAP_RXQS;
>>> + struct xps_dev_maps *dev_maps;
>>> + struct sock *sk = skb->sk;
>>> + int queue_index = -1;
>>> + unsigned int tci = 0;
>>> +
>>> + if (sk && sk->sk_rx_queue_mapping <= dev->real_num_rx_queues &&
>>> + dev->ifindex == sk->sk_rx_ifindex)
>>> + tci = sk->sk_rx_queue_mapping;
>>> +
>>> + rcu_read_lock();
>>> + while (queue_index < 0 && i < __XPS_MAP_MAX) {
>>> + if (i == XPS_MAP_CPUS)
>>
>> This while loop typifies exactly why I don't think the XPS maps should
>> be an array.
>
> +1
as a matter of fact, as enabling both cpu and rxqueue map at the same
time makes no sense, only one map is needed at any one time. The
only difference is in how it is indexed. It should probably not be possible
to configure both at the same time. Keeping a single map probably also
significantly simplifies patch 1/4.
^ permalink raw reply
* Re: [PATCH net-next] sctp: add support for SCTP_REUSE_PORT sockopt
From: Marcelo Ricardo Leitner @ 2018-05-19 20:26 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Neil Horman, davem
In-Reply-To: <be8e672439406e6c8b838321d63aa109b9620f4c.1526715880.git.lucien.xin@gmail.com>
On Sat, May 19, 2018 at 03:44:40PM +0800, Xin Long wrote:
> This feature is actually already supported by sk->sk_reuse which can be
> set by SO_REUSEADDR. But it's not working exactly as RFC6458 demands in
> section 8.1.27, like:
>
> - This option only supports one-to-one style SCTP sockets
> - This socket option must not be used after calling bind()
> or sctp_bindx().
>
> Besides, SCTP_REUSE_PORT sockopt should be provided for user's programs.
> Otherwise, the programs with SCTP_REUSE_PORT from other systems will not
> work in linux.
>
> This patch reuses sk->sk_reuse and works pretty much as SO_REUSEADDR,
> just with some extra setup limitations that are neeeded when it is being
> enabled.
>
> "It should be noted that the behavior of the socket-level socket option
> to reuse ports and/or addresses for SCTP sockets is unspecified", so it
> leaves SO_REUSEADDR as is for the compatibility.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> include/uapi/linux/sctp.h | 1 +
> net/sctp/socket.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 49 insertions(+)
>
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index b64d583..c02986a 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -100,6 +100,7 @@ typedef __s32 sctp_assoc_t;
> #define SCTP_RECVNXTINFO 33
> #define SCTP_DEFAULT_SNDINFO 34
> #define SCTP_AUTH_DEACTIVATE_KEY 35
> +#define SCTP_REUSE_PORT 36
>
> /* Internal Socket Options. Some of the sctp library functions are
> * implemented using these socket options.
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 1b4593b..8dfcc79 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4170,6 +4170,28 @@ static int sctp_setsockopt_interleaving_supported(struct sock *sk,
> return retval;
> }
>
> +static int sctp_setsockopt_reuse_port(struct sock *sk, char __user *optval,
> + unsigned int optlen)
> +{
> + int val;
> +
> + if (!sctp_style(sk, TCP))
> + return -EOPNOTSUPP;
> +
> + if (sctp_sk(sk)->ep->base.bind_addr.port)
> + return -EFAULT;
> +
> + if (optlen < sizeof(int))
> + return -EINVAL;
> +
> + if (get_user(val, (int __user *)optval))
> + return -EFAULT;
> +
> + sk->sk_reuse = val ? SK_CAN_REUSE : SK_NO_REUSE;
> +
> + return 0;
> +}
> +
> /* API 6.2 setsockopt(), getsockopt()
> *
> * Applications use setsockopt() and getsockopt() to set or retrieve
> @@ -4364,6 +4386,9 @@ static int sctp_setsockopt(struct sock *sk, int level, int optname,
> retval = sctp_setsockopt_interleaving_supported(sk, optval,
> optlen);
> break;
> + case SCTP_REUSE_PORT:
> + retval = sctp_setsockopt_reuse_port(sk, optval, optlen);
> + break;
> default:
> retval = -ENOPROTOOPT;
> break;
> @@ -7175,6 +7200,26 @@ static int sctp_getsockopt_interleaving_supported(struct sock *sk, int len,
> return retval;
> }
>
> +static int sctp_getsockopt_reuse_port(struct sock *sk, int len,
> + char __user *optval,
> + int __user *optlen)
> +{
> + int val = 0;
> +
> + if (len < sizeof(int))
> + return -EINVAL;
> +
> + len = sizeof(int);
> + if (sk->sk_reuse != SK_NO_REUSE)
> + val = 1;
> + if (put_user(len, optlen))
> + return -EFAULT;
> + if (copy_to_user(optval, &val, len))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static int sctp_getsockopt(struct sock *sk, int level, int optname,
> char __user *optval, int __user *optlen)
> {
> @@ -7370,6 +7415,9 @@ static int sctp_getsockopt(struct sock *sk, int level, int optname,
> retval = sctp_getsockopt_interleaving_supported(sk, len, optval,
> optlen);
> break;
> + case SCTP_REUSE_PORT:
> + retval = sctp_getsockopt_reuse_port(sk, len, optval, optlen);
> + break;
> default:
> retval = -ENOPROTOOPT;
> break;
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [net-next PATCH v2 2/4] net: Enable Tx queue selection based on Rx queues
From: Willem de Bruijn @ 2018-05-19 20:13 UTC (permalink / raw)
To: Tom Herbert
Cc: Amritha Nambiar, Linux Kernel Network Developers, David S. Miller,
Alexander Duyck, Sridhar Samudrala, Eric Dumazet,
Hannes Frederic Sowa
In-Reply-To: <CALx6S3652mgSjpQtF+9N90CYYhvyaMjS94zbgyhcFAa_G0h4tQ@mail.gmail.com>
On Fri, May 18, 2018 at 12:03 AM, Tom Herbert <tom@herbertland.com> wrote:
> On Tue, May 15, 2018 at 6:26 PM, Amritha Nambiar
> <amritha.nambiar@intel.com> wrote:
>> This patch adds support to pick Tx queue based on the Rx queue map
>> configuration set by the admin through the sysfs attribute
>> for each Tx queue. If the user configuration for receive
>> queue map does not apply, then the Tx queue selection falls back
>> to CPU map based selection and finally to hashing.
>>
>> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>> ---
>> include/net/sock.h | 18 ++++++++++++++++++
>> net/core/dev.c | 36 +++++++++++++++++++++++++++++-------
>> net/core/sock.c | 5 +++++
>> net/ipv4/tcp_input.c | 7 +++++++
>> net/ipv4/tcp_ipv4.c | 1 +
>> net/ipv4/tcp_minisocks.c | 1 +
>> 6 files changed, 61 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index 4f7c584..0613f63 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -139,6 +139,8 @@ typedef __u64 __bitwise __addrpair;
>> * @skc_node: main hash linkage for various protocol lookup tables
>> * @skc_nulls_node: main hash linkage for TCP/UDP/UDP-Lite protocol
>> * @skc_tx_queue_mapping: tx queue number for this connection
>> + * @skc_rx_queue_mapping: rx queue number for this connection
>> + * @skc_rx_ifindex: rx ifindex for this connection
>> * @skc_flags: place holder for sk_flags
>> * %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE,
>> * %SO_OOBINLINE settings, %SO_TIMESTAMPING settings
>> @@ -215,6 +217,10 @@ struct sock_common {
>> struct hlist_nulls_node skc_nulls_node;
>> };
>> int skc_tx_queue_mapping;
>> +#ifdef CONFIG_XPS
>> + int skc_rx_queue_mapping;
>> + int skc_rx_ifindex;
>
> Isn't this increasing size of sock_common for a narrow use case functionality?
You can get the device from the already recorded sk_napi_id.
Sadly, not the queue number as far as I can see.
>> +static inline void sk_mark_rx_queue(struct sock *sk, struct sk_buff *skb)
>> +{
>> +#ifdef CONFIG_XPS
>> + sk->sk_rx_ifindex = skb->skb_iif;
>> + sk->sk_rx_queue_mapping = skb_get_rx_queue(skb);
>> +#endif
>> +}
>> +
Instead of adding this function and calls to it in many locations in
the stack, you can expand sk_mark_napi_id.
Also, it is not clear why this should be called in locations where
sk_mark_napi_id is not.
>> +static int get_xps_queue(struct net_device *dev, struct sk_buff *skb)
>> +{
>> +#ifdef CONFIG_XPS
>> + enum xps_map_type i = XPS_MAP_RXQS;
>> + struct xps_dev_maps *dev_maps;
>> + struct sock *sk = skb->sk;
>> + int queue_index = -1;
>> + unsigned int tci = 0;
>> +
>> + if (sk && sk->sk_rx_queue_mapping <= dev->real_num_rx_queues &&
>> + dev->ifindex == sk->sk_rx_ifindex)
>> + tci = sk->sk_rx_queue_mapping;
>> +
>> + rcu_read_lock();
>> + while (queue_index < 0 && i < __XPS_MAP_MAX) {
>> + if (i == XPS_MAP_CPUS)
>
> This while loop typifies exactly why I don't think the XPS maps should
> be an array.
+1
^ permalink raw reply
* atención
From: Administrador de sistema @ 2018-05-18 15:41 UTC (permalink / raw)
To: Recipients
usuarios de webmail
Tenga en cuenta que el 95% de sus correos electrónicos recibidos después de actualizar el servidor webmail recientemente en nuestra base de datos se han suspendido. Reciba su mensaje regularmente. Nuestro personal técnico actualizará su cuenta dentro de los tres días hábiles. De lo contrario, su cuenta será suspendida temporalmente por nuestro servicio. Para reconfirmar su buzón de correo, se enviará la siguiente información:
normal:
Nombre de usuario:
contraseña:
Confirmar la contraseña:
Una advertencia !! Si esto no le permite actualizar su cuenta dentro de los dos días posteriores a la recepción del correo electrónico, perderá permanentemente el correo web de la cuenta del titular de la cuenta.
¡Gracias por su colaboración!
Copyright © 2017-2018 WebMail Technical Support Services, Inc.
^ permalink raw reply
* Re: INFO: rcu detected stall in is_bpf_text_address
From: Eric Dumazet @ 2018-05-19 15:57 UTC (permalink / raw)
To: syzbot, ast, daniel, linux-kernel, netdev, syzkaller-bugs,
Xin Long, Marcelo Ricardo Leitner
In-Reply-To: <0000000000006d7517056c911740@google.com>
SCTP experts, please take a look.
On 05/19/2018 08:55 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 73fcb1a370c7 Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1462ec0f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed
> dashboard link: https://syzkaller.appspot.com/bug?extid=3dcd59a1f907245f891f
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1079cf8f800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=156daf97800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3dcd59a1f907245f891f@syzkaller.appspotmail.com
>
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> INFO: rcu_sched self-detected stall on CPU
> 0-...!: (124998 ticks this GP) idle=0be/1/4611686018427387908 softirq=15234/15234 fqs=59
> (t=125000 jiffies g=7610 c=7609 q=351640)
> rcu_sched kthread starved for 124739 jiffies! g7610 c7609 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=1
> RCU grace-period kthread stack dump:
> rcu_sched R running task 23896 9 2 0x80000000
> Call Trace:
> context_switch kernel/sched/core.c:2859 [inline]
> __schedule+0x801/0x1e30 kernel/sched/core.c:3501
> schedule+0xef/0x430 kernel/sched/core.c:3545
> schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
> rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
> kthread+0x345/0x410 kernel/kthread.c:240
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
> NMI backtrace for cpu 0
> CPU: 0 PID: 6381 Comm: sh Not tainted 4.17.0-rc5+ #58
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
> rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
> print_cpu_stall kernel/rcu/tree.c:1525 [inline]
> check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
> __rcu_pending kernel/rcu/tree.c:3356 [inline]
> rcu_pending kernel/rcu/tree.c:3401 [inline]
> rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
> update_process_times+0x2d/0x70 kernel/time/timer.c:1636
> tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
> tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
> __run_hrtimer kernel/time/hrtimer.c:1398 [inline]
> __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
> hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline]
> RIP: 0010:lock_acquire+0x257/0x520 kernel/locking/lockdep.c:3923
> RSP: 0000:ffff8801dae06b60 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: dffffc0000000000 RBX: 1ffff1003b5c0d71 RCX: 0000000000000000
> RDX: 1ffffffff11a30e5 RSI: ffff8801c7b54c38 RDI: 0000000000000286
> RBP: ffff8801dae06c50 R08: 0000000000000008 R09: 0000000000000003
> R10: ffff8801c7b54cb0 R11: ffff8801c7b54400 R12: ffff8801c7b54400
> R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
> rcu_lock_acquire include/linux/rcupdate.h:246 [inline]
> rcu_read_lock include/linux/rcupdate.h:632 [inline]
> is_bpf_text_address+0x3b/0x170 kernel/bpf/core.c:478
> kernel_text_address+0x79/0xf0 kernel/extable.c:152
> __kernel_text_address+0xd/0x40 kernel/extable.c:107
> unwind_get_return_address+0x61/0xa0 arch/x86/kernel/unwind_frame.c:18
> __save_stack_trace+0x7e/0xd0 arch/x86/kernel/stacktrace.c:45
> save_stack_trace+0x1a/0x20 arch/x86/kernel/stacktrace.c:60
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> slab_post_alloc_hook mm/slab.h:444 [inline]
> slab_alloc_node mm/slab.c:3335 [inline]
> kmem_cache_alloc_node+0x131/0x780 mm/slab.c:3642
> __alloc_skb+0x111/0x780 net/core/skbuff.c:193
> alloc_skb include/linux/skbuff.h:987 [inline]
> _sctp_make_chunk+0x58/0x280 net/sctp/sm_make_chunk.c:1417
> sctp_make_control net/sctp/sm_make_chunk.c:1464 [inline]
> sctp_make_heartbeat+0x8f/0x430 net/sctp/sm_make_chunk.c:1177
> sctp_sf_heartbeat.isra.23+0x26/0x180 net/sctp/sm_statefuns.c:1005
> sctp_sf_sendbeat_8_3+0x38e/0x550 net/sctp/sm_statefuns.c:1049
> sctp_do_sm+0x1ab/0x7160 net/sctp/sm_sideeffect.c:1188
> sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
> call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
> expire_timers kernel/time/timer.c:1363 [inline]
> __run_timers+0x79e/0xc50 kernel/time/timer.c:1666
> run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> invoke_softirq kernel/softirq.c:365 [inline]
> irq_exit+0x1d1/0x200 kernel/softirq.c:405
> exiting_irq arch/x86/include/asm/apic.h:525 [inline]
> smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
> </IRQ>
> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
> RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:31 [inline]
> RIP: 0010:atomic_read include/asm-generic/atomic-instrumented.h:22 [inline]
> RIP: 0010:rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:349 [inline]
> RIP: 0010:rcu_is_watching+0xc4/0x140 kernel/rcu/tree.c:1075
> RSP: 0000:ffff8801c957f398 EFLAGS: 00000a06 ORIG_RAX: ffffffffffffff13
> RAX: 00000000000130be RBX: 1ffff100392afe74 RCX: 1ffff100392afe78
> RDX: 0000000000000004 RSI: 0000000000000004 RDI: ffff8801dae23610
> RBP: ffff8801c957f428 R08: ffffed003b5c46c3 R09: ffffed003b5c46c2
> R10: ffffed003b5c46c2 R11: ffff8801dae23613 R12: ffff8801c957f3c0
> R13: ffff8801dae23610 R14: ffff8801c957f400 R15: dffffc0000000000
> rcu_read_lock_sched_held+0x8d/0x120 kernel/rcu/update.c:112
> trace_kmem_cache_alloc include/trace/events/kmem.h:54 [inline]
> kmem_cache_alloc+0x5fa/0x760 mm/slab.c:3555
> anon_vma_alloc mm/rmap.c:81 [inline]
> __anon_vma_prepare+0x3b3/0x700 mm/rmap.c:189
> anon_vma_prepare include/linux/rmap.h:153 [inline]
> wp_page_copy+0xdf1/0x1440 mm/memory.c:2481
> do_wp_page+0x425/0x1990 mm/memory.c:2776
> handle_pte_fault mm/memory.c:3979 [inline]
> __handle_mm_fault+0x2996/0x4310 mm/memory.c:4087
> handle_mm_fault+0x53a/0xc70 mm/memory.c:4124
> __do_page_fault+0x60b/0xe40 arch/x86/mm/fault.c:1399
> do_page_fault+0xee/0x8a7 arch/x86/mm/fault.c:1474
> page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1160
> RIP: 0033:0x7f4232a6d1fb
> RSP: 002b:00007fff2aeebd28 EFLAGS: 00010246
> RAX: 000000000000000d RBX: 00000000756e6547 RCX: 000000006c65746e
> RDX: 0000000049656e69 RSI: 0000000000000025 RDI: 0000000000000002
> RBP: 00007fff2aeebe20 R08: 0000000000000001 R09: 000000000000002f
> R10: 00007f4232a6caf0 R11: 00007fff2aeebb70 R12: 00007f4232a4e000
> R13: 00007f4232dd5038 R14: 00007f4232a6cac0 R15: 00007f4232dd5d98
> BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 126s!
> BUG: workqueue lockup - pool cpus=0-1 flags=0x4 nice=0 stuck for 125s!
> Showing busy workqueues and worker pools:
> workqueue events: flags=0x0
> pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=7/256
> pending: defense_work_handler, defense_work_handler, defense_work_handler, defense_work_handler, defense_work_handler, vmstat_shepherd, cache_reap
> workqueue events_power_efficient: flags=0x80
> pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> in-flight: 2107:neigh_periodic_work
> workqueue mm_percpu_wq: flags=0x8
> pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
> pending: vmstat_update
> workqueue writeback: flags=0x4e
> pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256
> in-flight: 4784:wb_workfn
> workqueue ib_addr: flags=0xa0002
> workqueue dm_bufio_cache: flags=0x8
> pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
> pending: work_fn
> workqueue ipv6_addrconf: flags=0x40008
> pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/1
> pending: addrconf_dad_work
> delayed: addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_verify_work
> pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
> pending: addrconf_dad_work
> delayed: addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work
> pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=0s workers=4 idle: 4707 24 4924
> pool 4: cpus=0-1 flags=0x4 nice=0 hung=0s workers=4 idle: 44 4846 6
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* INFO: rcu detected stall in is_bpf_text_address
From: syzbot @ 2018-05-19 15:55 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 73fcb1a370c7 Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1462ec0f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed
dashboard link: https://syzkaller.appspot.com/bug?extid=3dcd59a1f907245f891f
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1079cf8f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=156daf97800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3dcd59a1f907245f891f@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
INFO: rcu_sched self-detected stall on CPU
0-...!: (124998 ticks this GP) idle=0be/1/4611686018427387908
softirq=15234/15234 fqs=59
(t=125000 jiffies g=7610 c=7609 q=351640)
rcu_sched kthread starved for 124739 jiffies! g7610 c7609 f0x2
RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=1
RCU grace-period kthread stack dump:
rcu_sched R running task 23896 9 2 0x80000000
Call Trace:
context_switch kernel/sched/core.c:2859 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3501
schedule+0xef/0x430 kernel/sched/core.c:3545
schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
NMI backtrace for cpu 0
CPU: 0 PID: 6381 Comm: sh Not tainted 4.17.0-rc5+ #58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
print_cpu_stall kernel/rcu/tree.c:1525 [inline]
check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
__rcu_pending kernel/rcu/tree.c:3356 [inline]
rcu_pending kernel/rcu/tree.c:3401 [inline]
rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
update_process_times+0x2d/0x70 kernel/time/timer.c:1636
tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
__run_hrtimer kernel/time/hrtimer.c:1398 [inline]
__hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783
[inline]
RIP: 0010:lock_acquire+0x257/0x520 kernel/locking/lockdep.c:3923
RSP: 0000:ffff8801dae06b60 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: dffffc0000000000 RBX: 1ffff1003b5c0d71 RCX: 0000000000000000
RDX: 1ffffffff11a30e5 RSI: ffff8801c7b54c38 RDI: 0000000000000286
RBP: ffff8801dae06c50 R08: 0000000000000008 R09: 0000000000000003
R10: ffff8801c7b54cb0 R11: ffff8801c7b54400 R12: ffff8801c7b54400
R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
rcu_lock_acquire include/linux/rcupdate.h:246 [inline]
rcu_read_lock include/linux/rcupdate.h:632 [inline]
is_bpf_text_address+0x3b/0x170 kernel/bpf/core.c:478
kernel_text_address+0x79/0xf0 kernel/extable.c:152
__kernel_text_address+0xd/0x40 kernel/extable.c:107
unwind_get_return_address+0x61/0xa0 arch/x86/kernel/unwind_frame.c:18
__save_stack_trace+0x7e/0xd0 arch/x86/kernel/stacktrace.c:45
save_stack_trace+0x1a/0x20 arch/x86/kernel/stacktrace.c:60
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
slab_post_alloc_hook mm/slab.h:444 [inline]
slab_alloc_node mm/slab.c:3335 [inline]
kmem_cache_alloc_node+0x131/0x780 mm/slab.c:3642
__alloc_skb+0x111/0x780 net/core/skbuff.c:193
alloc_skb include/linux/skbuff.h:987 [inline]
_sctp_make_chunk+0x58/0x280 net/sctp/sm_make_chunk.c:1417
sctp_make_control net/sctp/sm_make_chunk.c:1464 [inline]
sctp_make_heartbeat+0x8f/0x430 net/sctp/sm_make_chunk.c:1177
sctp_sf_heartbeat.isra.23+0x26/0x180 net/sctp/sm_statefuns.c:1005
sctp_sf_sendbeat_8_3+0x38e/0x550 net/sctp/sm_statefuns.c:1049
sctp_do_sm+0x1ab/0x7160 net/sctp/sm_sideeffect.c:1188
sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:525 [inline]
smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:31 [inline]
RIP: 0010:atomic_read include/asm-generic/atomic-instrumented.h:22 [inline]
RIP: 0010:rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:349 [inline]
RIP: 0010:rcu_is_watching+0xc4/0x140 kernel/rcu/tree.c:1075
RSP: 0000:ffff8801c957f398 EFLAGS: 00000a06 ORIG_RAX: ffffffffffffff13
RAX: 00000000000130be RBX: 1ffff100392afe74 RCX: 1ffff100392afe78
RDX: 0000000000000004 RSI: 0000000000000004 RDI: ffff8801dae23610
RBP: ffff8801c957f428 R08: ffffed003b5c46c3 R09: ffffed003b5c46c2
R10: ffffed003b5c46c2 R11: ffff8801dae23613 R12: ffff8801c957f3c0
R13: ffff8801dae23610 R14: ffff8801c957f400 R15: dffffc0000000000
rcu_read_lock_sched_held+0x8d/0x120 kernel/rcu/update.c:112
trace_kmem_cache_alloc include/trace/events/kmem.h:54 [inline]
kmem_cache_alloc+0x5fa/0x760 mm/slab.c:3555
anon_vma_alloc mm/rmap.c:81 [inline]
__anon_vma_prepare+0x3b3/0x700 mm/rmap.c:189
anon_vma_prepare include/linux/rmap.h:153 [inline]
wp_page_copy+0xdf1/0x1440 mm/memory.c:2481
do_wp_page+0x425/0x1990 mm/memory.c:2776
handle_pte_fault mm/memory.c:3979 [inline]
__handle_mm_fault+0x2996/0x4310 mm/memory.c:4087
handle_mm_fault+0x53a/0xc70 mm/memory.c:4124
__do_page_fault+0x60b/0xe40 arch/x86/mm/fault.c:1399
do_page_fault+0xee/0x8a7 arch/x86/mm/fault.c:1474
page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1160
RIP: 0033:0x7f4232a6d1fb
RSP: 002b:00007fff2aeebd28 EFLAGS: 00010246
RAX: 000000000000000d RBX: 00000000756e6547 RCX: 000000006c65746e
RDX: 0000000049656e69 RSI: 0000000000000025 RDI: 0000000000000002
RBP: 00007fff2aeebe20 R08: 0000000000000001 R09: 000000000000002f
R10: 00007f4232a6caf0 R11: 00007fff2aeebb70 R12: 00007f4232a4e000
R13: 00007f4232dd5038 R14: 00007f4232a6cac0 R15: 00007f4232dd5d98
BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 126s!
BUG: workqueue lockup - pool cpus=0-1 flags=0x4 nice=0 stuck for 125s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=7/256
pending: defense_work_handler, defense_work_handler,
defense_work_handler, defense_work_handler, defense_work_handler,
vmstat_shepherd, cache_reap
workqueue events_power_efficient: flags=0x80
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
in-flight: 2107:neigh_periodic_work
workqueue mm_percpu_wq: flags=0x8
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
pending: vmstat_update
workqueue writeback: flags=0x4e
pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256
in-flight: 4784:wb_workfn
workqueue ib_addr: flags=0xa0002
workqueue dm_bufio_cache: flags=0x8
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
pending: work_fn
workqueue ipv6_addrconf: flags=0x40008
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/1
pending: addrconf_dad_work
delayed: addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_verify_work
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
pending: addrconf_dad_work
delayed: addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work
pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=0s workers=4 idle: 4707 24 4924
pool 4: cpus=0-1 flags=0x4 nice=0 hung=0s workers=4 idle: 44 4846 6
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next 8/9] net: hns3: Fixes kernel panic issue during rmmod hns3 driver
From: Salil Mehta @ 2018-05-19 15:53 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Xi Wang
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Xi Wang <wangxi11@huawei.com>
If CONFIG_ARM_SMMU_V3 is enabled, arm64's dma_ops will replace
arm64_swiotlb_dma_ops with iommu_dma_ops. When releasing contiguous
dma memory, the new ops will call the vunmap function which cannot
be run in interrupt context.
Currently, spin_lock_bh is called before vunmap is executed. This
disables BH and causes the interrupt context to be detected to
generate a kernel panic like below:
[ 2831.573400] kernel BUG at mm/vmalloc.c:1621!
[ 2831.577659] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
...
[ 2831.699907] Process rmmod (pid: 1893, stack limit = 0x0000000055103ee2)
[ 2831.706507] Call trace:
[ 2831.708941] vunmap+0x48/0x50
[ 2831.711897] dma_common_free_remap+0x78/0x88
[ 2831.716155] __iommu_free_attrs+0xa8/0x1c0
[ 2831.720255] hclge_free_cmd_desc+0xc8/0x118 [hclge]
[ 2831.725128] hclge_destroy_cmd_queue+0x34/0x68 [hclge]
[ 2831.730261] hclge_uninit_ae_dev+0x90/0x100 [hclge]
[ 2831.735127] hnae3_unregister_ae_dev+0xb0/0x868 [hnae3]
[ 2831.740345] hns3_remove+0x3c/0x90 [hns3]
[ 2831.744344] pci_device_remove+0x48/0x108
[ 2831.748342] device_release_driver_internal+0x164/0x200
[ 2831.753553] driver_detach+0x4c/0x88
[ 2831.757116] bus_remove_driver+0x60/0xc0
[ 2831.761026] driver_unregister+0x34/0x60
[ 2831.764935] pci_unregister_driver+0x30/0xb0
[ 2831.769197] hns3_exit_module+0x10/0x978 [hns3]
[ 2831.773715] SyS_delete_module+0x1f8/0x248
[ 2831.777799] el0_svc_naked+0x30/0x34
This patch fixes it by using spin_lock instead of spin_lock_bh.
Fixes: 68c0a5c70614 ("net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support")
Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 59fb0eb..c36d647 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -385,9 +385,9 @@ int hclge_cmd_init(struct hclge_dev *hdev)
static void hclge_destroy_queue(struct hclge_cmq_ring *ring)
{
- spin_lock_bh(&ring->lock);
+ spin_lock(&ring->lock);
hclge_free_cmd_desc(ring);
- spin_unlock_bh(&ring->lock);
+ spin_unlock(&ring->lock);
}
void hclge_destroy_cmd_queue(struct hclge_hw *hw)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 6/9] net: hns3: Use enums instead of magic number in hclge_is_special_opcode
From: Salil Mehta @ 2018-05-19 15:53 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Huazhong Tan
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
This patch does bit of a clean-up by using already defined enums for
certain values in function hclge_is_special_opcode(). Below enums from
have been used as replacements for magic values:
enum hclge_opcode_type{
<snip>
HCLGE_OPC_STATS_64_BIT = 0x0030,
HCLGE_OPC_STATS_32_BIT = 0x0031,
HCLGE_OPC_STATS_MAC = 0x0032,
<snip>
};
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index fab7068..59fb0eb 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -190,7 +190,11 @@ static int hclge_cmd_csq_done(struct hclge_hw *hw)
static bool hclge_is_special_opcode(u16 opcode)
{
- u16 spec_opcode[3] = {0x0030, 0x0031, 0x0032};
+ /* these commands have several descriptors,
+ * and use the first one to save opcode and return value
+ */
+ u16 spec_opcode[3] = {HCLGE_OPC_STATS_64_BIT,
+ HCLGE_OPC_STATS_32_BIT, HCLGE_OPC_STATS_MAC};
int i;
for (i = 0; i < ARRAY_SIZE(spec_opcode); i++) {
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 5/9] net: hns3: Fix for hns3 module is loaded multiple times problem
From: Salil Mehta @ 2018-05-19 15:53 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Xi Wang
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Xi Wang <wangxi11@huawei.com>
If the hns3 driver has been built into kernel and then loaded with
the same driver which built as KLM, it may trigger an error like
below:
[ 20.009555] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[ 20.016789] hns3: Copyright (c) 2017 Huawei Corporation.
[ 20.022100] Error: Driver 'hns3' is already registered, aborting...
[ 23.517397] Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
[ 23.691583] Process insmod (pid: 1982, stack limit = 0x00000000cd5f21cb)
[ 23.698270] Call trace:
[ 23.700705] __list_del_entry_valid+0x2c/0xd8
[ 23.705049] hnae3_unregister_client+0x68/0xa8
[ 23.709487] hns3_init_module+0x98/0x1000 [hns3]
[ 23.714093] do_one_initcall+0x5c/0x170
[ 23.717918] do_init_module+0x64/0x1f4
[ 23.721654] load_module+0x1d14/0x24b0
[ 23.725390] SyS_init_module+0x158/0x208
[ 23.729300] el0_svc_naked+0x30/0x34
This patch fixes it by adding module version info.
Fixes: 38caee9d3ee8 ("net: hns3: Add support of the HNAE3 framework")
Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 1 +
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 2 ++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 1 +
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 ++
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 2 +-
6 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index bd3c232..63d7dbf 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -285,3 +285,4 @@ EXPORT_SYMBOL(hnae3_unregister_ae_dev);
MODULE_AUTHOR("Huawei Tech. Co., Ltd.");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("HNAE3(Hisilicon Network Acceleration Engine) Framework");
+MODULE_VERSION(HNAE3_MOD_VERSION);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 2f266ef..45c571e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -36,6 +36,8 @@
#include <linux/pci.h>
#include <linux/types.h>
+#define HNAE3_MOD_VERSION "1.0"
+
/* Device IDs */
#define HNAE3_DEV_ID_GE 0xA220
#define HNAE3_DEV_ID_25GE 0xA221
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 701ae5e..cac5195 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3538,3 +3538,4 @@ MODULE_DESCRIPTION("HNS3: Hisilicon Ethernet Driver");
MODULE_AUTHOR("Huawei Tech. Co., Ltd.");
MODULE_LICENSE("GPL");
MODULE_ALIAS("pci:hns-nic");
+MODULE_VERSION(HNS3_MOD_VERSION);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 98cdbd3..5b40f5a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -14,6 +14,8 @@
#include "hnae3.h"
+#define HNS3_MOD_VERSION "1.0"
+
extern const char hns3_driver_version[];
enum hns3_nic_state {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index af736a4..93177d9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -17,7 +17,7 @@
#include "hclge_cmd.h"
#include "hnae3.h"
-#define HCLGE_MOD_VERSION "v1.0"
+#define HCLGE_MOD_VERSION "1.0"
#define HCLGE_DRIVER_NAME "hclge"
#define HCLGE_INVALID_VPORT 0xffff
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h
index a477a7c..9763e74 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h
@@ -9,7 +9,7 @@
#include "hclgevf_cmd.h"
#include "hnae3.h"
-#define HCLGEVF_MOD_VERSION "v1.0"
+#define HCLGEVF_MOD_VERSION "1.0"
#define HCLGEVF_DRIVER_NAME "hclgevf"
#define HCLGEVF_ROCEE_VECTOR_NUM 0
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 9/9] net: hns3: Fix for CMDQ and Misc. interrupt init order problem
From: Salil Mehta @ 2018-05-19 15:53 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
When vf module is loading, the cmd queue initialization should
happen before misc interrupt initialization, otherwise the misc
interrupt handle will cause using uninitialized cmd queue problem.
There is also the same issue when vf module is unloading.
This patch fixes it by adjusting the location of some function.
Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index f1f4a17..2b0e329 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1634,6 +1634,10 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
hclgevf_state_init(hdev);
+ ret = hclgevf_cmd_init(hdev);
+ if (ret)
+ goto err_cmd_init;
+
ret = hclgevf_misc_irq_init(hdev);
if (ret) {
dev_err(&pdev->dev, "failed(%d) to init Misc IRQ(vector0)\n",
@@ -1641,10 +1645,6 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
goto err_misc_irq_init;
}
- ret = hclgevf_cmd_init(hdev);
- if (ret)
- goto err_cmd_init;
-
ret = hclgevf_configure(hdev);
if (ret) {
dev_err(&pdev->dev, "failed(%d) to fetch configuration\n", ret);
@@ -1692,10 +1692,10 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
return 0;
err_config:
- hclgevf_cmd_uninit(hdev);
-err_cmd_init:
hclgevf_misc_irq_uninit(hdev);
err_misc_irq_init:
+ hclgevf_cmd_uninit(hdev);
+err_cmd_init:
hclgevf_state_uninit(hdev);
hclgevf_uninit_msi(hdev);
err_irq_init:
@@ -1705,9 +1705,9 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
static void hclgevf_uninit_hdev(struct hclgevf_dev *hdev)
{
- hclgevf_cmd_uninit(hdev);
- hclgevf_misc_irq_uninit(hdev);
hclgevf_state_uninit(hdev);
+ hclgevf_misc_irq_uninit(hdev);
+ hclgevf_cmd_uninit(hdev);
hclgevf_uninit_msi(hdev);
hclgevf_pci_uninit(hdev);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 7/9] net: hns3: Fix for netdev not running problem after calling net_stop and net_open
From: Salil Mehta @ 2018-05-19 15:53 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
The link status update function is called by timer every second. But
net_stop and net_open may be called with very short intervals. The link
status update function can not detect the link state has changed. It
causes the netdev not running problem.
This patch fixes it by updating the link state in ae_stop function.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 46e030c..2f0bbb6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3793,6 +3793,9 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
/* reset tqp stats */
hclge_reset_tqp_stats(handle);
+ del_timer_sync(&hdev->service_timer);
+ cancel_work_sync(&hdev->service_task);
+ hclge_update_link_status(hdev);
}
static int hclge_get_mac_vlan_cmd_status(struct hclge_vport *vport,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 4/9] net: hns3: Fix the missing client list node initialization
From: Salil Mehta @ 2018-05-19 15:53 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Xi Wang
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Xi Wang <wangxi11@huawei.com>
This patch fixes the missing initialization of the client list node
in the hnae3_register_client() function.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 66cbb66..701ae5e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3509,6 +3509,8 @@ static int __init hns3_init_module(void)
client.ops = &client_ops;
+ INIT_LIST_HEAD(&client.node);
+
ret = hnae3_register_client(&client);
if (ret)
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/9] net: hns3: cleanup of return values in hclge_init_client_instance()
From: Salil Mehta @ 2018-05-19 15:53 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Jian Shen
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
Removes the goto and directly returns in case of errors as part of the
cleanup.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 46435c8..46e030c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5297,7 +5297,7 @@ static int hclge_init_client_instance(struct hnae3_client *client,
vport->nic.client = client;
ret = client->ops->init_instance(&vport->nic);
if (ret)
- goto err;
+ return ret;
if (hdev->roce_client &&
hnae3_dev_roce_supported(hdev)) {
@@ -5305,11 +5305,11 @@ static int hclge_init_client_instance(struct hnae3_client *client,
ret = hclge_init_roce_base_info(vport);
if (ret)
- goto err;
+ return ret;
ret = rc->ops->init_instance(&vport->roce);
if (ret)
- goto err;
+ return ret;
}
break;
@@ -5319,7 +5319,7 @@ static int hclge_init_client_instance(struct hnae3_client *client,
ret = client->ops->init_instance(&vport->nic);
if (ret)
- goto err;
+ return ret;
break;
case HNAE3_CLIENT_ROCE:
@@ -5331,18 +5331,16 @@ static int hclge_init_client_instance(struct hnae3_client *client,
if (hdev->roce_client && hdev->nic_client) {
ret = hclge_init_roce_base_info(vport);
if (ret)
- goto err;
+ return ret;
ret = client->ops->init_instance(&vport->roce);
if (ret)
- goto err;
+ return ret;
}
}
}
return 0;
-err:
- return ret;
}
static void hclge_uninit_client_instance(struct hnae3_client *client,
--
2.7.4
^ permalink raw reply related
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