* [PATCH] net: stmmac: do not call phy_ethtool_ksettings_set from atomic context
From: Niklas Cassel @ 2016-12-06 13:47 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue; +Cc: Niklas Cassel, netdev, linux-kernel
From: Niklas Cassel <niklas.cassel@axis.com>
>From what I can tell, spin_lock(&priv->lock) is not needed, since the
phy_ethtool_ksettings_set call is not given the priv struct.
phy_start_aneg takes the phydev->lock. Calls to phy_adjust_link
from phy_state_machine also takes the phydev->lock.
[ 13.718319] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
[ 13.726717] in_atomic(): 1, irqs_disabled(): 0, pid: 1307, name: ethtool
[ 13.742115] Hardware name: Axis ARTPEC-6 Platform
[ 13.746829] [<80110568>] (unwind_backtrace) from [<8010c2bc>] (show_stack+0x18/0x1c)
[ 13.754575] [<8010c2bc>] (show_stack) from [<80433484>] (dump_stack+0x80/0xa0)
[ 13.761801] [<80433484>] (dump_stack) from [<80145428>] (___might_sleep+0x108/0x170)
[ 13.769554] [<80145428>] (___might_sleep) from [<806c9b50>] (mutex_lock+0x24/0x44)
[ 13.777128] [<806c9b50>] (mutex_lock) from [<8050cbc0>] (phy_start_aneg+0x1c/0x13c)
[ 13.784783] [<8050cbc0>] (phy_start_aneg) from [<8050d338>] (phy_ethtool_ksettings_set+0x98/0xd0)
[ 13.793656] [<8050d338>] (phy_ethtool_ksettings_set) from [<80517adc>] (stmmac_ethtool_set_link_ksettings+0xa0/0xb4)
[ 13.804184] [<80517adc>] (stmmac_ethtool_set_link_ksettings) from [<805c5138>] (ethtool_set_settings+0xd4/0x13c)
[ 13.814358] [<805c5138>] (ethtool_set_settings) from [<805c9718>] (dev_ethtool+0x13c4/0x211c)
[ 13.822882] [<805c9718>] (dev_ethtool) from [<805dc7c0>] (dev_ioctl+0x480/0x8e0)
[ 13.830291] [<805dc7c0>] (dev_ioctl) from [<80260e34>] (do_vfs_ioctl+0x94/0xa00)
[ 13.837699] [<80260e34>] (do_vfs_ioctl) from [<802617dc>] (SyS_ioctl+0x3c/0x60)
[ 13.845011] [<802617dc>] (SyS_ioctl) from [<801088bc>] (__sys_trace_return+0x0/0x10)
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index d5a8122b6033..6ab7e2bdcadd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -406,9 +406,7 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
return 0;
}
- spin_lock(&priv->lock);
rc = phy_ethtool_ksettings_set(phy, cmd);
- spin_unlock(&priv->lock);
return rc;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH]net:sched:release lock before tcf_dump_walker() normal return to avoid deadlock
From: Jamal Hadi Salim @ 2016-12-06 13:50 UTC (permalink / raw)
To: Feng Deng, David S. Miller
Cc: netdev, linux-kernel, feng.deng, Roman Mashak, Cong Wang
In-Reply-To: <CAEX1niWim7BSki6uRtihwbJ3Adw4Qwt8MR1aki8UA4_x7V9UTA@mail.gmail.com>
On 16-12-06 12:36 AM, Feng Deng wrote:
> From: Feng Deng<cxdx2006@gmail.com>
>
> release lock before tcf_dump_walker() normal return to avoid deadlock
>
/Scratching my head.
I am probably missing something obvious.
What are the condition under which this deadlock will happen?
Do you have a testcase we can try?
cheers,
jamal
^ permalink raw reply
* [PATCH net-next v2 1/1] driver: ipvlan: Free ipvl_port directly with kfree instead of kfree_rcu
From: fgao @ 2016-12-06 13:54 UTC (permalink / raw)
To: davem, maheshb, edumazet, netdev, gfree.wind
From: Gao Feng <gfree.wind@gmail.com>
There is no one which may reference the ipvlan port when free it in
ipvlan_port_create and ipvlan_port_destroy. So it is unnecessary to
use kfree_rcu.
Signed-off-by: Gao Feng <gfree.wind@gmail.com>
---
v2: Remove the rcu of ipvl_port directly
v1: Initial version
drivers/net/ipvlan/ipvlan.h | 1 -
drivers/net/ipvlan/ipvlan_main.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan.h b/drivers/net/ipvlan/ipvlan.h
index 05a62d2..031093e 100644
--- a/drivers/net/ipvlan/ipvlan.h
+++ b/drivers/net/ipvlan/ipvlan.h
@@ -97,7 +97,6 @@ struct ipvl_port {
struct work_struct wq;
struct sk_buff_head backlog;
int count;
- struct rcu_head rcu;
};
static inline struct ipvl_port *ipvlan_port_get_rcu(const struct net_device *d)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index c6aa667..44ceebc 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -128,7 +128,7 @@ static int ipvlan_port_create(struct net_device *dev)
return 0;
err:
- kfree_rcu(port, rcu);
+ kfree(port);
return err;
}
@@ -145,7 +145,7 @@ static void ipvlan_port_destroy(struct net_device *dev)
netdev_rx_handler_unregister(dev);
cancel_work_sync(&port->wq);
__skb_queue_purge(&port->backlog);
- kfree_rcu(port, rcu);
+ kfree(port);
}
#define IPVLAN_FEATURES \
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 2/3] net/sched: cls_flower: Add support for matching on flags
From: Or Gerlitz @ 2016-12-06 14:02 UTC (permalink / raw)
To: Jiri Pirko; +Cc: David S. Miller, netdev, Jiri Pirko, Roi Dayan, Hadar Har-Zion
In-Reply-To: <20161206124006.GL1984@nanopsycho>
On 12/6/2016 2:40 PM, Jiri Pirko wrote:
> Tue, Dec 06, 2016 at 01:32:58PM CET, ogerlitz@mellanox.com wrote:
>> Add UAPI to provide set of flags for matching, where the flags
>> provided from user-space are mapped to flow-dissector flags.
>>
>> The 1st flag allows to match on whether the packet is an
>> IP fragment and corresponds to the FLOW_DIS_IS_FRAGMENT flag.
>>
>> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>> Reviewed-by: Paul Blakey <paulb@mellanox.com>
>> ---
>> include/uapi/linux/pkt_cls.h | 7 ++++
>> net/sched/cls_flower.c | 83 ++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 90 insertions(+)
>>
>> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>> index 86786d4..f114277 100644
>> --- a/include/uapi/linux/pkt_cls.h
>> +++ b/include/uapi/linux/pkt_cls.h
>> @@ -457,11 +457,18 @@ enum {
>> TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK, /* be16 */
>> TCA_FLOWER_KEY_ENC_UDP_DST_PORT, /* be16 */
>> TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK, /* be16 */
>> +
>> + TCA_FLOWER_KEY_FLAGS, /* be32 */
>> + TCA_FLOWER_KEY_FLAGS_MASK, /* be32 */
>> __TCA_FLOWER_MAX,
>> };
>>
>> #define TCA_FLOWER_MAX (__TCA_FLOWER_MAX - 1)
>>
>> +enum {
>> + TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT = BIT(0),
>> +};
>> +
>> /* Match-all classifier */
>>
>> enum {
>> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
>> index c5cea78..d9f4124 100644
>> --- a/net/sched/cls_flower.c
>> +++ b/net/sched/cls_flower.c
>> @@ -383,6 +383,8 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
>> [TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK] = { .type = NLA_U16 },
>> [TCA_FLOWER_KEY_ENC_UDP_DST_PORT] = { .type = NLA_U16 },
>> [TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK] = { .type = NLA_U16 },
>> + [TCA_FLOWER_KEY_FLAGS] = { .type = NLA_U32 },
>> + [TCA_FLOWER_KEY_FLAGS_MASK] = { .type = NLA_U32 },
>> };
>>
>> static void fl_set_key_val(struct nlattr **tb,
>> @@ -417,6 +419,40 @@ static void fl_set_key_vlan(struct nlattr **tb,
>> }
>> }
>>
>> +static void set_flags(u32 flower_key, u32 flower_mask,
> Use some prefix for helpers like this, or at least __
okay, will use fl_set_key_flags here
>
>
>> + u32 *dissector_key, u32 *dissector_mask,
>> + u32 flower_flag_bit, u32 dissector_flag_bit)
>> +{
>> + if (flower_mask & flower_flag_bit) {
>> + *dissector_mask |= dissector_flag_bit;
>> + if (flower_key & flower_flag_bit)
>> + *dissector_key |= dissector_flag_bit;
>> + }
>> +}
>> +
>> +static void fl_set_key_flags(struct nlattr **tb,
>> + u32 *flags_key,
>> + u32 *flags_mask)
>> +{
>> + u32 key, mask;
>> +
>> + if (!tb[TCA_FLOWER_KEY_FLAGS])
>> + return;
>> +
>> + key = be32_to_cpu(nla_get_u32(tb[TCA_FLOWER_KEY_FLAGS]));
>> +
>> + if (!tb[TCA_FLOWER_KEY_FLAGS_MASK])
>> + mask = ~0;
>> + else
>> + mask = be32_to_cpu(nla_get_u32(tb[TCA_FLOWER_KEY_FLAGS_MASK]));
>> +
>> + *flags_key = 0;
>> + *flags_mask = 0;
>> +
>> + set_flags(key, mask, flags_key, flags_mask,
>> + TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT, FLOW_DIS_IS_FRAGMENT);
>> +}
>> +
>> static int fl_set_key(struct net *net, struct nlattr **tb,
>> struct fl_flow_key *key, struct fl_flow_key *mask)
>> {
>> @@ -543,6 +579,8 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
>> &mask->enc_tp.dst, TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK,
>> sizeof(key->enc_tp.dst));
>>
>> + fl_set_key_flags(tb, &key->control.flags, &mask->control.flags);
>> +
>> return 0;
>> }
>>
>> @@ -877,6 +915,48 @@ static int fl_dump_key_vlan(struct sk_buff *skb,
>> return 0;
>> }
>>
>> +static void get_flags(u32 dissector_key, u32 dissector_mask,
> Same here.
and fl_get_key_flags here
>
>> + u32 *flower_key, u32 *flower_mask,
>> + u32 flower_flag_bit, u32 dissector_flag_bit)
>> +{
>> + if (dissector_mask & dissector_flag_bit) {
>> + *flower_mask |= flower_flag_bit;
>> + if (dissector_key & dissector_flag_bit)
>> + *flower_key |= flower_flag_bit;
>> + }
>> +}
>> +
>> +static int fl_dump_key_flags(struct sk_buff *skb,
>> + u32 flags_key,
>> + u32 flags_mask)
> over-wrapped :)
okay,
>
>> +{
>> + u32 key, mask;
>> + __be32 _key, _mask;
>> + int err;
>> +
>> + if (!memchr_inv(&flags_mask, 0, sizeof(flags_mask)))
>> + return 0;
>> +
>> + key = 0;
> ^ remove the extra space
okay
>
>> + mask = 0;
>> +
>> + get_flags(flags_key, flags_mask, &key, &mask,
>> + TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT, FLOW_DIS_IS_FRAGMENT);
>> +
>> + _key = cpu_to_be32(key);
> ^ remove the extra space
NP
>
>> + _mask = cpu_to_be32(mask);
>> +
>> + err = nla_put(skb, TCA_FLOWER_KEY_FLAGS, 4, &_key);
>> + if (err)
>> + return err;
>> +
>> + err = nla_put(skb, TCA_FLOWER_KEY_FLAGS_MASK, 4, &_mask);
> Just return nla_put...
sure
^ permalink raw reply
* Re: [PATCH] net:mv88e6xxx: dispose irq mapping
From: Andrew Lunn @ 2016-12-06 14:19 UTC (permalink / raw)
To: Volodymyr Bendiuga; +Cc: vivien.didelot, f.fainelli, netdev
In-Reply-To: <1481018743-27208-1-git-send-email-volodymyr.bendiuga@westermo.se>
On Tue, Dec 06, 2016 at 11:05:43AM +0100, Volodymyr Bendiuga wrote:
> If this is not done, then it is not possible to map
> irq next time, after EPROBE_DEFER.
>
> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@westermo.se>
Hi Volodymyr
Thanks for your patches.
Please could you include in the subject line which tree it is for. See
Documentation/networking/netdev-FAQ.txt
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 05942e3..12e7d38 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -420,6 +420,7 @@ static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip *chip)
> mv88e6xxx_g1_write(chip, GLOBAL_CONTROL, mask);
>
> free_irq(chip->irq, chip);
> + irq_dispose_mapping(chip->irq);
This seems like the wrong place to do this.
The mapping is created by chip->irq = of_irq_get(np, 0); in
mv88e6xxx_probe(). So the correct place to dispose of this mapping would be in
mv88e6xxx_remove() and the error path of mv88e6xxx_probe().
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] flow dissector: ICMP support
From: Simon Horman @ 2016-12-06 14:23 UTC (permalink / raw)
To: Jiri Pirko
Cc: Tom Herbert, David Miller, Linux Kernel Network Developers,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, Jamal Hadi Salim,
Jiri Pirko
In-Reply-To: <20161206122634.GH1984@nanopsycho>
On Tue, Dec 06, 2016 at 01:26:34PM +0100, Jiri Pirko wrote:
> Tue, Dec 06, 2016 at 11:51:46AM CET, simon.horman@netronome.com wrote:
> >On Mon, Dec 05, 2016 at 09:29:45AM -0800, Tom Herbert wrote:
> >> On Mon, Dec 5, 2016 at 6:23 AM, Simon Horman <simon.horman@netronome.com> wrote:
> >> > On Sat, Dec 03, 2016 at 10:52:32AM -0800, Tom Herbert wrote:
> >> >> On Sat, Dec 3, 2016 at 2:49 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> >> >> > Fri, Dec 02, 2016 at 09:31:41PM CET, simon.horman@netronome.com wrote:
> >> >> >>Allow dissection of ICMP(V6) type and code. This re-uses transport layer
> >> >> >>port dissection code as although ICMP is not a transport protocol and their
> >> >> >>type and code are not ports this allows sharing of both code and storage.
> >> >> >>
> >> >> >>Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >> >
> >> > ...
> >> >
> >> >> > Digging into this a bit more. I think it would be much nice not to mix
> >> >> > up l4 ports and icmp stuff.
> >> >> >
> >> >> > How about to have FLOW_DISSECTOR_KEY_ICMP
> >> >> > and
> >> >> > struct flow_dissector_key_icmp {
> >> >> > u8 type;
> >> >> > u8 code;
> >> >> > };
> >> >> >
> >> >> > The you can make this structure and struct flow_dissector_key_ports into
> >> >> > an union in struct flow_keys.
> >> >> >
> >> >> > Looks much cleaner to me.
> >> >
> >> > Hi Jiri,
> >> >
> >> > I wondered about that too. The main reason that I didn't do this the first
> >> > time around is that I wasn't sure what to do to differentiate between ports
> >> > and icmp in fl_init_dissector() given that using a union would could to
> >> > mask bits being set in both if they are set in either.
> >> >
> >> > I've taken a stab at addressing that below along with implementing your
> >> > suggestion. If the treatment in fl_init_dissector() is acceptable
> >> > perhaps something similar should be done for FLOW_DISSECTOR_KEY_IPV[46]_ADDRS
> >> > too?
> >> >
> >> >> I agree, this patch adds to many conditionals into the fast path for
> >> >> ICMP handling. Neither is there much point in using type and code as
> >> >> input to the packet hash.
> >> >
> >> > Hi Tom,
> >> >
> >> > I'm not sure that I follow this. A packet may be ICMP or not regardless of
> >> > if FLOW_DISSECTOR_KEY_PORT (and now FLOW_DISSECTOR_KEY_ICMP) port is set or
> >> > not. I'd appreciate some guidance here.
> >> >
> >> > First-pass at implementing Jiri's suggestion follows:
> >> >
> >
> >...
> >
> >> > diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> >> > index 0584b4bb4390..33e5fa2b3e87 100644
> >> > --- a/net/core/flow_dissector.c
> >> > +++ b/net/core/flow_dissector.c
> >
> >...
> >
> >> > @@ -975,6 +983,10 @@ static const struct flow_dissector_key flow_keys_dissector_keys[] = {
> >> > .offset = offsetof(struct flow_keys, ports),
> >> > },
> >> > {
> >> > + .key_id = FLOW_DISSECTOR_KEY_ICMP,
> >> > + .offset = offsetof(struct flow_keys, icmp),
> >> > + },
> >>
> >> This is the problem I was referring to. This adds ICMP to the keys for
> >> computing the skb hash and the ICMP type and code are in a union with
> >> port numbers so they are in the range over which the hash is computed.
> >> This means that we are treating type and code as some sort of flow and
> >> and so different type/code between the same src/dst could follow
> >> different paths in ECMP. For the purposes of computing a packet hash I
> >> don't think we want ICMP information included. This might be a matter
> >> of not putting FLOW_DISSECTOR_KEY_ICMP in flow_keys_dissector_keys,
> >> where we need this information we could define another structure that
> >> has all the same fields as in flow_keys_dissector_keys and include
> >> FLOW_DISSECTOR_KEY_ICMP. Alternatively, the flow_dissector_key_icmp
> >> could also be outside of the area that is used in the hash: that is no
> >> in flow_keys_hash_start(keys) to flow_keys_hash_length(keys), keyval);
> >
> >...
> >
> >> > diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> >> > index c96b2a349779..f4ba69bd362f 100644
> >> > --- a/net/sched/cls_flower.c
> >> > +++ b/net/sched/cls_flower.c
> >> > @@ -38,7 +38,10 @@ struct fl_flow_key {
> >> > struct flow_dissector_key_ipv4_addrs ipv4;
> >> > struct flow_dissector_key_ipv6_addrs ipv6;
> >> > };
> >> > - struct flow_dissector_key_ports tp;
> >> > + union {
> >> > + struct flow_dissector_key_ports tp;
> >> > + struct flow_dissector_key_icmp icmp;
> >> > + };
> >>
> >> When an ICMP packet is encapsulated within UDP then icmp overwrites
> >> valid port information with is a stronger signal of the flow (unless
> >> FLOW_DISSECTOR_F_STOP_AT_ENCAP is set). This is another reason not to
> >> use a union with ports.
> >
> >...
> >
> >Hi Tom,
> >
> >thanks for your explanation. I think I have a clearer picture now.
> >
> >I have reworked things to try to address your concerns.
> >In particular:
> >
> >* FLOW_DISSECTOR_KEY_ICMP is no longer added to flow_keys_dissector_keys.
> > I don't think it is needed at all for the use-case I currently have in
> > mind, which is classifying packets using tc_flower. And adding it there
> > was an error on my part.
>
> I was just about to ask why you are adding it there. Good.
>
>
> >
> >* I stopped using a union for ports and icmp. At the very least this seems
> > to make it easier to reason about things as we no longer need to consider
> > that a port value may in fact be an ICMP type or code.
>
> This should be within csl_flower code. You can easily have it as a union
> in struct fl_flow_key.
Ok, will do.
> > This seems to allow us avoid adding a number of is_icmp checks (as I believe
> > you pointed out earlier). And should also address the problem you state
> > immediately above.
>
> I don't understand the check you are talking about. The union just allow
> to share the mem. I don't see any checks needed.
I meant the checks that the patchset adds were in bond_main.c and
other places before accessing the ports fields. I now see we can avoid them
while still using a union.
> >* I have also placed icmp outside of the range flow_keys_hash_start(keys)
> > to flow_keys_hash_length(keys), keyval). This is because I now see no
> > value of having it inside that range and it both avoids any chance of
> > contaminating the hash with ICMP values and hashing over unwanted
> > (hopefully zero) values.
>
> Okay, now I'm confused again. You don't want to add this to
> flow_keys_dissector_keys. Why would you?
Sorry, I think it was me that was being confused. I'll drop that change.
I agree it should not be necessary.
^ permalink raw reply
* Re: [PATCH] dsa:mv88e6xxx: allow address 0x1 in smi_init
From: Andrew Lunn @ 2016-12-06 14:27 UTC (permalink / raw)
To: Volodymyr Bendiuga; +Cc: vivien.didelot, f.fainelli, netdev, volodymyr.bendiuga
In-Reply-To: <1481029592-19496-1-git-send-email-volodymyr.bendiuga@westermo.se>
On Tue, Dec 06, 2016 at 02:06:32PM +0100, Volodymyr Bendiuga wrote:
> Westermo devices use this address.
I think we can have a better change log entry than that. How about:
Some devices, such as the mv88e6097 do have ADDR[0] external and so it
is possible to configure the device to use SMI address 0x1. Remove the
restriction, as there are boards using this address.
Thanks
Andrew
>
> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@westermo.se>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 4212fb6..05942e3 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -4253,10 +4253,6 @@ static void mv88e6xxx_phy_destroy(struct mv88e6xxx_chip *chip)
> static int mv88e6xxx_smi_init(struct mv88e6xxx_chip *chip,
> struct mii_bus *bus, int sw_addr)
> {
> - /* ADDR[0] pin is unavailable externally and considered zero */
> - if (sw_addr & 0x1)
> - return -EINVAL;
> -
> if (sw_addr == 0)
> chip->smi_ops = &mv88e6xxx_smi_single_chip_ops;
> else if (mv88e6xxx_has(chip, MV88E6XXX_FLAGS_MULTI_CHIP))
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH]net:switchdev:add judgement and proper return vlaue to make switchdev_port_vlan_fill() more robust
From: David Miller @ 2016-12-06 14:32 UTC (permalink / raw)
To: jiri; +Cc: cxdx2006, netdev, linux-kernel, feng.deng
In-Reply-To: <20161206123225.GK1984@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 6 Dec 2016 13:32:25 +0100
> Tue, Dec 06, 2016 at 05:46:36AM CET, cxdx2006@gmail.com wrote:
>>From: Feng Deng<cxdx2006@gmail.com>
>>
>>1.add judgement to make sure switchdev_port_vlan_fill() could
>> return right, even when switchdev_port_vlan_dump_put() failed ,
>> which will make switchdev_port_vlan_fill() more robust
>>2.add proper return vlaue at the end of the switchdev_port_vlan_fill()
>>
>>Signed-off-by: Feng Deng <feng.deng@cortina-access.com>
>
> Please don't send patches like this. You are wasting everyone's time.
+1
^ permalink raw reply
* Re: [PATCH] net/udp: do not touch skb->peeked unless really needed
From: Eric Dumazet @ 2016-12-06 14:34 UTC (permalink / raw)
To: Paolo Abeni; +Cc: David Miller, netdev, Willem de Bruijn
In-Reply-To: <1481017989.6225.21.camel@redhat.com>
On Tue, 2016-12-06 at 10:53 +0100, Paolo Abeni wrote:
> Hi Eric,
> I don't understand why we can avoid setting skb->peek if len > 0. I
> think that will change the kernel behavior if:
> - peek with offset is set
> - 3 skbs with len > 0 are enqueued
> - the u/s peek (with offset) the second one
> - the u/s disable peeking with offset and peeks 2 more skbs.
>
> With the current code in the last step the u/s is going to peek the 1#
> and the 3# skbs, after this patch will peek the 1# and the 2#. Am I
> missing something ? Probably the new behavior is more correct, but still
> is a change.
>
> I gave this a run in my test bed on top of your udp-related patches I
> see additional ~3 improvement in the udp flood scenario, and a bit more
> in the un-contended scenario.
>
> Thank you,
MSG_PEEK always grab the first skb in queue, regardless of its
skb->peeked status.
Unless an offset (given in bytes) is given. Then we skip X bytes in the
queue, again regardless of skb->peeked bit.
skb->peeked is _needed_ to avoid peeking the same 0-byte skb over and
over, since user land could not skip it, as the offset to skip skbs is
computed by sum ( lengthes). An infinite loop of recvmsg() would happen,
stuck on the same skb.
For regular non 0-bytes payload, we can skip over them without even
looking at skb->peeked.
Initially, skb->peeked was only a (bad) way to make sure UDP would
increment its stats only for non peeked messages. We can implement that
using at MSG_PEEK flag.
^ permalink raw reply
* Re: [PATCH] net/udp: do not touch skb->peeked unless really needed
From: Eric Dumazet @ 2016-12-06 14:35 UTC (permalink / raw)
To: Paolo Abeni; +Cc: David Miller, netdev, Willem de Bruijn
In-Reply-To: <1481026212.6225.43.camel@redhat.com>
On Tue, 2016-12-06 at 13:10 +0100, Paolo Abeni wrote:
> Please ignore the above dumb comment. I misread the 'skip condition'.
>
> I'm fine with the patch in its current form.
>
> Acked-by: Paolo Abeni <pabeni@redhat.com>
No worries, I prefer having multiple eyes on this stuff before doing the
next step ;)
Thanks !
^ permalink raw reply
* Re: [PATCH] net:dsa:mv88e6xxx: delete timer and cancel ppu_work
From: Andrew Lunn @ 2016-12-06 14:22 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: vivien.didelot, f.fainelli, netdev, volodymyr.bendiuga,
Jonas Johansson
In-Reply-To: <1481029062-16668-1-git-send-email-volodymyr.bendiuga@westermo.se>
On Tue, Dec 06, 2016 at 01:57:42PM +0100, Volodymyr Bendiuga wrote:
> Signed-off-by: Jonas Johansson <jonas.johansson@westermo.se>
> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@westermo.se>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index ca453f3..4212fb6 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -4528,8 +4528,11 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
> out_mdio:
> mv88e6xxx_mdio_unregister(chip);
> out_g2_irq:
> - if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT) && chip->irq > 0)
> + if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT) && chip->irq > 0) {
> mv88e6xxx_g2_irq_free(chip);
> + del_timer(&chip->ppu_timer);
> + cancel_work_sync(&chip->ppu_work);
> + }
Why do this here, inside this if statement?
Vivien has also just reworked the PPU code. Please take a look at his
patches and see if they fix the issue.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next] phy: add phy fixup unregister functions
From: David Miller @ 2016-12-06 15:01 UTC (permalink / raw)
To: Woojung.Huh; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40975526@CHN-SV-EXMX02.mchp-main.com>
From: <Woojung.Huh@microchip.com>
Date: Fri, 2 Dec 2016 23:04:13 +0000
> From: Woojung Huh <woojung.huh@microchip.com>
>
> Add functions to unregister phy fixup for modules.
>
> phy_unregister_fixup(const char *bus_id, u32 phy_uid, u32 phy_uid_mask)
> Unregister phy fixup matches bus_id, phy_uid and phy_uid_mask
> from phy_fixup_list.
> Return 0 when find matched one and remove from the list.
> Return -ENODEV when fail to find it on the list.
>
> phy_unregister_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask)
> Unregister phy fixup from phy_fixup_list.
> Use it for fixup registered by phy_register_fixup_for_uid()
> Return 0 when find matched one and remove from the list.
> Return -ENODEV when fail to find it on the list.
>
> phy_unregister_fixup_for_id(const char *bus_id)
> Unregister phy fixup from phy_fixup_list.
> Use it for fixup registered by phy_register_fixup_for_id()
> Return 0 when find matched one and remove from the list.
> Return -ENODEV when fail to find it on the list.
>
> Signed-off-by: Woojung Huh <woojung.huh@microchip.com>
Please submit this along with whatever will be the first user(s) of these
new interfaces.
^ permalink raw reply
* Re: Avoid deadlock situation due to use of xmit_lock
From: David Miller @ 2016-12-06 15:06 UTC (permalink / raw)
To: LinoSanfilippo
Cc: bh74.an, ks.giri, vipul.pandya, peppe.cavallaro, alexandre.torgue,
linux-kernel, netdev
In-Reply-To: <1480719966-12839-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sat, 3 Dec 2016 00:06:04 +0100
> after stumbling over a potential deadlock situation in the altera driver
> (see http://marc.info/?l=linux-netdev&m=148054615230447&w=2), I checked
> all other ethernet drivers for the same issue and actually found it in 2
> more, namely stmmac, and sxgbe. Please see the commit messages for a
> description of the problem.
> These 2 patches fix the concerning drivers.
First of all, I don't want to apply these patches without proper testing
and ACKs from the individual driver maintainers.
For both of these drivers, this situation only exists because the TX
path uses the unnecessary ->tx_lock. This private lock should be
removed completely and the driver should use the lock the mid-layer
already holds in the transmit path and take it in the TX reclaim path
instead of the private ->tx_lock.
^ permalink raw reply
* Re: [PATCH] net:mv88e6xxx: dispose irq mapping
From: Andrew Lunn @ 2016-12-06 15:08 UTC (permalink / raw)
To: Volodymyr Bendiuga; +Cc: vivien.didelot, f.fainelli, netdev
In-Reply-To: <7717215e-dddd-14af-196f-e638b5c60649@westermo.se>
On Tue, Dec 06, 2016 at 04:00:27PM +0100, Volodymyr Bendiuga wrote:
> Hi Andrew,
>
> thanks for you comments and time taken to review. I will make a new
>
> version which will indicate net-next tree.
>
> About mv88e6xxx_remove(), this function will not be called
Correct, which is why i said:
> and the error path of mv88e6xxx_probe().
which will be called on EPRODE_DEFFER.
> irq_dispose_mapping() is also called in mv88e6xxx_g2_irq_free(), so
> I put it in a similar
The mapping for chip->device_irq is made in mv88e6xxx_g2_irq_setup(),
so the disposal of the mapping logically goes in
mv88e6xxx_g2_irq_free().
Andrew
^ permalink raw reply
* Re: bpf debug info
From: Arnaldo Carvalho de Melo @ 2016-12-06 15:12 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, netdev, Brenden Blanco, Thomas Graf, Wangnan,
He Kuang, kernel-team
In-Reply-To: <20161129170115.GB22217@ast-mbp.thefacebook.com>
Em Tue, Nov 29, 2016 at 09:01:17AM -0800, Alexei Starovoitov escreveu:
> On Tue, Nov 29, 2016 at 04:11:32PM +0100, Daniel Borkmann wrote:
> > On 11/29/2016 07:42 AM, Alexei Starovoitov wrote:
> > >Notice that 'clang -S -o a.s' output and llvm-objdump disassembler
> > >were changed to use kernel verifier style, so now it should be easier
> > >to see what's going on.
> > Sounds really useful, is that scheduled for llvm 3.10 release?
> llvm 4.0 :)
> > That debugging info is stored in dwarf format into the obj, right?
> right.
> > Would be nice if also pahole could work on bpf object files.
>
> yeah. pahole need to be taught to recognize bpf e_machine type and relocations.
Coincidentally I'm testing some perf patches wrt builtin BPF and for
that I'm updating to llvm to 4.0, will take a look at what is involved
in that...
- Arnaldo
^ permalink raw reply
* Re: [PATCH net-next] tools: hv: Enable network manager for bonding scripts on RHEL
From: David Miller @ 2016-12-06 15:14 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: olaf, netdev, driverdev-devel, linux-kernel
In-Reply-To: <1480722938-23378-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 2 Dec 2016 15:55:38 -0800
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> We found network manager is necessary on RHEL to make the synthetic
> NIC, VF NIC bonding operations handled automatically. So, enabling
> network manager here.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bpf: add additional verifier tests for BPF_PROG_TYPE_LWT_*
From: David Miller @ 2016-12-06 15:15 UTC (permalink / raw)
To: tgraf; +Cc: netdev, daniel, alexei.starovoitov
In-Reply-To: <ad522c194cdc9b37a50ce087453586128e954321.1480926086.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Mon, 5 Dec 2016 10:30:52 +0100
> - direct packet read is allowed for LWT_*
> - direct packet write for LWT_IN/LWT_OUT is prohibited
> - direct packet write for LWT_XMIT is allowed
> - access to skb->tc_classid is prohibited for LWT_*
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Rob Herring @ 2016-12-06 15:16 UTC (permalink / raw)
To: Peter Rosin
Cc: Mark Rutland, devicetree, alsa-devel, Arnd Bergmann,
Greg Kroah-Hartman, Takashi Iwai, Nicolas Ferre, linux-kernel,
Liam Girdwood, Mark Brown, netdev, Jaroslav Kysela,
linux-arm-kernel
In-Reply-To: <1480593549-6464-2-git-send-email-peda@axentia.se>
On Thu, Dec 01, 2016 at 12:59:08PM +0100, Peter Rosin wrote:
> The SSC is currently not usable with the ASoC simple-audio-card, as
> every SSC audio user has to build a platform driver that may do as
> little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
> allocates the SSC and registers a DAI with the ASoC subsystem).
>
> So, have that happen automatically, if the #sound-dai-cells property
> is present in devicetree, which it has to be anyway for simple audio
> card to work.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> .../devicetree/bindings/misc/atmel-ssc.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
> include/linux/atmel-ssc.h | 1 +
> 3 files changed, 53 insertions(+)
^ permalink raw reply
* Re: [PATCH] net:mv88e6xxx: dispose irq mapping
From: Volodymyr Bendiuga @ 2016-12-06 15:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: vivien.didelot, f.fainelli, netdev
In-Reply-To: <20161206141923.GB26615@lunn.ch>
Hi Andrew,
thanks for you comments and time taken to review. I will make a new
version which will indicate net-next tree.
About mv88e6xxx_remove(), this function will not be called
if switch has not been registered completely, therefore dispose will not
be called.
irq_dispose_mapping() is also called in mv88e6xxx_g2_irq_free(), so I
put it in a similar
way in mv88e6xxx_g1_irq_free(). What do you think? If you have any other
idea
of how this could be implemented then let me know and I will fix it.
/Volodymyr
On 2016-12-06 15:19, Andrew Lunn wrote:
> On Tue, Dec 06, 2016 at 11:05:43AM +0100, Volodymyr Bendiuga wrote:
>> If this is not done, then it is not possible to map
>> irq next time, after EPROBE_DEFER.
>>
>> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@westermo.se>
> Hi Volodymyr
>
> Thanks for your patches.
>
> Please could you include in the subject line which tree it is for. See
>
> Documentation/networking/netdev-FAQ.txt
>
>
>> ---
>> drivers/net/dsa/mv88e6xxx/chip.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>> index 05942e3..12e7d38 100644
>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>> @@ -420,6 +420,7 @@ static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip *chip)
>> mv88e6xxx_g1_write(chip, GLOBAL_CONTROL, mask);
>>
>> free_irq(chip->irq, chip);
>> + irq_dispose_mapping(chip->irq);
> This seems like the wrong place to do this.
>
> The mapping is created by chip->irq = of_irq_get(np, 0); in
> mv88e6xxx_probe(). So the correct place to dispose of this mapping would be in
> mv88e6xxx_remove() and the error path of mv88e6xxx_probe().
>
> Thanks
> Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: Use EDSA on mv88e6097
From: David Miller @ 2016-12-06 15:17 UTC (permalink / raw)
To: eichest; +Cc: andrew, vivien.didelot, netdev, stefan.eichenberger
In-Reply-To: <20161205131242.19370-1-stefan.eichenberger@netmodule.com>
From: Stefan Eichenberger <eichest@gmail.com>
Date: Mon, 5 Dec 2016 14:12:42 +0100
> Use DSA_TAG_PROTO_EDSA as tag_protocol for the mv88e6097. The
> initialisation was missing before.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@netmodule.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next V2 1/2] net/sched: cls_flower: Add support for matching on flags
From: Or Gerlitz @ 2016-12-06 15:18 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jiri Pirko, Roi Dayan, Hadar Har-Zion, Or Gerlitz
In-Reply-To: <1481037486-27195-1-git-send-email-ogerlitz@mellanox.com>
Add UAPI to provide set of flags for matching, where the flags
provided from user-space are mapped to flow-dissector flags.
The 1st flag allows to match on whether the packet is an
IP fragment and corresponds to the FLOW_DIS_IS_FRAGMENT flag.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Paul Blakey <paulb@mellanox.com>
---
include/uapi/linux/pkt_cls.h | 7 ++++
net/sched/cls_flower.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 86786d4..f114277 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -457,11 +457,18 @@ enum {
TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK, /* be16 */
TCA_FLOWER_KEY_ENC_UDP_DST_PORT, /* be16 */
TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK, /* be16 */
+
+ TCA_FLOWER_KEY_FLAGS, /* be32 */
+ TCA_FLOWER_KEY_FLAGS_MASK, /* be32 */
__TCA_FLOWER_MAX,
};
#define TCA_FLOWER_MAX (__TCA_FLOWER_MAX - 1)
+enum {
+ TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT = BIT(0),
+};
+
/* Match-all classifier */
enum {
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index c5cea78..0efbeb0 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -383,6 +383,8 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
[TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_ENC_UDP_DST_PORT] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_FLAGS] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_FLAGS_MASK] = { .type = NLA_U32 },
};
static void fl_set_key_val(struct nlattr **tb,
@@ -417,6 +419,39 @@ static void fl_set_key_vlan(struct nlattr **tb,
}
}
+static void fl_set_key_flag(u32 flower_key, u32 flower_mask,
+ u32 *dissector_key, u32 *dissector_mask,
+ u32 flower_flag_bit, u32 dissector_flag_bit)
+{
+ if (flower_mask & flower_flag_bit) {
+ *dissector_mask |= dissector_flag_bit;
+ if (flower_key & flower_flag_bit)
+ *dissector_key |= dissector_flag_bit;
+ }
+}
+
+static void fl_set_key_flags(struct nlattr **tb,
+ u32 *flags_key, u32 *flags_mask)
+{
+ u32 key, mask;
+
+ if (!tb[TCA_FLOWER_KEY_FLAGS])
+ return;
+
+ key = be32_to_cpu(nla_get_u32(tb[TCA_FLOWER_KEY_FLAGS]));
+
+ if (!tb[TCA_FLOWER_KEY_FLAGS_MASK])
+ mask = ~0;
+ else
+ mask = be32_to_cpu(nla_get_u32(tb[TCA_FLOWER_KEY_FLAGS_MASK]));
+
+ *flags_key = 0;
+ *flags_mask = 0;
+
+ fl_set_key_flag(key, mask, flags_key, flags_mask,
+ TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT, FLOW_DIS_IS_FRAGMENT);
+}
+
static int fl_set_key(struct net *net, struct nlattr **tb,
struct fl_flow_key *key, struct fl_flow_key *mask)
{
@@ -543,6 +578,8 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
&mask->enc_tp.dst, TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK,
sizeof(key->enc_tp.dst));
+ fl_set_key_flags(tb, &key->control.flags, &mask->control.flags);
+
return 0;
}
@@ -877,6 +914,42 @@ static int fl_dump_key_vlan(struct sk_buff *skb,
return 0;
}
+static void fl_get_key_flag(u32 dissector_key, u32 dissector_mask,
+ u32 *flower_key, u32 *flower_mask,
+ u32 flower_flag_bit, u32 dissector_flag_bit)
+{
+ if (dissector_mask & dissector_flag_bit) {
+ *flower_mask |= flower_flag_bit;
+ if (dissector_key & dissector_flag_bit)
+ *flower_key |= flower_flag_bit;
+ }
+}
+
+static int fl_dump_key_flags(struct sk_buff *skb, u32 flags_key, u32 flags_mask)
+{
+ u32 key, mask;
+ __be32 _key, _mask;
+ int err;
+
+ if (!memchr_inv(&flags_mask, 0, sizeof(flags_mask)))
+ return 0;
+
+ key = 0;
+ mask = 0;
+
+ fl_get_key_flag(flags_key, flags_mask, &key, &mask,
+ TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT, FLOW_DIS_IS_FRAGMENT);
+
+ _key = cpu_to_be32(key);
+ _mask = cpu_to_be32(mask);
+
+ err = nla_put(skb, TCA_FLOWER_KEY_FLAGS, 4, &_key);
+ if (err)
+ return err;
+
+ return nla_put(skb, TCA_FLOWER_KEY_FLAGS_MASK, 4, &_mask);
+}
+
static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
struct sk_buff *skb, struct tcmsg *t)
{
@@ -1012,6 +1085,9 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
sizeof(key->enc_tp.dst)))
goto nla_put_failure;
+ if (fl_dump_key_flags(skb, key->control.flags, mask->control.flags))
+ goto nla_put_failure;
+
nla_put_u32(skb, TCA_FLOWER_FLAGS, f->flags);
if (tcf_exts_dump(skb, &f->exts))
--
2.3.7
^ permalink raw reply related
* [PATCH net-next V2 0/2] net/sched: cls_flower: Add support for matching on dissection flags
From: Or Gerlitz @ 2016-12-06 15:18 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jiri Pirko, Roi Dayan, Hadar Har-Zion, Or Gerlitz
Hi Dave,
This series add the UAPI to provide set of flags for matching, where the
flags provided from user-space are mapped to flow-dissector flags.
The 1st flag allows to match on whether the packet is an
IP fragment and corresponds to the FLOW_DIS_IS_FRAGMENT flag.
Or
v1->v2:
- dropped the flow dissector patch (#1) as no changes are needed there (Jiri)
- applied code review comments from Jiri to the flower patch
Or Gerlitz (2):
net/sched: cls_flower: Add support for matching on flags
net/mlx5e: Offload TC matching on packets being IP fragments
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 12 ++++
include/uapi/linux/pkt_cls.h | 7 +++
net/sched/cls_flower.c | 76 +++++++++++++++++++++++++
3 files changed, 95 insertions(+)
--
2.3.7
^ permalink raw reply
* [PATCH net-next V2 2/2] net/mlx5e: Offload TC matching on packets being IP fragments
From: Or Gerlitz @ 2016-12-06 15:18 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jiri Pirko, Roi Dayan, Hadar Har-Zion, Or Gerlitz
In-Reply-To: <1481037486-27195-1-git-send-email-ogerlitz@mellanox.com>
Enable offloading of matching on packets being fragments.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Paul Blakey <paulb@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index f07ef8c..f8829b5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -31,6 +31,7 @@
*/
#include <net/flow_dissector.h>
+#include <net/sch_generic.h>
#include <net/pkt_cls.h>
#include <net/tc_act/tc_gact.h>
#include <net/tc_act/tc_skbedit.h>
@@ -363,7 +364,18 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
skb_flow_dissector_target(f->dissector,
FLOW_DISSECTOR_KEY_CONTROL,
f->key);
+
+ struct flow_dissector_key_control *mask =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_CONTROL,
+ f->mask);
addr_type = key->addr_type;
+
+ if (mask->flags & FLOW_DIS_IS_FRAGMENT) {
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, frag, 1);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, frag,
+ key->flags & FLOW_DIS_IS_FRAGMENT);
+ }
}
if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_BASIC)) {
--
2.3.7
^ permalink raw reply related
* Re: [PATCH net-next v2 1/1] driver: ipvlan: Free ipvl_port directly with kfree instead of kfree_rcu
From: Eric Dumazet @ 2016-12-06 15:18 UTC (permalink / raw)
To: fgao; +Cc: davem, maheshb, edumazet, netdev, gfree.wind
In-Reply-To: <1481032489-7864-1-git-send-email-fgao@ikuai8.com>
On Tue, 2016-12-06 at 21:54 +0800, fgao@ikuai8.com wrote:
> From: Gao Feng <gfree.wind@gmail.com>
>
> There is no one which may reference the ipvlan port when free it in
> ipvlan_port_create and ipvlan_port_destroy. So it is unnecessary to
> use kfree_rcu.
You did not really explain _why_ it was safe/unnecessary.
Why should anyone trust you ?
The reason an RCU grace period is not needed is that
netdev_rx_handler_unregister() already enforces a grace period.
My guess is ipvlan copied code in macvlan.
At the time macvlan was written, commit
00cfec37484761a44 ("net: add a synchronize_net() in
netdev_rx_handler_unregister()") was not there yet.
macvlan could be changed the same way.
^ permalink raw reply
* Re: [PATCH v2 0/4] net: hix5hd2_gmac: add tx sg feature and reset/clock control signals
From: David Miller @ 2016-12-06 15:21 UTC (permalink / raw)
To: lidongpo
Cc: robh+dt, mark.rutland, mturquette, sboyd, linux, zhangfei.gao,
yisen.zhuang, salil.mehta, arnd, andrew, xuejiancheng,
benjamin.chenhao, caizhiyong, netdev, devicetree, linux-kernel
In-Reply-To: <1480944481-118803-1-git-send-email-lidongpo@hisilicon.com>
From: Dongpo Li <lidongpo@hisilicon.com>
Date: Mon, 5 Dec 2016 21:27:57 +0800
> The "hix5hd2" is SoC name, add the generic ethernet driver compatible string.
> The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
> the SG/TXCSUM/TSO/UFO features.
> This patch set only adds the SG(scatter-gather) driver for transmitting,
> the drivers of other features will be submitted later.
>
> Add the MAC reset control signals and clock signals.
> We make these signals optional to be backward compatible with
> the hix5hd2 SoC.
>
> Changes in v2:
> - Make the compatible string changes be a separate patch and
> the most specific string come first than the generic string
> as advised by Rob.
> - Make the MAC reset control signals and clock signals optional
> to be backward compatible with the hix5hd2 SoC.
> - Change the compatible string and give the clock a specific name
> in hix5hd2 dts file.
Series applied to net-next, thanks.
^ 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