* Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Or Gerlitz @ 2019-01-27 16:39 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz
In-Reply-To: <1548587196-10746-2-git-send-email-xiangxia.m.yue@gmail.com>
On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@gmail.com> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> In some case, we may use multiple pedit actions to modify packets.
> The command shown as below: the last pedit action is effective.
> @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
> if (!parse_attr->mod_hdr_actions)
> return -ENOMEM;
>
> - parse_attr->num_mod_hdr_actions = max_actions;
> + parse_attr->max_mod_hdr_actions = max_actions;
> + parse_attr->num_mod_hdr_actions = 0;
why would we want to do this zeroing? what purpose does it serve?
On a probably related note, I suspect that the patch broke the caching
we do for modify header contexts, see mlx5e_attach_mod_hdr where we
look if a given set of modify header operations already has hw modify header
context and we use it.
To test that, put two tc rules with different matching but same set of
modify header
(pedit) actions and see that only one modify header context is used.
^ permalink raw reply
* Re: [PATCH V2] net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq
From: Andrew Lunn @ 2019-01-27 16:34 UTC (permalink / raw)
To: Yang Wei; +Cc: netdev, davem, yang.wei9
In-Reply-To: <1548604388-4087-1-git-send-email-albin_yang@163.com>
On Sun, Jan 27, 2019 at 11:53:08PM +0800, Yang Wei wrote:
> dev_consume_skb_irq() should be called in i596_interrupt() when
> xmit done. It makes drop profiles more friendly.
>
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
> ---
Hi Yang
It is normal to include here, under the ---, what has changed since
the previous version of the patch.
Please also read
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
Your patches don't have the correct subject.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net v4 1/2] net/mlx5e: Update hw flows when encap source mac changed
From: Or Gerlitz @ 2019-01-27 16:32 UTC (permalink / raw)
To: David Miller, Saeed Mahameed
Cc: Linux Netdev List, Tonghao Zhang, Hadar Hen Zion
In-Reply-To: <1548587196-10746-1-git-send-email-xiangxia.m.yue@gmail.com>
On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@gmail.com> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> When we offload tc filters to hardware, hardware flows can
> be updated when mac of encap destination ip is changed.
> But we ignore one case, that the mac of local encap ip can
> be changed too, so we should also update them.
>
> To fix it, add route_dev in mlx5e_encap_entry struct to save
> the local encap netdevice, and when mac changed, kernel will
> flush all the neighbour on the netdevice and send NETEVENT_NEIGH_UPDATE
> event. The mlx5 driver will delete the flows and add them when neighbour
> available again.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Cc: Hadar Hen Zion <hadarh@mellanox.com>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
+1 again
this one is good to go upstream
^ permalink raw reply
* stable request: ipv6: Consider sk_bound_dev_if when binding a socket to an address
From: David Ahern @ 2019-01-27 16:17 UTC (permalink / raw)
To: David Miller, Salvatore Bonaccorso, netdev@vger.kernel.org
Hi Dave:
Request for c5ee066333eb("ipv6: Consider sk_bound_dev_if when binding a
socket to an address") to be backported.
The v4-mapped version - ec90ad334986 ("ipv6: Consider sk_bound_dev_if
when binding a socket to a v4 mapped address") - has been backported to
stable releases, but the v6 socket version c5ee066333eb has not (and is
not on the current stable list).
Thanks,
David
^ permalink raw reply
* net: amd8111e: replace dev_kfree_skb_irq by dev_consume_skb_irq
From: Yang Wei @ 2019-01-27 15:58 UTC (permalink / raw)
To: netdev; +Cc: davem, yang.wei9, Yang Wei
dev_consume_skb_irq() should be called in amd8111e_tx() when xmit
done. It makes drop profiles more friendly.
Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
---
drivers/net/ethernet/amd/amd8111e.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/amd8111e.c b/drivers/net/ethernet/amd/amd8111e.c
index a90080f..1a24292 100644
--- a/drivers/net/ethernet/amd/amd8111e.c
+++ b/drivers/net/ethernet/amd/amd8111e.c
@@ -666,7 +666,7 @@ static int amd8111e_tx(struct net_device *dev)
pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[tx_index],
lp->tx_skbuff[tx_index]->len,
PCI_DMA_TODEVICE);
- dev_kfree_skb_irq (lp->tx_skbuff[tx_index]);
+ dev_consume_skb_irq(lp->tx_skbuff[tx_index]);
lp->tx_skbuff[tx_index] = NULL;
lp->tx_dma_addr[tx_index] = 0;
}
--
2.7.4
^ permalink raw reply related
* net: alteon: replace dev_kfree_skb_irq by dev_consume_skb_irq
From: Yang Wei @ 2019-01-27 15:56 UTC (permalink / raw)
To: linux-acenic, netdev; +Cc: jes, davem, yang.wei9, Yang Wei
dev_consume_skb_irq() should be called in ace_tx_int() when xmit
done. It makes drop profiles more friendly.
Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
---
drivers/net/ethernet/alteon/acenic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/alteon/acenic.c b/drivers/net/ethernet/alteon/acenic.c
index 4f11f98..1827ef1 100644
--- a/drivers/net/ethernet/alteon/acenic.c
+++ b/drivers/net/ethernet/alteon/acenic.c
@@ -2059,7 +2059,7 @@ static inline void ace_tx_int(struct net_device *dev,
if (skb) {
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
- dev_kfree_skb_irq(skb);
+ dev_consume_skb_irq(skb);
info->skb = NULL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH V2] net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq
From: Yang Wei @ 2019-01-27 15:53 UTC (permalink / raw)
To: netdev; +Cc: davem, yang.wei9, Yang Wei
dev_consume_skb_irq() should be called in i596_interrupt() when
xmit done. It makes drop profiles more friendly.
Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
---
drivers/net/ethernet/i825xx/82596.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/i825xx/82596.c b/drivers/net/ethernet/i825xx/82596.c
index d719668..855900a 100644
--- a/drivers/net/ethernet/i825xx/82596.c
+++ b/drivers/net/ethernet/i825xx/82596.c
@@ -1310,7 +1310,7 @@ static irqreturn_t i596_interrupt(int irq, void *dev_id)
dev->stats.tx_aborted_errors++;
}
- dev_kfree_skb_irq(skb);
+ dev_consume_skb_irq(skb);
tx_cmd->cmd.command = 0; /* Mark free */
break;
--
2.7.4
^ permalink raw reply related
* net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq
From: Yang Wei @ 2019-01-27 15:50 UTC (permalink / raw)
To: netdev; +Cc: davem, yang.wei9, Yang Wei
dev_consume_skb_irq() should be called in i596_interrupt() when
xmit done. It makes drop profiles more friendly.
Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
---
drivers/net/ethernet/i825xx/82596.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/i825xx/82596.c b/drivers/net/ethernet/i825xx/82596.c
index d719668..855900a 100644
--- a/drivers/net/ethernet/i825xx/82596.c
+++ b/drivers/net/ethernet/i825xx/82596.c
@@ -1310,7 +1310,7 @@ static irqreturn_t i596_interrupt(int irq, void *dev_id)
dev->stats.tx_aborted_errors++;
}
- dev_kfree_skb_irq(skb);
+ dev_kfree_consume_irq(skb);
tx_cmd->cmd.command = 0; /* Mark free */
break;
--
2.7.4
^ permalink raw reply related
* RE: [PATCH net-next 0/3] qed*: Error recovery process
From: Michal Kalderon @ 2019-01-27 13:42 UTC (permalink / raw)
To: David Miller, michal.kalderon@cavium.com
Cc: ariel.elior@cavium.com, netdev@vger.kernel.org
In-Reply-To: <20190122.173715.2023476735879069761.davem@davemloft.net>
> From: David Miller <davem@davemloft.net>
> Sent: Wednesday, January 23, 2019 3:37 AM
>
> > Parity errors might happen in the device's memories due to momentary
> > bit flips which are caused by radiation.
> > Errors that are not correctable initiate a process kill event, which
> > blocks the device access towards the host and the network, and a
> > recovery process is started in the management FW and in the driver.
> >
> > This series adds the support of this process in the qed core module
> > and in the qede driver (patches 2 & 3).
> > Patch 1 in the series revises the load sequence, to avoid PCI errors
> > that might be observed during a recovery process.
>
> Series applied.
Thanks Dave, though I don't see this in net-next, I noticed this was recently applied
and reverted from net, should I resend to have it applied to net-next ?
Thanks,
Michal
^ permalink raw reply
* RE: [PATCH] lan78xx: fix ip header misalignment
From: RaghuramChary.Jallipalli @ 2019-01-27 13:14 UTC (permalink / raw)
To: yumkam, netdev; +Cc: Woojung.Huh, UNGLinuxDriver
In-Reply-To: <53800bc3-397a-ed1a-958d-a1dbc887d249@gmail.com>
Hi Yuiry,
Thanks for the patch.
Changes look good to me.
Thanks,
-Raghu
> -----Original Message-----
> From: Yuriy M. Kaminskiy <yumkam@gmail.com>
> Sent: Monday, January 21, 2019 6:18 PM
> To: netdev@vger.kernel.org
> Cc: Woojung Huh - C21699 <Woojung.Huh@microchip.com>;
> UNGLinuxDriver <UNGLinuxDriver@microchip.com>
> Subject: [PATCH] lan78xx: fix ip header misalignment
>
> lan78xx.c:rx_submit() allocates space for frame-to-be-received with
> netdev_alloc_skb_ip_align(), which misalign start of buffer by 2 bytes in
> expectation that frame will start from 14-byte ethernet header, then ip
> header; if start of buffer misaligned by 2 bytes, ip header will be 16-byte
> aligned.
>
> Unfortunately, usb frame that is sent by lan78xx starts with another 10-byte
> header (lan78xx_rx(): rx_cmd_a/rx_cmd_b/rx_cmd_c), *then* follows
> ethernet header, and *then* ip header (which ends up being misaligned).
>
> This issue was observed on arm platform (where misaligned 32-bit word
> access triggers exception and leaves traces in /proc/cpu/alignment, see
> https://github.com/raspberrypi/linux/issues/2599 ; for me, about any
> ipv6 traffic that hits machine - `ping -I eth0 ip6-allnodes`, tcp/udp packets, etc
> triggered increase in this counter, with ip6_datagram_recv_common_ctl,
> icmpv6_echo_reply, etc as culprit).
>
> If we just allocate skb data without any misalignment tricks, ip header will
> end up and at offset 24 (8-byte aligned).
>
> Patch attached; runtime-tested with raspbian fork of stable/4.14.y [4.14.92]
> on Raspberry pi 3B+ (it is slightly different from mainline, but patch should
> not have any conflicts, all affected code is pretty same).
>
> P.S. I'm not subscribed, please CC me on reply.
^ permalink raw reply
* Re: [RFC PATCH 0/3] RV64G eBPF JIT
From: Björn Töpel @ 2019-01-27 12:28 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-riscv, Palmer Dabbelt, davidlee, Daniel Borkmann, Netdev
In-Reply-To: <alpine.DEB.2.21.9999.1901251147250.20864@viisi.sifive.com>
Den fre 25 jan. 2019 kl 20:54 skrev Paul Walmsley <paul.walmsley@sifive.com>:
>
> Hi,
>
> thanks for taking a shot at the eBPF JIT; this will be very useful.
>
> On Tue, 15 Jan 2019, Björn Töpel wrote:
>
> > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to
> > arch/riscv/Kconfig. Is this assumption correct?
>
> From a hardware point of view, this is not the case on the Linux-capable
> RISC-V ASICs that the public can buy right now (to the best of my
> knowledge this is only the SiFive FU540).
>
> So I'd recommend not including this for now.
>
Got it! Thanks for clearing that up for me!
Hopefully, I'll find some time the coming week to get a v2 out with
tail-call support and most comments addressed.
Cheers,
Björn
>
> - Paul
^ permalink raw reply
* [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: xiangxia.m.yue @ 2019-01-27 11:06 UTC (permalink / raw)
To: saeedm, gerlitz.or; +Cc: netdev, Tonghao Zhang, Or Gerlitz
In-Reply-To: <1548587196-10746-1-git-send-email-xiangxia.m.yue@gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
In some case, we may use multiple pedit actions to modify packets.
The command shown as below: the last pedit action is effective.
$ tc filter add dev netdev_rep parent ffff: protocol ip prio 1 \
flower skip_sw ip_proto icmp dst_ip 3.3.3.3 \
action pedit ex munge ip dst set 192.168.1.100 pipe \
action pedit ex munge eth src set 00:00:00:00:00:01 pipe \
action pedit ex munge eth dst set 00:00:00:00:00:02 pipe \
action csum ip pipe \
action tunnel_key set src_ip 1.1.1.100 dst_ip 1.1.1.200 dst_port 4789 id 100 \
action mirred egress redirect dev vxlan0
To fix it, we add max_mod_hdr_actions to mlx5e_tc_flow_parse_attr struction,
max_mod_hdr_actions will store the max pedit action number we support and
num_mod_hdr_actions indicates how many pedit action we used, and store all
pedit action to mod_hdr_actions.
Fixes: d79b6df6b10a ("net/mlx5e: Add parsing of TC pedit actions to HW format")
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
v2: Fix comment message and change tag from net-next to net.
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 26 +++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index cae6c6d..833a29a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -128,6 +128,7 @@ struct mlx5e_tc_flow_parse_attr {
struct net_device *filter_dev;
struct mlx5_flow_spec spec;
int num_mod_hdr_actions;
+ int max_mod_hdr_actions;
void *mod_hdr_actions;
int mirred_ifindex[MLX5_MAX_FLOW_FWD_VPORTS];
};
@@ -1934,9 +1935,9 @@ struct mlx5_fields {
OFFLOAD(UDP_DPORT, 2, udp.dest, 0),
};
-/* On input attr->num_mod_hdr_actions tells how many HW actions can be parsed at
- * max from the SW pedit action. On success, it says how many HW actions were
- * actually parsed.
+/* On input attr->max_mod_hdr_actions tells how many HW actions can be parsed at
+ * max from the SW pedit action. On success, attr->num_mod_hdr_actions
+ * says how many HW actions were actually parsed.
*/
static int offload_pedit_fields(struct pedit_headers *masks,
struct pedit_headers *vals,
@@ -1960,9 +1961,11 @@ static int offload_pedit_fields(struct pedit_headers *masks,
add_vals = &vals[TCA_PEDIT_KEY_EX_CMD_ADD];
action_size = MLX5_UN_SZ_BYTES(set_action_in_add_action_in_auto);
- action = parse_attr->mod_hdr_actions;
- max_actions = parse_attr->num_mod_hdr_actions;
- nactions = 0;
+ action = parse_attr->mod_hdr_actions +
+ parse_attr->num_mod_hdr_actions * action_size;
+
+ max_actions = parse_attr->max_mod_hdr_actions;
+ nactions = parse_attr->num_mod_hdr_actions;
for (i = 0; i < ARRAY_SIZE(fields); i++) {
f = &fields[i];
@@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
if (!parse_attr->mod_hdr_actions)
return -ENOMEM;
- parse_attr->num_mod_hdr_actions = max_actions;
+ parse_attr->max_mod_hdr_actions = max_actions;
+ parse_attr->num_mod_hdr_actions = 0;
return 0;
}
@@ -2119,9 +2123,11 @@ static int parse_tc_pedit_action(struct mlx5e_priv *priv,
goto out_err;
}
- err = alloc_mod_hdr_actions(priv, a, namespace, parse_attr);
- if (err)
- goto out_err;
+ if (!parse_attr->mod_hdr_actions) {
+ err = alloc_mod_hdr_actions(priv, a, namespace, parse_attr);
+ if (err)
+ goto out_err;
+ }
err = offload_pedit_fields(masks, vals, parse_attr, extack);
if (err < 0)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net v4 1/2] net/mlx5e: Update hw flows when encap source mac changed
From: xiangxia.m.yue @ 2019-01-27 11:06 UTC (permalink / raw)
To: saeedm, gerlitz.or; +Cc: netdev, Tonghao Zhang, Hadar Hen Zion
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
When we offload tc filters to hardware, hardware flows can
be updated when mac of encap destination ip is changed.
But we ignore one case, that the mac of local encap ip can
be changed too, so we should also update them.
To fix it, add route_dev in mlx5e_encap_entry struct to save
the local encap netdevice, and when mac changed, kernel will
flush all the neighbour on the netdevice and send NETEVENT_NEIGH_UPDATE
event. The mlx5 driver will delete the flows and add them when neighbour
available again.
Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
Cc: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 ++++
drivers/net/ethernet/mellanox/mlx5/core/en_rep.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
index 046948e..114e0a2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
@@ -256,6 +256,7 @@ int mlx5e_tc_tun_create_header_ipv4(struct mlx5e_priv *priv,
e->m_neigh.family = n->ops->family;
memcpy(&e->m_neigh.dst_ip, n->primary_key, n->tbl->key_len);
e->out_dev = out_dev;
+ e->route_dev = route_dev;
/* It's important to add the neigh to the hash table before checking
* the neigh validity state. So if we'll get a notification, in case the
@@ -369,6 +370,7 @@ int mlx5e_tc_tun_create_header_ipv6(struct mlx5e_priv *priv,
e->m_neigh.family = n->ops->family;
memcpy(&e->m_neigh.dst_ip, n->primary_key, n->tbl->key_len);
e->out_dev = out_dev;
+ e->route_dev = route_dev;
/* It's importent to add the neigh to the hash table before checking
* the neigh validity state. So if we'll get a notification, in case the
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index 96cc0c6..c4b9073 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -594,6 +594,10 @@ static void mlx5e_rep_update_flows(struct mlx5e_priv *priv,
if (neigh_connected && !(e->flags & MLX5_ENCAP_ENTRY_VALID)) {
ether_addr_copy(e->h_dest, ha);
ether_addr_copy(eth->h_dest, ha);
+ /* Update the encap source mac, in case that we delete
+ * the flows when encap source mac changed.
+ */
+ ether_addr_copy(eth->h_source, e->route_dev->dev_addr);
mlx5e_tc_encap_flows_add(priv, e);
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h
index edd7228..36eafc8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h
@@ -148,6 +148,7 @@ struct mlx5e_encap_entry {
unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
struct net_device *out_dev;
+ struct net_device *route_dev;
int tunnel_type;
int tunnel_hlen;
int reformat_type;
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC v4 00/19] batman-adv: netlink restructuring, part 2
From: Jiri Pirko @ 2019-01-27 8:45 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: b.a.t.m.a.n, Jiri Pirko, netdev, linus.luessing
In-Reply-To: <1895931.G10psR3j26@sven-edge>
Sat, Jan 26, 2019 at 11:47:20AM CET, sven@narfation.org wrote:
>On Saturday, 19 January 2019 16.56.07 CET Sven Eckelmann wrote:
>[...]
>> There were also two topics which were not yet really discussed and thus
>> these requests (from Linus) were not yet implemented:
>
>@Jiri, @Linus maybe you can discuss these topics further and select the
>correct solution.
>
>> * convert BATADV_ATTR_MULTICAST_MODE_ENABLED to an u32 and let don't handle
>> it like a boolean. Instead use it to select how multicast traffic has to
>> be handled:
>>
>> - 0: ignore multicast optimization and just flood it like broadcast
>> traffic
>> - 1: enabled multicast optimization
>> - 2: undefined but also some kind of multicast optimization
>> - 3: undefined but also some kind of multicast of optimization
>> - ...
>
>Multicast mode is currently defined.
>
>* according to batctl manpage:
>
> multicast_mode|mm [0|1]
> If no parameter is given the current multicast mode set‐
> ting is displayed. Otherwise the parameter is used to en‐
> able or disable multicast optimizations (i.e. disabling
> means always sending own multicast frames via classic
> flooding).
>
>* according to sysfs ABI:
>
> What: /sys/class/net/<mesh_iface>/mesh/multicast_mode
> Date: Feb 2014
> Contact: Linus Lüssing <linus.luessing@web.de>
> Description:
> Indicates whether multicast optimizations are enabled
> or disabled. If set to zero then all nodes in the
> mesh are going to use classic flooding for any
> multicast packet with no optimizations.
>
>Both define it as boolean value and therefore it was converted to a boolean
>value (via u8) in netlink.
>
>But Linus now suggested that it is actually an u32. Most likely 0 == to
>something like BATADV_MULTICAST_MODE_FLOODING. But I have no idea what 1 is or
>what 2, 3, 4, .. would be. So I need some input here.
>
>And Jiri said that it should be renamed to BATADV_ATTR_MULTICAST_ENABLED -
>which seems to suggest that he doesn't like the idea of a u32 for some reason
>and prefers to use a boolean value.
>
>And now Linus even said that it should be a bit field - which makes it even
>more vague to me and I have now absolutely no idea what should be implemented.
If it is bool, it should be bool. If it is a bitfield (future more bits
than one needed), it should be a bitfield.
>
>* BIT 0 for flooding vs ?
>* BIT 1 for ?
>* ...
>
>> * convert BATADV_ATTR_AGGREGATION_OGM_ENABLED to u32 and use it
>> to mark which type of traffic should be aggregated:
>>
>> - bit 0: enable aggregation of OGM(2)s
>> - bit 1: yet undefined packet type which allows some kind of aggregation
>> - bit 2: yet undefined packet type which allows some kind of aggregation
>> - ...
>
>Aggregated OGM is currently defined as:
>
>
>* according to batctl manpage:
>
> aggregation|ag [0|1]
> If no parameter is given the current aggregation setting
> is displayed. Otherwise the parameter is used to enable or
> disable OGM packet aggregation.
>
>* according to sysfs ABI:
>
> What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
> Date: May 2010
> Contact: Marek Lindner <mareklindner@neomailbox.ch>
> Description:
> Indicates whether the batman protocol messages of the
> mesh <mesh_iface> shall be aggregated or not.
>
>So sysfs is only one possible backend for the batctl command. There is
>currently nothing which I would assume to be aggregatable beside OGMs but let
>us assume for now that there is now something and some way to aggregate things
>beside OGMs in a save and backward compatible way. Let's call this FOO - so we
>have BATADV_ATTR_AGGREGATION_OGM_ENABLED and
>BATADV_ATTR_AGGREGATION_FOO_ENABLED. Or we have BATADV_ATTR_AGGREGATION as an
>u32 and just use the second bit as marker for FOO (and of course the first bit
>as marker for OGM).
>
>Would it now be more preferable to use BATADV_ATTR_AGGREGATION_OGM_ENABLED as
>u8 (boolean) or to to switch to BATADV_ATTR_AGGREGATION (u32) & assign single
>bits to packet types.
>
>Kind regards,
> Sven
^ permalink raw reply
* Re: [PATCH iproute2-next 05/19] rdma: Move resource PD logic to separate file
From: Leon Romanovsky @ 2019-01-27 8:29 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <0ad0319f-194c-d574-e7f7-eca71c7a008a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
On Fri, Jan 25, 2019 at 10:19:22AM -0700, David Ahern wrote:
> On 1/22/19 11:31 AM, Leon Romanovsky wrote:
> > +static const
> > +struct filters pd_valid_filters[MAX_NUMBER_OF_FILTERS] = {
> > + { .name = "dev", .is_number = false },
> > + { .name = "users", .is_number = true },
> > + { .name = "pid", .is_number = true },
> > + { .name = "ctxn", .is_number = true },
> > + { .name = "pdn", .is_number = true },
> > + { .name = "ctxn", .is_number = true }
> > +};
>
> These should not be in a header file. Looks like you have done this in
> other patches as well.
This is the outcome of how we build command line with single struct *rd,
see res_show(). While I refactored the code, I saw your comment is coming,
but decided to proceed anyway to make this series a little bit sane.
I'll definitely continue to refactor it, but for now, there is a need to see
valid_filters structure in RES_FUNC() macro.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH mlx5-next 0/4] mlx5 next misc updates
From: Leon Romanovsky @ 2019-01-27 7:51 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Jason Gunthorpe
In-Reply-To: <CALzJLG9hjOZ=+pommPcjP0He_mBSUMK5+q3F9k8qGGhJvmJPQw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
On Fri, Jan 25, 2019 at 10:08:00AM -0800, Saeed Mahameed wrote:
> On Thu, Jan 24, 2019 at 4:30 AM Leon Romanovsky <leonro@mellanox.com> wrote:
> >
> > On Fri, Jan 18, 2019 at 04:33:09PM -0800, Saeed Mahameed wrote:
> > > Hi all,
> > >
> > > This series includes updates to mlx5-next shared branch.
> > >
> > > 1) from Jason, improve mlx5_cmd_exec_cb async API to be safer
> > > 2) from Maxim Mikityanskiy, cleanups for mlx5_write64 doorbell API
> > > 3) from Michael Guralnik, Add pci AtomicOps request
> > >
> > > Thanks,
> > > Saeed.
> > >
> > > ---
> > >
> > > Jason Gunthorpe (1):
> > > net/mlx5: Make mlx5_cmd_exec_cb() a safe API
> > >
> > > Michael Guralnik (1):
> > > net/mlx5: Add pci AtomicOps request
> >
> > Those two were applied to mlx5-next branch.
> >
> > ce4eee5340a9 (mlx5-next) net/mlx5: Add pci AtomicOps request
> > e355477ed9e4 net/mlx5: Make mlx5_cmd_exec_cb() a safe API
> >
> > > Maxim Mikityanskiy (2):
> > > net/mlx5: Remove unused MLX5_*_DOORBELL_LOCK macros
> > > net/mlx5: Remove spinlock support from mlx5_write64
> >
> > Those two needs extra work,
>
> What extra work ?
You got two comments for area you are touching:
1. Replace _rww writes to something else.
2. Protect with spinlock 32-bits writes instead of ignoring it.
Both of those changes will touch the same 2-4 lines and there
is very little benefit in creating more than one-two patches
just for that.
Thanks
>
> >
> > Thanks
> >
> > >
> > > --
> > > 2.20.1
> > >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH net] ip6mr: Fix notifiers call on mroute_clean_tables()
From: Nir Dotan @ 2019-01-27 7:26 UTC (permalink / raw)
To: netdev; +Cc: davem, nikolay, mlxsw, Nir Dotan
When the MC route socket is closed, mroute_clean_tables() is called to
cleanup existing routes. Mistakenly notifiers call was put on the cleanup
of the unresolved MC route entries cache.
In a case where the MC socket closes before an unresolved route expires,
the notifier call leads to a crash, caused by the driver trying to
increment a non initialized refcount_t object [1] and then when handling
is done, to decrement it [2]. This was detected by a test recently added in
commit 6d4efada3b82 ("selftests: forwarding: Add multicast routing test").
Fix that by putting notifiers call on the resolved entries traversal,
instead of on the unresolved entries traversal.
[1]
[ 245.748967] refcount_t: increment on 0; use-after-free.
[ 245.754829] WARNING: CPU: 3 PID: 3223 at lib/refcount.c:153 refcount_inc_checked+0x2b/0x30
...
[ 245.802357] Hardware name: Mellanox Technologies Ltd. MSN2740/SA001237, BIOS 5.6.5 06/07/2016
[ 245.811873] RIP: 0010:refcount_inc_checked+0x2b/0x30
...
[ 245.907487] Call Trace:
[ 245.910231] mlxsw_sp_router_fib_event.cold.181+0x42/0x47 [mlxsw_spectrum]
[ 245.917913] notifier_call_chain+0x45/0x7
[ 245.922484] atomic_notifier_call_chain+0x15/0x20
[ 245.927729] call_fib_notifiers+0x15/0x30
[ 245.932205] mroute_clean_tables+0x372/0x3f
[ 245.936971] ip6mr_sk_done+0xb1/0xc0
[ 245.940960] ip6_mroute_setsockopt+0x1da/0x5f0
...
[2]
[ 246.128487] refcount_t: underflow; use-after-free.
[ 246.133859] WARNING: CPU: 0 PID: 7 at lib/refcount.c:187 refcount_sub_and_test_checked+0x4c/0x60
[ 246.183521] Hardware name: Mellanox Technologies Ltd. MSN2740/SA001237, BIOS 5.6.5 06/07/2016
...
[ 246.193062] Workqueue: mlxsw_core_ordered mlxsw_sp_router_fibmr_event_work [mlxsw_spectrum]
[ 246.202394] RIP: 0010:refcount_sub_and_test_checked+0x4c/0x60
...
[ 246.298889] Call Trace:
[ 246.301617] refcount_dec_and_test_checked+0x11/0x20
[ 246.307170] mlxsw_sp_router_fibmr_event_work.cold.196+0x47/0x78 [mlxsw_spectrum]
[ 246.315531] process_one_work+0x1fa/0x3f0
[ 246.320005] worker_thread+0x2f/0x3e0
[ 246.324083] kthread+0x118/0x130
[ 246.327683] ? wq_update_unbound_numa+0x1b0/0x1b0
[ 246.332926] ? kthread_park+0x80/0x80
[ 246.337013] ret_from_fork+0x1f/0x30
Fixes: 088aa3eec2ce ("ip6mr: Support fib notifications")
Signed-off-by: Nir Dotan <nird@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
---
net/ipv6/ip6mr.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 30337b3..cc01aa3 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1516,6 +1516,9 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
continue;
rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
list_del_rcu(&c->list);
+ call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
+ FIB_EVENT_ENTRY_DEL,
+ (struct mfc6_cache *)c, mrt->id);
mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
mr_cache_put(c);
}
@@ -1524,10 +1527,6 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
spin_lock_bh(&mfc_unres_lock);
list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
list_del(&c->list);
- call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
- FIB_EVENT_ENTRY_DEL,
- (struct mfc6_cache *)c,
- mrt->id);
mr6_netlink_event(mrt, (struct mfc6_cache *)c,
RTM_DELROUTE);
ip6mr_destroy_unres(mrt, (struct mfc6_cache *)c);
--
2.8.4
^ permalink raw reply related
* Re: [PATCH net-next 1/1] openvswitch: Declare ovs key structures using macros
From: Eli Britstein @ 2019-01-27 6:37 UTC (permalink / raw)
To: David Miller
Cc: pshelar@ovn.org, netdev@vger.kernel.org, blp@ovn.org,
dev@openvswitch.org, Roi Dayan, simon.horman@netronome.com
In-Reply-To: <20190126.150405.955435491231261260.davem@davemloft.net>
On 1/27/2019 1:04 AM, David Miller wrote:
> From: Eli Britstein <elibr@mellanox.com>
> Date: Thu, 24 Jan 2019 11:46:47 +0200
>
>> Declare ovs key structures using macros to enable retrieving fields
>> information, with no functional change.
>>
>> Signed-off-by: Eli Britstein <elibr@mellanox.com>
>> Reviewed-by: Roi Dayan <roid@mellanox.com>
> I agree with Pravin, this need a much better commit message.
>
> Maybe even better to submit this alongside whatever is supposed
> to use these new macros.
This patch is equivalent to a work done in the OVS tree.
https://patchwork.ozlabs.org/patch/1023405/
As a standalone it doesn't serve any purpose (as mentioned - no
functional change).
It serves as a pre-step towards another patch in the OVS:
https://patchwork.ozlabs.org/patch/1022794/
So, the purpose of doing it in the kernel is just to keep this H file
identical. Once it is approved for the kernel, we will be able to
proceed with it in the OVS.
^ permalink raw reply
* Re: [PATCH] net: lmc: remove -I. header search path
From: David Miller @ 2019-01-27 2:27 UTC (permalink / raw)
To: yamada.masahiro; +Cc: netdev, linux-kernel
In-Reply-To: <1548426149-7961-1-git-send-email-yamada.masahiro@socionext.com>
From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Fri, 25 Jan 2019 23:22:29 +0900
> The header search path -I. in kernel Makefiles is very suspicious;
> it allows the compiler to search for headers in the top of $(srctree),
> where obviously no header file exists.
>
> I was able to build without this header search path.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied to net-next, thanks.
^ permalink raw reply
* [PATCH net] net: tls: Fix deadlock in free_resources tx
From: Dave Watson @ 2019-01-27 0:59 UTC (permalink / raw)
To: netdev@vger.kernel.org, Dave Miller
Cc: Vakul Garg, Boris Pismenny, Aviad Yehezkel, John Fastabend,
Daniel Borkmann
If there are outstanding async tx requests (when crypto returns EINPROGRESS),
there is a potential deadlock: the tx work acquires the lock, while we
cancel_delayed_work_sync() while holding the lock. Drop the lock while waiting
for the work to complete.
Fixes: a42055e8d2c30 ("Add support for async encryption of records...")
Signed-off-by: Dave Watson <davejwatson@fb.com>
---
net/tls/tls_sw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 7e963560edef..bf5b54b513bc 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1794,7 +1794,9 @@ void tls_sw_free_resources_tx(struct sock *sk)
if (atomic_read(&ctx->encrypt_pending))
crypto_wait_req(-EINPROGRESS, &ctx->async_wait);
+ release_sock(sk);
cancel_delayed_work_sync(&ctx->tx_work.work);
+ lock_sock(sk);
/* Tx whatever records we can transmit and abandon the rest */
tls_tx_records(sk, -1);
--
2.17.1
^ permalink raw reply related
* [PATCH net] net: tls: Save iv in tls_rec for async crypto requests
From: Dave Watson @ 2019-01-27 0:57 UTC (permalink / raw)
To: netdev@vger.kernel.org, Dave Miller
Cc: Vakul Garg, Boris Pismenny, Aviad Yehezkel, John Fastabend,
Daniel Borkmann
aead_request_set_crypt takes an iv pointer, and we change the iv
soon after setting it. Some async crypto algorithms don't save the iv,
so we need to save it in the tls_rec for async requests.
Found by hardcoding x64 aesni to use async crypto manager (to test the async
codepath), however I don't think this combination can happen in the wild.
Presumably other hardware offloads will need this fix, but there have been
no user reports.
Fixes: a42055e8d2c30 ("Add support for async encryption of records...")
Signed-off-by: Dave Watson <davejwatson@fb.com>
---
include/net/tls.h | 2 ++
net/tls/tls_sw.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index 2a6ac8d642af..1486b60c4de8 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -120,6 +120,8 @@ struct tls_rec {
struct scatterlist sg_aead_out[2];
char aad_space[TLS_AAD_SPACE_SIZE];
+ u8 iv_data[TLS_CIPHER_AES_GCM_128_IV_SIZE +
+ TLS_CIPHER_AES_GCM_128_SALT_SIZE];
struct aead_request aead_req;
u8 aead_req_ctx[];
};
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 11cdc8f7db63..7e963560edef 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -439,6 +439,8 @@ static int tls_do_encryption(struct sock *sk,
struct scatterlist *sge = sk_msg_elem(msg_en, start);
int rc;
+ memcpy(rec->iv_data, tls_ctx->tx.iv, sizeof(rec->iv_data));
+
sge->offset += tls_ctx->tx.prepend_size;
sge->length -= tls_ctx->tx.prepend_size;
@@ -448,7 +450,7 @@ static int tls_do_encryption(struct sock *sk,
aead_request_set_ad(aead_req, TLS_AAD_SPACE_SIZE);
aead_request_set_crypt(aead_req, rec->sg_aead_in,
rec->sg_aead_out,
- data_len, tls_ctx->tx.iv);
+ data_len, rec->iv_data);
aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_BACKLOG,
tls_encrypt_done, sk);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next V4 0/5] vhost: accelerate metadata access through vmap()
From: Michael S. Tsirkin @ 2019-01-27 0:31 UTC (permalink / raw)
To: David Miller; +Cc: jasowang, virtualization, netdev, linux-kernel, kvm
In-Reply-To: <20190126.143708.1203048880266877709.davem@davemloft.net>
On Sat, Jan 26, 2019 at 02:37:08PM -0800, David Miller wrote:
> From: Jason Wang <jasowang@redhat.com>
> Date: Wed, 23 Jan 2019 17:55:52 +0800
>
> > This series tries to access virtqueue metadata through kernel virtual
> > address instead of copy_user() friends since they had too much
> > overheads like checks, spec barriers or even hardware feature
> > toggling.
> >
> > Test shows about 24% improvement on TX PPS. It should benefit other
> > cases as well.
>
> I've read over the discussion of patch #5 a few times.
>
> And it seems to me that, at a minimum, a few things still need to
> be resolved:
>
> 1) More perf data added to commit message.
>
> 2) Whether invalidate_range_start() and invalidate_range_end() must
> be paired.
Add dirty tracking.
> Etc. So I am marking this series "Changes Requested".
^ permalink raw reply
* Re: [PATCH net-next 1/1] openvswitch: Declare ovs key structures using macros
From: David Miller @ 2019-01-26 23:04 UTC (permalink / raw)
To: elibr; +Cc: pshelar, netdev, blp, dev, roid, simon.horman
In-Reply-To: <20190124094647.24579-1-elibr@mellanox.com>
From: Eli Britstein <elibr@mellanox.com>
Date: Thu, 24 Jan 2019 11:46:47 +0200
> Declare ovs key structures using macros to enable retrieving fields
> information, with no functional change.
>
> Signed-off-by: Eli Britstein <elibr@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
I agree with Pravin, this need a much better commit message.
Maybe even better to submit this alongside whatever is supposed
to use these new macros.
^ permalink raw reply
* [PATCH net] net: set default network namespace in init_dummy_netdev()
From: Josh Elsasser @ 2019-01-26 22:38 UTC (permalink / raw)
To: David S. Miller
Cc: josh, Josh Elsasser, Edward Cree, Kirill Tkhai, Jiri Pirko,
Petr Machata, Eric Dumazet, Amritha Nambiar, Alexander Duyck,
Li RongQing, netdev, linux-kernel
Assign a default net namespace to netdevs created by init_dummy_netdev().
Fixes a NULL pointer dereference caused by busy-polling a socket bound to
an iwlwifi wireless device, which bumps the per-net BUSYPOLLRXPACKETS stat
if napi_poll() received packets:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000190
IP: napi_busy_loop+0xd6/0x200
Call Trace:
sock_poll+0x5e/0x80
do_sys_poll+0x324/0x5a0
SyS_poll+0x6c/0xf0
do_syscall_64+0x6b/0x1f0
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Fixes: 7db6b048da3b ("net: Commonize busy polling code to focus on napi_id instead of socket")
Signed-off-by: Josh Elsasser <jelsasser@appneta.com>
---
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 82f20022259d..d1043d49979c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8712,7 +8712,9 @@ int init_dummy_netdev(struct net_device *dev)
set_bit(__LINK_STATE_PRESENT, &dev->state);
set_bit(__LINK_STATE_START, &dev->state);
+ /* napi_busy_loop stats accounting wants this */
+ dev_net_set(dev, &init_net);
+
/* Note : We dont allocate pcpu_refcnt for dummy devices,
* because users of this 'device' dont need to change
* its refcount.
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next V4 0/5] vhost: accelerate metadata access through vmap()
From: David Miller @ 2019-01-26 22:37 UTC (permalink / raw)
To: jasowang; +Cc: virtualization, netdev, linux-kernel, mst, kvm
In-Reply-To: <20190123095557.30168-1-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 23 Jan 2019 17:55:52 +0800
> This series tries to access virtqueue metadata through kernel virtual
> address instead of copy_user() friends since they had too much
> overheads like checks, spec barriers or even hardware feature
> toggling.
>
> Test shows about 24% improvement on TX PPS. It should benefit other
> cases as well.
I've read over the discussion of patch #5 a few times.
And it seems to me that, at a minimum, a few things still need to
be resolved:
1) More perf data added to commit message.
2) Whether invalidate_range_start() and invalidate_range_end() must
be paired.
Etc. So I am marking this series "Changes Requested".
^ 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