* [PATCH 0/3] net/mlx5e: Kconfig fixes
From: Arnd Bergmann @ 2016-05-04 12:26 UTC (permalink / raw)
To: Matan Barak, Leon Romanovsky, Saeed Mahameed
Cc: netdev, linux-rdma, linux-kernel, arnd, davem
I saw two new build errors with invalid configurations on mlx5e, and a
closer look revealed that one of them was caused by a slightly incorrect
fix for which I had sent a different patch when it first broke.
This series reverts the new fix for the VXLAN problem as it caused
another bug, and follows up with a new version of my patch (adapted
as originally requested), and another patch for the simiar RFS
bug that was just introduced.
Arnd
^ permalink raw reply
* Re: [PATCHv2 bluetooth-next 04/10] ndisc: add addr_len parameter to ndisc_opt_addr_space
From: Alexander Aring @ 2016-05-04 12:30 UTC (permalink / raw)
To: Hannes Frederic Sowa, linux-wpan
Cc: kernel, marcel, jukka.rissanen, stefan, mcr, werner,
linux-bluetooth, netdev, David S . Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <109698cb-18ae-abdb-34a5-1db5a2e8dc6b@stressinduktion.org>
Hi,
On 05/02/2016 09:37 PM, Hannes Frederic Sowa wrote:
> On 20.04.2016 10:19, Alexander Aring wrote:
>> This patch makes the address length as argument for the
>> ndisc_opt_addr_space function. This is necessary to handle addresses
>> which don't use dev->addr_len as address length.
>
> Would it make sense for patch 4, 5 and 6 to add the operation to ndisc_ops?
>
not sure if I understand this question right,
We have now the ndisc_ops where we can could change the send/recv of
NS/NA, also is_useropt (for add 6CO RA is userspace option field).
In case of 802.15.4 we have two MAC addresses with different length:
- extended address - 8 bytes => EUI64
- short address - 2 bytes
Now [0] describes how to make the source/target address option for
NS/NA/RS/RA/... to deal with both addresses.
The short address is a special case in 802.15.4 and not always
available. If available we add both addresses as option field in
NS/NA (RS/RA will follow in future, but currently NS/NA only).
At this point the understanding of [0] differs in 6LoWPAN
implementations.
Some people handles it like:
Handle the short address/extended address in XOR case of 6LoWPAN
interface. The interface has as MAC address the extended XOR short (if
available), depends on setting.
Then dev->addr_len is 8 XOR 2.
Other people (inclusive me) handle it like:
Handle the short/extended address in case of OR, but never short address
alone. The interface can be accessed by extended address or short
address and each neighbour stores both information.
The case "short address never alone" means that the extended address is
always available and MUST be there.
Furthermore, depends on L3 addressing it could be useful to have the
possibility to decide if using or short OR extended address as L2 address
for do better compressing stuff.
---
I implement it as OR case, so we add both addresses when short address
is available. Also we drop NS/NA when the short address is given only,
in theory we could also react on this and store a "dummy" 0x00..00
address for extended address then.
Not sure how it need to be handled correctly, for now I implemented how
I understand it.
In case of the OR case, we need to add two option fields for the
address, extended and short. This is why I do the calculation stuff more
accessible with different address lengths, so we can use 8 or 2 and not
dev->addr_len which stores always the 802.15.4 EUI64 address length.
And the answer would be, no it makes no sense because we need to call
these functions with 8 (dev->addr_len) and 2 (if short addr is
available).
- Alex
[0] https://tools.ietf.org/html/rfc4944#section-8
^ permalink raw reply
* [PATCH 2/3] net/mlx5e: make VXLAN support conditional
From: Arnd Bergmann @ 2016-05-04 12:31 UTC (permalink / raw)
To: Matan Barak, Leon Romanovsky, Saeed Mahameed
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Matthew Finlay, Richard Cochran,
Amir Vadai, Haggai Abramonvsky, Maor Gottlieb, Or Gerlitz,
Majd Dibbiny, Achiad Shochat, Tariq Toukan, Gal Pressman
In-Reply-To: <1462364774-3792510-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
VXLAN can be disabled at compile-time or it can be a loadable
module while mlx5 is built-in, which leads to a link error:
drivers/net/built-in.o: In function `mlx5e_create_netdev':
ntb_netdev.c:(.text+0x106de4): undefined reference to `vxlan_get_rx_port'
This avoids the link error and makes the vxlan code optional,
like the other ethernet drivers do as well.
Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Link: https://patchwork.ozlabs.org/patch/589296/
Fixes: b3f63c3d5e2c ("net/mlx5e: Add netdev support for VXLAN tunneling")
---
I sent it originally on Feb 26 2016, but misread Saeed Mahameed's
reply as saying that he'd fix it up himself. The new version
should address the original comment.
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 7 +++++++
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 4 +++-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++++
drivers/net/ethernet/mellanox/mlx5/core/vxlan.h | 11 +++++++++--
5 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index 1cf722eba607..f5c3b9465d8d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -31,3 +31,10 @@ config MLX5_CORE_EN_DCB
This flag is depended on the kernel's DCB support.
If unsure, set to Y
+
+config MLX5_CORE_EN_VXLAN
+ bool "VXLAN offloads Support"
+ default y
+ depends on MLX5_CORE_EN && VXLAN && !(MLX5_CORE=y && VXLAN=m)
+ ---help---
+ Say Y here if you want to use VXLAN offloads in the driver.
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index 679e18ffb3a6..6b8da0b36acd 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -6,7 +6,9 @@ mlx5_core-y := main.o cmd.o debugfs.o fw.o eq.o uar.o pagealloc.o \
mlx5_core-$(CONFIG_MLX5_CORE_EN) += wq.o eswitch.o \
en_main.o en_fs.o en_ethtool.o en_tx.o en_rx.o \
- en_txrx.o en_clock.o vxlan.o en_tc.o
+ en_txrx.o en_clock.o en_tc.o
+
+mlx5_core-$(CONFIG_MLX5_CORE_EN_VXLAN) += vxlan.o
mlx5_core-$(CONFIG_MLX5_CORE_EN_DCB) += en_dcbnl.o
mlx5_core-$(CONFIG_RFS_ACCEL) += en_arfs.o
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index bfa5daaaf5aa..19b1b021af2d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -522,7 +522,9 @@ struct mlx5e_priv {
struct mlx5e_direct_tir direct_tir[MLX5E_MAX_NUM_CHANNELS];
struct mlx5e_flow_steering fs;
+#ifdef CONFIG_MLX5_CORE_EN_VXLAN
struct mlx5e_vxlan_db vxlan;
+#endif
struct mlx5e_params params;
struct workqueue_struct *wq;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 7dfb73aa8e41..5e710315c5a9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -2494,6 +2494,7 @@ static int mlx5e_get_vf_stats(struct net_device *dev,
vf_stats);
}
+#if IS_ENABLED(CONFIG_MLX5_CORE_EN_VXLAN)
static void mlx5e_add_vxlan_port(struct net_device *netdev,
sa_family_t sa_family, __be16 port)
{
@@ -2565,6 +2566,7 @@ static netdev_features_t mlx5e_features_check(struct sk_buff *skb,
return features;
}
+#endif
static const struct net_device_ops mlx5e_netdev_ops_basic = {
.ndo_open = mlx5e_open,
@@ -2599,9 +2601,11 @@ static const struct net_device_ops mlx5e_netdev_ops_sriov = {
.ndo_set_features = mlx5e_set_features,
.ndo_change_mtu = mlx5e_change_mtu,
.ndo_do_ioctl = mlx5e_ioctl,
+#ifdef CONFIG_MLX5_CORE_EN_VXLAN
.ndo_add_vxlan_port = mlx5e_add_vxlan_port,
.ndo_del_vxlan_port = mlx5e_del_vxlan_port,
.ndo_features_check = mlx5e_features_check,
+#endif
#ifdef CONFIG_RFS_ACCEL
.ndo_rx_flow_steer = mlx5e_rx_flow_steer,
#endif
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h b/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h
index 129f3527aa14..217ac530a514 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h
@@ -48,14 +48,21 @@ struct mlx5e_vxlan_work {
static inline bool mlx5e_vxlan_allowed(struct mlx5_core_dev *mdev)
{
- return (MLX5_CAP_ETH(mdev, tunnel_stateless_vxlan) &&
+ return IS_ENABLED(CONFIG_MLX5_CORE_EN_VXLAN) &&
+ (MLX5_CAP_ETH(mdev, tunnel_stateless_vxlan) &&
mlx5_core_is_pf(mdev));
}
+#ifdef CONFIG_MLX5_CORE_EN_VXLAN
void mlx5e_vxlan_init(struct mlx5e_priv *priv);
+void mlx5e_vxlan_cleanup(struct mlx5e_priv *priv);
+#else
+static inline void mlx5e_vxlan_init(struct mlx5e_priv *priv) {}
+static inline void mlx5e_vxlan_cleanup(struct mlx5e_priv *priv) {}
+#endif
+
void mlx5e_vxlan_queue_work(struct mlx5e_priv *priv, sa_family_t sa_family,
u16 port, int add);
struct mlx5e_vxlan *mlx5e_vxlan_lookup_port(struct mlx5e_priv *priv, u16 port);
-void mlx5e_vxlan_cleanup(struct mlx5e_priv *priv);
#endif /* __MLX5_VXLAN_H__ */
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net] net/mlx4_en: Fix endianness bug in IPV6 csum calculation
From: Tariq Toukan @ 2016-05-04 12:00 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Daniel Jurgens, Tariq Toukan
From: Daniel Jurgens <danielj@mellanox.com>
Use htons instead of unconditionally byte swapping nexthdr. On a little
endian systems shifting the byte is correct behavior, but it results in
incorrect csums on big endian architectures.
Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Reviewed-by: Carol Soto <clsoto@us.ibm.com>
Tested-by: Carol Soto <clsoto@us.ibm.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index b723e3b..ca3a384 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -707,7 +707,7 @@ static int get_fixed_ipv6_csum(__wsum hw_checksum, struct sk_buff *skb,
if (ipv6h->nexthdr == IPPROTO_FRAGMENT || ipv6h->nexthdr == IPPROTO_HOPOPTS)
return -1;
- hw_checksum = csum_add(hw_checksum, (__force __wsum)(ipv6h->nexthdr << 8));
+ hw_checksum = csum_add(hw_checksum, (__force __wsum)htons(ipv6h->nexthdr));
csum_pseudo_hdr = csum_partial(&ipv6h->saddr,
sizeof(ipv6h->saddr) + sizeof(ipv6h->daddr), 0);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/3] net/mlx5e: don't build RFS without ethernet
From: Arnd Bergmann @ 2016-05-04 12:32 UTC (permalink / raw)
To: Matan Barak, Leon Romanovsky, Saeed Mahameed
Cc: netdev, linux-rdma, linux-kernel, arnd, davem, Matthew Finlay,
Richard Cochran, Amir Vadai, Haggai Abramonvsky, Maor Gottlieb,
Or Gerlitz, Majd Dibbiny
In-Reply-To: <1462364774-3792510-1-git-send-email-arnd@arndb.de>
The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
because the rfs code now calls into the ethernet portion of the
driver:
ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
This patch adds another Kconfig symbol to control the compilation of
the RFS code, to ensure it is only built if both the ethernet support
and the core RFS support are enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 4 ++++
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index f5c3b9465d8d..5efba14a1453 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -38,3 +38,7 @@ config MLX5_CORE_EN_VXLAN
depends on MLX5_CORE_EN && VXLAN && !(MLX5_CORE=y && VXLAN=m)
---help---
Say Y here if you want to use VXLAN offloads in the driver.
+
+config MLX5_CORE_EN_RFS
+ def_bool y
+ depends on MLX5_CORE_EN && RFS_ACCEL
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index 6b8da0b36acd..29118c1debb7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -11,4 +11,4 @@ mlx5_core-$(CONFIG_MLX5_CORE_EN) += wq.o eswitch.o \
mlx5_core-$(CONFIG_MLX5_CORE_EN_VXLAN) += vxlan.o
mlx5_core-$(CONFIG_MLX5_CORE_EN_DCB) += en_dcbnl.o
-mlx5_core-$(CONFIG_RFS_ACCEL) += en_arfs.o
+mlx5_core-$(CONFIG_MLX5_CORE_EN_RFS) += en_arfs.o
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
From: Nicolas Dichtel @ 2016-05-04 12:49 UTC (permalink / raw)
To: David Miller, netdev, philipp.reisner, drbd-dev, linux-kernel
In-Reply-To: <20160504090529.GJ16459@soda.linbit>
Le 04/05/2016 11:05, Lars Ellenberg a écrit :
[snip]
> We don't have an "alignment problem" there, btw.
> Last time I checked, we did work fine without this alignment magic,
> we already take care of that, yes, even on affected architectures.
The code adds several consecutive u64 attributes. The nl attribute header is 4
bytes, thus the full attribute length is 12 bytes. If the first u64 is aligned
on 8 (nla_data()), the next one is not aligned on 8: it starts 12 bytes (8 (u64)
+ 4 (nl attr hdr)) after the previous u64.
^ permalink raw reply
* Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
From: Lars Ellenberg @ 2016-05-04 12:52 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, drbd-dev-cunTk1MwBs8qoQakbn7OcQ,
David Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA
In-Reply-To: <5729EFBC.7040002-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Wed, May 04, 2016 at 02:49:00PM +0200, Nicolas Dichtel wrote:
> Le 04/05/2016 11:05, Lars Ellenberg a écrit :
> [snip]
> > We don't have an "alignment problem" there, btw.
> > Last time I checked, we did work fine without this alignment magic,
> > we already take care of that, yes, even on affected architectures.
> The code adds several consecutive u64 attributes. The nl attribute header is 4
> bytes, thus the full attribute length is 12 bytes. If the first u64 is aligned
> on 8 (nla_data()), the next one is not aligned on 8: it starts 12 bytes (8 (u64)
> + 4 (nl attr hdr)) after the previous u64.
Yes. Which in our case is not a problem.
But I don't object to the padding per se,
if that is how things "should be".
I try to understand why you so much object to using 0 as pad.
Lars
^ permalink raw reply
* [PATCH] ravb: Add missing free_irq() calls to ravb_close()
From: Geert Uytterhoeven @ 2016-05-04 13:03 UTC (permalink / raw)
To: David S. Miller, Sergei Shtylyov
Cc: Yoshihiro Kaneko, Simon Horman, netdev, linux-renesas-soc,
Geert Uytterhoeven
When reopening the network device on ra7795/salvator-x, e.g. after a
DHCP timeout:
IP-Config: Reopening network devices...
genirq: Flags mismatch irq 139. 00000000 (eth0:ch24:emac) vs. 00000000 (eth0:ch24:emac)
ravb e6800000.ethernet eth0: cannot request IRQ eth0:ch24:emac
IP-Config: Failed to open eth0
IP-Config: No network devices available
The "mismatch" is due to requesting an IRQ that is already in use,
while IRQF_PROBE_SHARED wasn't set.
However, the real cause is that ravb_close() doesn't release any of the
R-Car Gen3-specific secondary IRQs.
Add the missing free_irq() calls to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/net/ethernet/renesas/ravb_main.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 34066e0649f5c673..867caf6e7a5a65ad 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1667,6 +1667,13 @@ static int ravb_close(struct net_device *ndev)
priv->phydev = NULL;
}
+ if (priv->chip_id != RCAR_GEN2) {
+ free_irq(priv->tx_irqs[RAVB_NC], ndev);
+ free_irq(priv->rx_irqs[RAVB_NC], ndev);
+ free_irq(priv->tx_irqs[RAVB_BE], ndev);
+ free_irq(priv->rx_irqs[RAVB_BE], ndev);
+ free_irq(priv->emac_irq, ndev);
+ }
free_irq(ndev->irq, ndev);
napi_disable(&priv->napi[RAVB_NC]);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/3] net/mlx5e: don't build RFS without ethernet
From: Saeed Mahameed @ 2016-05-04 13:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Matan Barak, Leon Romanovsky, Saeed Mahameed, Linux Netdev List,
linux-rdma, linux-kernel, David S. Miller, Matthew Finlay,
Richard Cochran, Amir Vadai, Haggai Abramonvsky, Maor Gottlieb,
Or Gerlitz, Majd Dibbiny
In-Reply-To: <1462365155-3861405-1-git-send-email-arnd@arndb.de>
On Wed, May 4, 2016 at 3:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
> is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
> because the rfs code now calls into the ethernet portion of the
> driver:
>
> ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
>
Hi Arnd,
We already posted a fix for this, please see "[PATCH net-next V1
01/12] net/mlx5e: Fix aRFS compilation dependency", and give us your
feedback.
Saeed.
^ permalink raw reply
* Re: [PATCH net] igmp: fix byte order in /proc/net/igmp output
From: Eric Dumazet @ 2016-05-04 13:13 UTC (permalink / raw)
To: Eugene Crosser; +Cc: crosser, netdev
In-Reply-To: <1462363884-34968-1-git-send-email-Eugene.Crosser@ru.ibm.com>
On Wed, 2016-05-04 at 14:11 +0200, Eugene Crosser wrote:
> /proc/net/igmp is a readonly attribute that shows multicast groups
> to which different network interfaces are subscribed. Among other
> things, it displays `multiaddr` which is a 32 bit network-byte-order
> field, in hexadecimal format. Prior to this patch, the field was
> displayed as an integer, resulting in reverse byte order on little
> endian architectures. This patch converts it with ntohl() for display
> the same way as this is done for the /proc/net/mcfilter attribute.
>
> The patch changes (corrects) user-visible behaviour.
>
> Signed-off-by: Eugene Crosser <Eugene.Crosser@ru.ibm.com>
> ---
> net/ipv4/igmp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index b3086cf..f9d2139 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -2722,7 +2722,7 @@ static int igmp_mc_seq_show(struct seq_file *seq, void *v)
> delta = im->timer.expires - jiffies;
> seq_printf(seq,
> "\t\t\t\t%08X %5d %d:%08lX\t\t%d\n",
> - im->multiaddr, im->users,
> + ntohl(im->multiaddr), im->users,
> im->tm_running,
> im->tm_running ? jiffies_delta_to_clock_t(delta) : 0,
> im->reporter);
I do not believe we can change this. This is unfortunately too late.
/proc/net/tcp has the same 'issue' or if you prefer, well known
behavior.
Such change would break basically all /proc/net/igmp users.
^ permalink raw reply
* [PATCH] VSOCK: do not disconnect socket when peer has shutdown SEND only
From: Ian Campbell @ 2016-05-04 13:21 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, David S. Miller, Stefan Hajnoczi, Claudio Imbrenda,
Andy King, Dmitry Torokhov, Jorgen Hansen, Adit Ranadive
The peer may be expecting a reply having sent a request and then done a
shutdown(SHUT_WR), so tearing down the whole socket at this point seems
wrong and breaks for me with a client which does a SHUT_WR.
Looking at other socket family's stream_recvmsg callbacks doing a shutdown
here does not seem to be the norm and removing it does not seem to have
had any adverse effects that I can see.
I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
on the vmci transport.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Cc: Andy King <acking@vmware.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: Jorgen Hansen <jhansen@vmware.com>
Cc: Adit Ranadive <aditr@vmware.com>
Cc: netdev@vger.kernel.org
---
net/vmw_vsock/af_vsock.c | 21 +--------------------
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 1e5f5ed..7a25150 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1789,27 +1789,8 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
else if (sk->sk_shutdown & RCV_SHUTDOWN)
err = 0;
- if (copied > 0) {
- /* We only do these additional bookkeeping/notification steps
- * if we actually copied something out of the queue pair
- * instead of just peeking ahead.
- */
-
- if (!(flags & MSG_PEEK)) {
- /* If the other side has shutdown for sending and there
- * is nothing more to read, then modify the socket
- * state.
- */
- if (vsk->peer_shutdown & SEND_SHUTDOWN) {
- if (vsock_stream_has_data(vsk) <= 0) {
- sk->sk_state = SS_UNCONNECTED;
- sock_set_flag(sk, SOCK_DONE);
- sk->sk_state_change(sk);
- }
- }
- }
+ if (copied > 0)
err = copied;
- }
out:
release_sock(sk);
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] ravb: Add missing free_irq() calls to ravb_close()
From: Sergei Shtylyov @ 2016-05-04 13:30 UTC (permalink / raw)
To: Geert Uytterhoeven, David S. Miller
Cc: Yoshihiro Kaneko, Simon Horman, netdev, linux-renesas-soc
In-Reply-To: <1462366987-18418-1-git-send-email-geert+renesas@glider.be>
Hello.
On 05/04/2016 04:03 PM, Geert Uytterhoeven wrote:
> When reopening the network device on ra7795/salvator-x, e.g. after a
> DHCP timeout:
>
> IP-Config: Reopening network devices...
> genirq: Flags mismatch irq 139. 00000000 (eth0:ch24:emac) vs. 00000000 (eth0:ch24:emac)
> ravb e6800000.ethernet eth0: cannot request IRQ eth0:ch24:emac
> IP-Config: Failed to open eth0
> IP-Config: No network devices available
>
> The "mismatch" is due to requesting an IRQ that is already in use,
> while IRQF_PROBE_SHARED wasn't set.
>
> However, the real cause is that ravb_close() doesn't release any of the
> R-Car Gen3-specific secondary IRQs.
>
> Add the missing free_irq() calls to fix this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
This patch must be against net-next.git but you because the patch that
this one fixes is only there. You never indicated that. I'd also appreciate if
you specify the Fixed: tag.
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 34066e0649f5c673..867caf6e7a5a65ad 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1667,6 +1667,13 @@ static int ravb_close(struct net_device *ndev)
> priv->phydev = NULL;
> }
>
> + if (priv->chip_id != RCAR_GEN2) {
> + free_irq(priv->tx_irqs[RAVB_NC], ndev);
> + free_irq(priv->rx_irqs[RAVB_NC], ndev);
> + free_irq(priv->tx_irqs[RAVB_BE], ndev);
> + free_irq(priv->rx_irqs[RAVB_BE], ndev);
Shame on me for not noticing this. :-(
> + free_irq(priv->emac_irq, ndev);
However, net.git is also affected, it only calls free_irq() on 'ndev->irq'.
Please submit 2 separate fixes against net.git and net-next.git.
> + }
> free_irq(ndev->irq, ndev);
>
> napi_disable(&priv->napi[RAVB_NC]);
>
MBR, Sergei
^ permalink raw reply
* Re: Regression: netlink fail (triggered by iw) removes extra wlan (phy) interface
From: Rafał Miłecki @ 2016-05-04 13:33 UTC (permalink / raw)
To: Cong Wang
Cc: Network Development, Herbert Xu, Tejun Heo, Cong Wang,
David Miller, Tom Herbert, Martin KaFai Lau, kernel-team,
Linux Kernel Mailing List, Linus Torvalds, Jiri Pirko,
Nicolas Dichtel, Thomas Graf, Scott Feldman
In-Reply-To: <CAM_iQpW_63Di76BcnSF35h1+ezxv8G62NT0U=tWFFe6n9FaNig@mail.gmail.com>
Hi again and sorry for the late reply.
On 16 March 2016 at 17:00, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Feb 25, 2016 at 5:22 AM, Rafał Miłecki <zajec5@gmail.com> wrote:
>> After updating kernel in OpenWrt from 4.1.6 to 4.1.10 I noticed that
>> if "iw" command fails (which happens very rarely) my wlan0-1 interface
>> disappears. To trigger this problem easily I'm using this trivial
>> script:
>> while [ 1 ]
>> do
>> iw phy phy0 interface add mon0 type monitor
>> ifconfig mon0 up
>> iw dev mon0 del
>> done
>>
>> Whenever it goes wrong I see:
>> Failed to connect to generic netlink.
>> kern.info kernel: [ 1933.114338] br-lan: port 3(wlan0-1) entered disabled state
>> kern.info kernel: [ 1933.335568] device wlan0-1 left promiscuous mode
>> kern.info kernel: [ 1933.340385] br-lan: port 3(wlan0-1) entered disabled state
>> daemon.notice netifd: Network device 'wlan0-1' link is down
>> command failed: Too many open files in system (-23)
>>
>
> Note, for 4.1, the backport is known to be incorrect, and it is
> fixed later by:
>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/net/netlink/af_netlink.c?h=linux-4.1.y&id=a52ec6de6d1638e8c203d7188c55627f75371612
>
>
>> This regression is caused by commit:
>> 4e27762 netlink: Fix autobind race condition that leads to zero port ID
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=4e27762417669cb459971635be550eb7b5598286
>> that is a backport of upstream:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f770c0a09da855a2b51af6d19de97fb955eca85
>>
>> This still happens with kernel 4.4.
>
>
> Looks like the goto is missing in 4.4 branch too. ;) Mind to send a patch
> to GregKH?
So I just tried kernel 4.1.23 and got that problem again while running
my bash script:
Failed to connect to generic netlink.
ifconfig: SIOCGIFFLAGS: No such device
command failed: No such device (-19)
[ 2200.114464] br-lan: port 3(wlan0-1) entered disabled state
[ 2200.125979] device wlan0-1 left promiscuous mode
[ 2200.134529] br-lan: port 3(wlan0-1) entered disabled state
Failed to connect to generic netlink.
ifconfig: SIOCGIFFLAGS: No such device
command failed: No such device (-19)
--
Rafał
^ permalink raw reply
* Re: [PATCH net] igmp: fix byte order in /proc/net/igmp output
From: Evgeny Cherkashin @ 2016-05-04 13:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: crosser, netdev
In-Reply-To: <1462367616.5535.340.camel@edumazet-glaptop3.roam.corp.google.com>
-----Eric Dumazet <eric.dumazet@gmail.com> wrote: -----
>To: Evgeny Cherkashin/Russia/IBM@IBMRU
>From: Eric Dumazet <eric.dumazet@gmail.com>
>Date: 2016-05-04 16:13
>Cc: crosser@average.org, netdev@vger.kernel.org
>Subject: Re: [PATCH net] igmp: fix byte order in /proc/net/igmp
>output
>
>On Wed, 2016-05-04 at 14:11 +0200, Eugene Crosser wrote:
>> /proc/net/igmp is a readonly attribute that shows multicast groups
>> to which different network interfaces are subscribed. Among other
>> things, it displays `multiaddr` which is a 32 bit
>network-byte-order
>> field, in hexadecimal format. Prior to this patch, the field was
>> displayed as an integer, resulting in reverse byte order on little
>> endian architectures. This patch converts it with ntohl() for
>display
>> the same way as this is done for the /proc/net/mcfilter attribute.
>>
>> The patch changes (corrects) user-visible behaviour.
>>
>> Signed-off-by: Eugene Crosser <Eugene.Crosser@ru.ibm.com>
>> ---
>> net/ipv4/igmp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
>> index b3086cf..f9d2139 100644
>> --- a/net/ipv4/igmp.c
>> +++ b/net/ipv4/igmp.c
>> @@ -2722,7 +2722,7 @@ static int igmp_mc_seq_show(struct seq_file
>*seq, void *v)
>> delta = im->timer.expires - jiffies;
>> seq_printf(seq,
>> "\t\t\t\t%08X %5d %d:%08lX\t\t%d\n",
>> - im->multiaddr, im->users,
>> + ntohl(im->multiaddr), im->users,
>> im->tm_running,
>> im->tm_running ? jiffies_delta_to_clock_t(delta) : 0,
>> im->reporter);
>
>
>I do not believe we can change this. This is unfortunately too late.
>
>/proc/net/tcp has the same 'issue' or if you prefer, well known
>behavior.
>
>Such change would break basically all /proc/net/igmp users.
I understand that. It is unfortunate though that the byte order is not _just_ wrong, it's _different_ on BE and LE machines...
Oh well.
Thanks,
Eugene
^ permalink raw reply
* [PATCH net] net: bridge: fix old ioctl unlocked net device walk
From: Nikolay Aleksandrov @ 2016-05-04 14:18 UTC (permalink / raw)
To: netdev; +Cc: roopa, stephen, davem, Nikolay Aleksandrov
get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
calls which aren't called with rtnl held. The comment above says that it is
called with rtnl but that is not really the case.
Here's a sample output from a test ASSERT_RTNL() which I put in
get_bridge_ifindices and executed "brctl show":
[ 957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
[ 957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G W O
4.6.0-rc4+ #157
[ 957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[ 957.423009] 0000000000000000 ffff880058adfdf0 ffffffff8138dec5
0000000000000400
[ 957.423009] ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
0000000000000001
[ 957.423009] 00007ffec1a444b0 0000000000000400 ffff880053c19130
0000000000008940
[ 957.423009] Call Trace:
[ 957.423009] [<ffffffff8138dec5>] dump_stack+0x85/0xc0
[ 957.423009] [<ffffffffa05ead32>]
br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
[ 957.423009] [<ffffffff81515beb>] sock_ioctl+0x22b/0x290
[ 957.423009] [<ffffffff8126ba75>] do_vfs_ioctl+0x95/0x700
[ 957.423009] [<ffffffff8126c159>] SyS_ioctl+0x79/0x90
[ 957.423009] [<ffffffff8163a4c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
Since it only reads bridge ifindices, we can use rcu to safely walk the net
device list. Also remove the wrong rtnl comment above.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
AFAICT this has been present since the beginning of git history thus no
fixes tag.
net/bridge/br_ioctl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c
index 263b4de4de57..60a3dbfca8a1 100644
--- a/net/bridge/br_ioctl.c
+++ b/net/bridge/br_ioctl.c
@@ -21,18 +21,19 @@
#include <asm/uaccess.h>
#include "br_private.h"
-/* called with RTNL */
static int get_bridge_ifindices(struct net *net, int *indices, int num)
{
struct net_device *dev;
int i = 0;
- for_each_netdev(net, dev) {
+ rcu_read_lock();
+ for_each_netdev_rcu(net, dev) {
if (i >= num)
break;
if (dev->priv_flags & IFF_EBRIDGE)
indices[i++] = dev->ifindex;
}
+ rcu_read_unlock();
return i;
}
--
2.4.11
^ permalink raw reply related
* Re: [PATCH 3/3] net/mlx5e: don't build RFS without ethernet
From: Arnd Bergmann @ 2016-05-04 14:23 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Matan Barak, Leon Romanovsky, Saeed Mahameed, Linux Netdev List,
linux-rdma, linux-kernel, David S. Miller, Matthew Finlay,
Richard Cochran, Amir Vadai, Haggai Abramonvsky, Maor Gottlieb,
Or Gerlitz, Majd Dibbiny
In-Reply-To: <CALzJLG9j6ZodwDToX8iuvNVKLoMoaM8V9w8cFR6jM-ktU0ynHg@mail.gmail.com>
On Wednesday 04 May 2016 16:09:16 Saeed Mahameed wrote:
> On Wed, May 4, 2016 at 3:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
> > is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
> > because the rfs code now calls into the ethernet portion of the
> > driver:
> >
> > ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
> >
>
> Hi Arnd,
>
> We already posted a fix for this, please see "[PATCH net-next V1
> 01/12] net/mlx5e: Fix aRFS compilation dependency", and give us your
> feedback.
That version looks fine as well. I think it's better to be a little
more explicit as I was, but either way seems fine.
You can also achieve the same thing in yet another way using Makefile
syntax instead of cpp or Kconfig:
ifdef CONFIG_MLX5_CORE_EN
mlx5_core-y += wq.o eswitch.o \
en_main.o en_fs.o en_ethtool.o en_tx.o en_rx.o \
en_txrx.o en_clock.o vxlan.o en_tc.o
en_txrx.o en_clock.o vxlan.o en_tc.o en_arfs.o
mlx5_core-$(CONFIG_RFS_ACCEL) += en_arfs.o
endif
If you prefer Maor's version, feel free to add
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
From: Eric Dumazet @ 2016-05-04 14:27 UTC (permalink / raw)
To: nicolas.dichtel
Cc: David Miller, netdev, philipp.reisner, drbd-dev, linux-kernel
In-Reply-To: <5729EFBC.7040002@6wind.com>
On Wed, 2016-05-04 at 14:49 +0200, Nicolas Dichtel wrote:
> Le 04/05/2016 11:05, Lars Ellenberg a écrit :
> [snip]
> > We don't have an "alignment problem" there, btw.
> > Last time I checked, we did work fine without this alignment magic,
> > we already take care of that, yes, even on affected architectures.
> The code adds several consecutive u64 attributes. The nl attribute header is 4
> bytes, thus the full attribute length is 12 bytes. If the first u64 is aligned
> on 8 (nla_data()), the next one is not aligned on 8: it starts 12 bytes (8 (u64)
> + 4 (nl attr hdr)) after the previous u64.
As I mentioned earlier ( https://lkml.org/lkml/2016/4/22/706 ), if both
kernel and user land do not blindly use *(u64 *)ptr to put/get these
values, there was no issue.
kernel was fine, and most user land apps were fine as well.
Only for compound struct like tcp_info this was nice to get alignment
for performance reason (it removed one memcpy(), or the use of
put_unaligned() helpers)
^ permalink raw reply
* Re: [PATCH 3/3] net/mlx5e: don't build RFS without ethernet
From: Saeed Mahameed @ 2016-05-04 14:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Matan Barak, Leon Romanovsky, Saeed Mahameed, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Matthew Finlay, Richard Cochran, Amir Vadai, Haggai Abramonvsky,
Maor Gottlieb, Or Gerlitz, Majd Dibbiny
In-Reply-To: <6481938.m1ihicFdKr@wuerfel>
On Wed, May 4, 2016 at 5:23 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday 04 May 2016 16:09:16 Saeed Mahameed wrote:
>> On Wed, May 4, 2016 at 3:32 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> > The RFS acceleration support in mlx5 is enabled whenever CONFIG_RFS_ACCEL
>> > is in use. However, this fails if a user turns off CONFIG_MLX5_CORE_EN,
>> > because the rfs code now calls into the ethernet portion of the
>> > driver:
>> >
>> > ERROR: "mlx5e_destroy_flow_table" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!
>> >
>>
>> Hi Arnd,
>>
>> We already posted a fix for this, please see "[PATCH net-next V1
>> 01/12] net/mlx5e: Fix aRFS compilation dependency", and give us your
>> feedback.
>
> That version looks fine as well. I think it's better to be a little
> more explicit as I was, but either way seems fine.
>
Simply we didn't want to add new Kconfig flag.
>
> You can also achieve the same thing in yet another way using Makefile
> syntax instead of cpp or Kconfig:
>
> ifdef CONFIG_MLX5_CORE_EN
> mlx5_core-y += wq.o eswitch.o \
> en_main.o en_fs.o en_ethtool.o en_tx.o en_rx.o \
> en_txrx.o en_clock.o vxlan.o en_tc.o
> en_txrx.o en_clock.o vxlan.o en_tc.o en_arfs.o
>
> mlx5_core-$(CONFIG_RFS_ACCEL) += en_arfs.o
> endif
>
>
> If you prefer Maor's version, feel free to add
>
>
> Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>
I do prefer this version, but the difference is small, so will keep Maor's.
Thanks Arnd for the Ack and the suggestion.
Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] bridge: fix igmp / mld query parsing
From: Linus Lüssing @ 2016-05-04 14:59 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Simon Wunderlich, netdev, bridge, David S . Miller, linux-kernel
In-Reply-To: <20160503132623.59cf54fb@xeon-e3>
On Tue, May 03, 2016 at 01:26:23PM -0700, Stephen Hemminger wrote:
> On Tue, 3 May 2016 22:18:54 +0200
> Linus Lüssing <linus.luessing@c0d3.blue> wrote:
>
> > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> > index 03661d9..7105cdf 100644
> > --- a/net/bridge/br_multicast.c
> > +++ b/net/bridge/br_multicast.c
> > @@ -1271,6 +1271,7 @@ static int br_ip4_multicast_query(struct net_bridge *br,
> > unsigned long max_delay;
> > unsigned long now = jiffies;
> > __be32 group;
> > + int offset = skb_transport_offset(skb);
> shouldn't this be unsigned?
Yes, should always be unsigned here.
Ok, I'm changing that (even though skb_transport_offset() is "static
inline int").
^ permalink raw reply
* [PATCHv2 net] bridge: fix igmp / mld query parsing
From: Linus Lüssing @ 2016-05-04 15:25 UTC (permalink / raw)
To: netdev; +Cc: Simon Wunderlich, bridge, linux-kernel, David S . Miller
With the newly introduced helper functions the skb pulling is hidden
in the checksumming function - and undone before returning to the
caller.
The IGMP and MLD query parsing functions in the bridge still
assumed that the skb is pointing to the beginning of the IGMP/MLD
message while it is now kept at the beginning of the IPv4/6 header.
If there is a querier somewhere else, then this either causes
the multicast snooping to stay disabled even though it could be
enabled. Or, if we have the querier enabled too, then this can
create unnecessary IGMP / MLD query messages on the link.
Fixing this by taking the offset between IP and IGMP/MLD header into
account, too.
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
---
v2: changed "int" to "unsigned int"
net/bridge/br_multicast.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 03661d9..ea98937 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1270,6 +1270,7 @@ static int br_ip4_multicast_query(struct net_bridge *br,
struct br_ip saddr;
unsigned long max_delay;
unsigned long now = jiffies;
+ unsigned int offset = skb_transport_offset(skb);
__be32 group;
int err = 0;
@@ -1280,14 +1281,14 @@ static int br_ip4_multicast_query(struct net_bridge *br,
group = ih->group;
- if (skb->len == sizeof(*ih)) {
+ if (skb->len == offset + sizeof(*ih)) {
max_delay = ih->code * (HZ / IGMP_TIMER_SCALE);
if (!max_delay) {
max_delay = 10 * HZ;
group = 0;
}
- } else if (skb->len >= sizeof(*ih3)) {
+ } else if (skb->len >= offset + sizeof(*ih3)) {
ih3 = igmpv3_query_hdr(skb);
if (ih3->nsrcs)
goto out;
@@ -1348,6 +1349,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
struct br_ip saddr;
unsigned long max_delay;
unsigned long now = jiffies;
+ unsigned int offset = skb_transport_offset(skb);
const struct in6_addr *group = NULL;
bool is_general_query;
int err = 0;
@@ -1357,8 +1359,8 @@ static int br_ip6_multicast_query(struct net_bridge *br,
(port && port->state == BR_STATE_DISABLED))
goto out;
- if (skb->len == sizeof(*mld)) {
- if (!pskb_may_pull(skb, sizeof(*mld))) {
+ if (skb->len == offset + sizeof(*mld)) {
+ if (!pskb_may_pull(skb, offset + sizeof(*mld))) {
err = -EINVAL;
goto out;
}
@@ -1367,7 +1369,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
if (max_delay)
group = &mld->mld_mca;
} else {
- if (!pskb_may_pull(skb, sizeof(*mld2q))) {
+ if (!pskb_may_pull(skb, offset + sizeof(*mld2q))) {
err = -EINVAL;
goto out;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Or Gerlitz @ 2016-05-04 15:50 UTC (permalink / raw)
To: Alexander Duyck, Tom Herbert
Cc: Or Gerlitz, Alexander Duyck, talal@mellanox.com,
Linux Netdev List, Michael Chan, David Miller, Gal Pressman,
Eran Ben Elisha
In-Reply-To: <CAKgT0UeK2ss9AsxdvyDHArXXVZMZG7AL6f0iXQukSg135B64cQ@mail.gmail.com>
On 5/3/2016 6:29 PM, Alexander Duyck wrote:
> We split the one that would be a different size off via GSO. So we
> end up sending up 2 frames to the device if there is going to be one
> piece that doesn't quite match. We split that one piece off via GSO.
> That is one of the reasons why I referred to it as partial GSO as all
> we are using the software segmentation code for is to make sure we
> have the GSO block consists of segments that are all the same size.
I see, so if somehow it happens a lot that the TCP stack sends down
something which once segmented ends up with the last segment being of
different size from the other ones we would have to call the NIC xmit
function twice (BTW can we use xmit_more here?) -- which could be
effecting performance, I guess.
GSO_UDP_TUNNEL_CSUM (commit 0f4f4ffa7 "net: Add GSO support for UDP
tunnels with checksum") came to mark "that a device is capable of
computing the UDP checksum in the encapsulating header of a UDP tunnel"
-- and the way we use it here is that we do advertize that bit towards
the stack for devices whose HW can **not** do that, and things work b/c
of LCO (this is my understanding).
I miss something in the bigger picture here, what does this buy us? e.g
vs just letting this (say) vxlan tunnel use zero checksum on the outer
UDP packet, is that has something to do with RCO?
Or.
^ permalink raw reply
* Re: [PATCH net v2] vlan: Propagate MAC address to VLANs unless explicitly set
From: David Miller @ 2016-05-04 15:58 UTC (permalink / raw)
To: mkubecek; +Cc: mmanning, netdev
In-Reply-To: <20160504092801.GC19967@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Wed, 4 May 2016 11:28:02 +0200
> The commit message says "unless explicitly changed for the VLAN" but
> what you really check is "if it is the same as real device MAC address".
> This, in general, is not the same. (I believe this is what David tries
> to explain from the start.)
Even more proof that these MAC checks are rediculous, confusing, and
that we need to use a boolean state stores in the vlan private in
order to implement the intended semantics properly and more importantly
"clearly".
^ permalink raw reply
* Re: [patch net-next] vrf: add exit function and allow module unload
From: David Miller @ 2016-05-04 15:59 UTC (permalink / raw)
To: jiri; +Cc: hannes, netdev, idosch, eladr, yotamg, dsa, shm
In-Reply-To: <20160504102455.GB1947@nanopsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 4 May 2016 12:24:55 +0200
> Wed, May 04, 2016 at 12:23:42PM CEST, hannes@stressinduktion.org wrote:
>>Hello Jiri,
>>
>>On Wed, May 4, 2016, at 12:20, Jiri Pirko wrote:
>>> drivers/net/vrf.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
>>> index 8a8f1e5..b217c2d 100644
>>> --- a/drivers/net/vrf.c
>>> +++ b/drivers/net/vrf.c
>>> @@ -839,7 +839,14 @@ error:
>>> return rc;
>>> }
>>>
>>> +static void __exit vrf_exit_module(void)
>>> +{
>>> + rtnl_link_unregister(&vrf_link_ops);
>>> + unregister_netdevice_notifier(&vrf_notifier_block);
>>> +}
>>> +
>>> module_init(vrf_init_module);
>>> +module_exit(vrf_exit_module);
>>
>>The dst_entries created by vrf don't carry a reference to THIS_MODULE
>>but have a code dependency to the vrf module (e.g. via
>>vrf_output/vrf_output6) that gets published. This is exactly the same
>>why ipv6 cannot be unloaded.
>
> Oh. Okay. Thanks!
So I'm dropping this.
^ permalink raw reply
* Re: [patch net-next] vrf: add exit function and allow module unload
From: David Ahern @ 2016-05-04 16:05 UTC (permalink / raw)
To: Hannes Frederic Sowa, Jiri Pirko, netdev
Cc: davem, idosch, eladr, yotamg, shm
In-Reply-To: <1462357422.1666076.597731009.4C5E1305@webmail.messagingengine.com>
On 5/4/16 4:23 AM, Hannes Frederic Sowa wrote:
> Hello Jiri,
>
> On Wed, May 4, 2016, at 12:20, Jiri Pirko wrote:
>> drivers/net/vrf.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
>> index 8a8f1e5..b217c2d 100644
>> --- a/drivers/net/vrf.c
>> +++ b/drivers/net/vrf.c
>> @@ -839,7 +839,14 @@ error:
>> return rc;
>> }
>>
>> +static void __exit vrf_exit_module(void)
>> +{
>> + rtnl_link_unregister(&vrf_link_ops);
>> + unregister_netdevice_notifier(&vrf_notifier_block);
>> +}
>> +
>> module_init(vrf_init_module);
>> +module_exit(vrf_exit_module);
>
> The dst_entries created by vrf don't carry a reference to THIS_MODULE
> but have a code dependency to the vrf module (e.g. via
> vrf_output/vrf_output6) that gets published. This is exactly the same
> why ipv6 cannot be unloaded.
exactly. The module exit was removed recently by 9ab179d83b4e ("net:
vrf: Fix dst reference counting")
^ permalink raw reply
* Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Alex Duyck @ 2016-05-04 16:06 UTC (permalink / raw)
To: Or Gerlitz
Cc: Alexander Duyck, Tom Herbert, Or Gerlitz, talal@mellanox.com,
Linux Netdev List, Michael Chan, David Miller, Gal Pressman,
Eran Ben Elisha
In-Reply-To: <572A1A49.9020507@mellanox.com>
On Wed, May 4, 2016 at 8:50 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 5/3/2016 6:29 PM, Alexander Duyck wrote:
>>
>> We split the one that would be a different size off via GSO. So we
>> end up sending up 2 frames to the device if there is going to be one
>> piece that doesn't quite match. We split that one piece off via GSO.
>> That is one of the reasons why I referred to it as partial GSO as all
>> we are using the software segmentation code for is to make sure we
>> have the GSO block consists of segments that are all the same size.
>
>
> I see, so if somehow it happens a lot that the TCP stack sends down
> something which once segmented ends up with the last segment being of
> different size from the other ones we would have to call the NIC xmit
> function twice (BTW can we use xmit_more here?) -- which could be effecting
> performance, I guess.
>
> GSO_UDP_TUNNEL_CSUM (commit 0f4f4ffa7 "net: Add GSO support for UDP tunnels
> with checksum") came to mark "that a device is capable of computing the UDP
> checksum in the encapsulating header of a UDP tunnel" -- and the way we use
> it here is that we do advertize that bit towards the stack for devices whose
> HW can **not** do that, and things work b/c of LCO (this is my
> understanding).
>
> I miss something in the bigger picture here, what does this buy us? e.g vs
> just letting this (say) vxlan tunnel use zero checksum on the outer UDP
> packet, is that has something to do with RCO?
I think the piece you are missing is GSO_PARTIAL. Basically
GSO_PARTIAL indicates that we can perform GSO as long as all segments
are the same size and also allows for ignoring one level of headers.
So in the case of ixgbe for instance we can support tunnel offloads as
long as we allow for the inner IPv4 ID to be a fixed value which is
identified by enabling TSO_MANGLEID. In the case of i40e, mlx4, and
mlx5 the key bit is that we just have to have the frames the same size
for all segments and then we can support tunnels with outer checksum
because the checksum has been computed once and can be applied to all
of the segmented frames.
Hope that helps.
- Alex
^ 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