* Re: [PATCH net-next 2/3] net: dsa: mv88e6xxx: Add minimal platform_data support
From: Florian Fainelli @ 2018-05-19 22:52 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: Vivien Didelot, netdev
In-Reply-To: <1526761895-15839-3-git-send-email-andrew@lunn.ch>
On 05/19/2018 01:31 PM, Andrew Lunn wrote:
> 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>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
There is a bit of overlap with your net_device structure and what
dsa_chip_data includes, but this is fine for now.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mv88e6xxx: Remove OF check for IRQ domain
From: Florian Fainelli @ 2018-05-19 22:47 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: Vivien Didelot, netdev
In-Reply-To: <1526761895-15839-2-git-send-email-andrew@lunn.ch>
On 05/19/2018 01:31 PM, Andrew Lunn wrote:
> 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>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 14/14] net: sched: implement delete for all actions
From: Marcelo Ricardo Leitner @ 2018-05-19 22:45 UTC (permalink / raw)
To: Vlad Buslov
Cc: Jiri Pirko, netdev, davem, jhs, xiyou.wangcong, pablo, kadlec, fw,
ast, daniel, edumazet, keescook, linux-kernel, netfilter-devel,
coreteam, kliteyn
In-Reply-To: <vbf7eo32a7l.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Wed, May 16, 2018 at 12:58:38PM +0300, Vlad Buslov wrote:
>
> On Wed 16 May 2018 at 09:48, Jiri Pirko <jiri@resnulli.us> wrote:
> > Mon, May 14, 2018 at 04:27:15PM CEST, vladbu@mellanox.com wrote:
> >>Implement delete function that is required to delete actions without
> >>holding rtnl lock. Use action API function that atomically deletes action
> >>only if it is still in action idr. This implementation prevents concurrent
> >>threads from deleting same action twice.
> >>
> >>Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
> >>---
> >> net/sched/act_bpf.c | 8 ++++++++
> >> net/sched/act_connmark.c | 8 ++++++++
> >> net/sched/act_csum.c | 8 ++++++++
> >> net/sched/act_gact.c | 8 ++++++++
> >> net/sched/act_ife.c | 8 ++++++++
> >> net/sched/act_ipt.c | 16 ++++++++++++++++
> >> net/sched/act_mirred.c | 8 ++++++++
> >> net/sched/act_nat.c | 8 ++++++++
> >> net/sched/act_pedit.c | 8 ++++++++
> >> net/sched/act_police.c | 8 ++++++++
> >> net/sched/act_sample.c | 8 ++++++++
> >> net/sched/act_simple.c | 8 ++++++++
> >> net/sched/act_skbedit.c | 8 ++++++++
> >> net/sched/act_skbmod.c | 8 ++++++++
> >> net/sched/act_tunnel_key.c | 8 ++++++++
> >> net/sched/act_vlan.c | 8 ++++++++
> >> 16 files changed, 136 insertions(+)
> >>
> >>diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
> >>index 0bf4ecf..36f7f66 100644
> >>--- a/net/sched/act_bpf.c
> >>+++ b/net/sched/act_bpf.c
> >>@@ -394,6 +394,13 @@ static int tcf_bpf_search(struct net *net, struct tc_action **a, u32 index,
> >> return tcf_idr_search(tn, a, index);
> >> }
> >>
> >>+static int tcf_bpf_delete(struct net *net, u32 index)
> >>+{
> >>+ struct tc_action_net *tn = net_generic(net, bpf_net_id);
> >>+
> >>+ return tcf_idr_find_delete(tn, index);
> >>+}
> >>+
> >> static struct tc_action_ops act_bpf_ops __read_mostly = {
> >> .kind = "bpf",
> >> .type = TCA_ACT_BPF,
> >>@@ -404,6 +411,7 @@ static struct tc_action_ops act_bpf_ops __read_mostly = {
> >> .init = tcf_bpf_init,
> >> .walk = tcf_bpf_walker,
> >> .lookup = tcf_bpf_search,
> >>+ .delete = tcf_bpf_delete,
> >
> > I wonder, right before this patch, how the idr index got removed?
> > delete op is NULL and I didn't find anyone else to do it.
AFAICT this also means it is leaking idr's till this patch is applied.
Maybe I missed something.
> >
> > Also, after this patch, does it make sense to have following check in
> > tcf_action_del_1()?
> >
> > if (ops->delete)
> > err = ops->delete(net, index);
> >
> > Looks like ops->delete is non-null for all.
> >
> > Seems to me that you need to introduce this patch filling up the delete
> > op in all acts and only after that introduce a code that actually calls
> > it.
>
> Already moved this for V2 patchset to:
> - Add delete callback to ops and implement it for all actions in single
> patch.
> - Move this patch before delete first use.
>
> Will now remove the conditional as well.
>
> >
> > [...]
>
^ permalink raw reply
* Re: [PATCH 12/14] net: sched: retry action check-insert on concurrent modification
From: Marcelo Ricardo Leitner @ 2018-05-19 22:35 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: <20180516132135.GN1972@nanopsycho>
On Wed, May 16, 2018 at 03:21:35PM +0200, Jiri Pirko wrote:
...
> int tcf_idr_check_alloc(struct tc_action_net *tn, u32 *index,
> struct tc_action **a, int bind)
Considering we don't have any other variant of it, maybe just
"tcf_idr_alloc()" instead?
^ permalink raw reply
* Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions
From: Marcelo Ricardo Leitner @ 2018-05-19 22:20 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-14-git-send-email-vladbu@mellanox.com>
On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote:
> Substitute calls to action insert function with calls to action insert
> unique function that warns if insertion overwrites index in idr.
I know this patch may be gone on V2, but a general comment, please use
the function names themselves instead of a textualized version. I.e.,
s/action insert unique/tcf_idr_insert_unique/
^ permalink raw reply
* Re: [PATCH 10/14] net: sched: extend act API for lockless actions
From: Marcelo Ricardo Leitner @ 2018-05-19 22:17 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-11-git-send-email-vladbu@mellanox.com>
Please use a more meaningful patch summary. This one is too generic.
On Mon, May 14, 2018 at 05:27:11PM +0300, Vlad Buslov wrote:
...
> +int tcf_idr_find_delete(struct tc_action_net *tn, u32 index)
What about naming it tcf_idr_delete_index() instead?
The find operation is always implicit when you don't specify the
object itself directly, and then it describes which key will be used.
> +{
> + struct tcf_idrinfo *idrinfo = tn->idrinfo;
> + struct tc_action *p;
> + int ret = 0;
> +
> + spin_lock_bh(&idrinfo->lock);
> + p = idr_find(&idrinfo->action_idr, index);
> + if (!p) {
> + spin_unlock(&idrinfo->lock);
> + return -ENOENT;
> + }
> +
> + if (!atomic_read(&p->tcfa_bindcnt)) {
> + if (refcount_dec_and_test(&p->tcfa_refcnt)) {
> + struct module *owner = p->ops->owner;
> +
> + WARN_ON(p != idr_remove(&idrinfo->action_idr,
> + p->tcfa_index));
> + spin_unlock_bh(&idrinfo->lock);
> +
> + tcf_action_cleanup(p);
> + module_put(owner);
> + return 0;
> + }
> + ret = 0;
> + } else {
> + ret = -EPERM;
> + }
> +
> + spin_unlock_bh(&idrinfo->lock);
> + return ret;
> +}
> +EXPORT_SYMBOL(tcf_idr_find_delete);
...
^ permalink raw reply
* Re: [PATCH 09/14] net: sched: don't release reference on action overwrite
From: Marcelo Ricardo Leitner @ 2018-05-19 21:52 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-10-git-send-email-vladbu@mellanox.com>
On Mon, May 14, 2018 at 05:27:10PM +0300, Vlad Buslov wrote:
> Return from action init function with reference to action taken,
> even when overwriting existing action.
Isn't this patch necessary before patch 7, to not break things up?
AFAICU after patchset 7 it assumes the action init function is already
behaving like this.
^ permalink raw reply
* Re: [PATCH 06/14] net: sched: implement reference counted action release
From: Marcelo Ricardo Leitner @ 2018-05-19 21:43 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-7-git-send-email-vladbu@mellanox.com>
On Mon, May 14, 2018 at 05:27:07PM +0300, Vlad Buslov wrote:
...
> @@ -1052,6 +1088,36 @@ static int tca_action_flush(struct net *net, struct nlattr *nla,
> return err;
> }
>
> +static int tcf_action_delete(struct net *net, struct list_head *actions,
> + struct netlink_ext_ack *extack)
> +{
> + int ret;
Reverse christmass tree.. this line should be the last in variable
declarations.
> + struct tc_action *a, *tmp;
> + char kind[IFNAMSIZ];
> + u32 act_index;
> +
> + list_for_each_entry_safe(a, tmp, actions, list) {
> + const struct tc_action_ops *ops = a->ops;
> +
> + /* Actions can be deleted concurrently
> + * so we must save their type and id to search again
> + * after reference is released.
> + */
> + strncpy(kind, a->ops->kind, sizeof(kind) - 1);
This may be problematic. Why strncpy here?
a->ops->kind is also of size IFNAMSIZ. If a->ops->kind is actually
IFNAMSIZ-1 long, kind here won't be NULL terminated, as kind is not
initialized and strncpy won't add the NULL.
> + act_index = a->tcfa_index;
> +
> + list_del(&a->list);
> + if (tcf_action_put(a))
> + module_put(ops->owner);
> +
> + /* now do the delete */
> + ret = tcf_action_del_1(net, kind, act_index, extack);
> + if (ret < 0)
> + return ret;
> + }
> + return 0;
> +}
^ permalink raw reply
* 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
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