* Re: [PATCH] VSOCK: do not disconnect socket when peer has shutdown SEND only
From: Stefan Hajnoczi @ 2016-05-05 18:23 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, David S. Miller, Claudio Imbrenda, Andy King,
Dmitry Torokhov, Jorgen Hansen, Adit Ranadive
In-Reply-To: <1462368113-5493-1-git-send-email-ian.campbell@docker.com>
[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]
On Wed, May 04, 2016 at 02:21:53PM +0100, Ian Campbell wrote:
> 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.
Seems fine to me.
> 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
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] net/mlx5e: make VXLAN support conditional
From: Arnd Bergmann @ 2016-05-05 18:09 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, Achiad Shochat, Tariq Toukan,
Gal Pressman
In-Reply-To: <CALzJLG885q-Nm4xD3FobvY4A9RhLAV3jLwfAWdJwyDOid+tJ6g@mail.gmail.com>
On Thursday 05 May 2016 19:44:36 Saeed Mahameed wrote:
> On Wed, May 4, 2016 at 3:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 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@arndb.de>
> > 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.
> > ---
>
> Hi Arnd,
>
> I didn't post a fix up since it is not needed anymore, see
> b7aade15485a ('vxlan: break dependency with netdev drivers') in
> net-next.
>
> The new issue is introduced due to : "net/mlx5: Kconfig: Fix
> MLX5_EN/VXLAN build issue" which was merged from net tree.
>
> Dave shouldn't have merged it into net-next, I explicitly asked him
> that in the cover letter. Maybe he missed it.
>
> I just checked and It is sufficient to only take the revert patch:
> [PATCH 1/3] Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
> to net-next.
>
> Can you please confirm that with only the revert patch, you don't see
> the issue ?
Yes, it works, but not it is different from all the other drivers
(MLX4, BENET, IXGBE, I40E, FM10K, QLCNIC, and QEDE). If the 'select
VXLAN' is not the preferred way to handle this, we should change
the other ones the same way, right?
For reference, I've tried it out on the MLX4 driver, and it does
seem nicer that way, see below.
Arnd
---
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
in case someone wants to pick up that patch and do the other
ones as well.
diff --git a/drivers/net/ethernet/mellanox/mlx4/Kconfig b/drivers/net/ethernet/mellanox/mlx4/Kconfig
index 9ca3734ebb6b..88fff4484200 100644
--- a/drivers/net/ethernet/mellanox/mlx4/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx4/Kconfig
@@ -6,6 +6,7 @@ config MLX4_EN
tristate "Mellanox Technologies 1/10/40Gbit Ethernet support"
depends on MAY_USE_DEVLINK
depends on PCI
+ select VXLAN
select MLX4_CORE
select PTP_1588_CLOCK
---help---
@@ -24,13 +25,6 @@ config MLX4_EN_DCB
If unsure, set to Y
-config MLX4_EN_VXLAN
- bool "VXLAN offloads Support"
- default y
- depends on MLX4_EN && VXLAN && !(MLX4_EN=y && VXLAN=m)
- ---help---
- Say Y here if you want to use VXLAN offloads in the driver.
-
config MLX4_CORE
tristate
depends on PCI
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 6f28ac58251c..ad887c425f2d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1691,10 +1691,8 @@ int mlx4_en_start_port(struct net_device *dev)
/* Schedule multicast task to populate multicast list */
queue_work(mdev->workqueue, &priv->rx_mode_task);
-#ifdef CONFIG_MLX4_EN_VXLAN
if (priv->mdev->dev->caps.tunnel_offload_mode == MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
vxlan_get_rx_port(dev);
-#endif
priv->port_up = true;
netif_tx_start_all_queues(dev);
netif_device_attach(dev);
@@ -2337,7 +2335,6 @@ static int mlx4_en_get_phys_port_id(struct net_device *dev,
return 0;
}
-#ifdef CONFIG_MLX4_EN_VXLAN
static void mlx4_en_add_vxlan_offloads(struct work_struct *work)
{
int ret;
@@ -2448,7 +2445,6 @@ static netdev_features_t mlx4_en_features_check(struct sk_buff *skb,
return features;
}
-#endif
static int mlx4_en_set_tx_maxrate(struct net_device *dev, int queue_index, u32 maxrate)
{
@@ -2501,11 +2497,9 @@ static const struct net_device_ops mlx4_netdev_ops = {
.ndo_rx_flow_steer = mlx4_en_filter_rfs,
#endif
.ndo_get_phys_port_id = mlx4_en_get_phys_port_id,
-#ifdef CONFIG_MLX4_EN_VXLAN
.ndo_add_vxlan_port = mlx4_en_add_vxlan_port,
.ndo_del_vxlan_port = mlx4_en_del_vxlan_port,
.ndo_features_check = mlx4_en_features_check,
-#endif
.ndo_set_tx_maxrate = mlx4_en_set_tx_maxrate,
};
@@ -2539,11 +2533,9 @@ static const struct net_device_ops mlx4_netdev_ops_master = {
.ndo_rx_flow_steer = mlx4_en_filter_rfs,
#endif
.ndo_get_phys_port_id = mlx4_en_get_phys_port_id,
-#ifdef CONFIG_MLX4_EN_VXLAN
.ndo_add_vxlan_port = mlx4_en_add_vxlan_port,
.ndo_del_vxlan_port = mlx4_en_del_vxlan_port,
.ndo_features_check = mlx4_en_features_check,
-#endif
.ndo_set_tx_maxrate = mlx4_en_set_tx_maxrate,
};
@@ -2834,10 +2826,8 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
INIT_WORK(&priv->linkstate_task, mlx4_en_linkstate);
INIT_DELAYED_WORK(&priv->stats_task, mlx4_en_do_get_stats);
INIT_DELAYED_WORK(&priv->service_task, mlx4_en_service_task);
-#ifdef CONFIG_MLX4_EN_VXLAN
INIT_WORK(&priv->vxlan_add_task, mlx4_en_add_vxlan_offloads);
INIT_WORK(&priv->vxlan_del_task, mlx4_en_del_vxlan_offloads);
-#endif
#ifdef CONFIG_RFS_ACCEL
INIT_LIST_HEAD(&priv->filters);
spin_lock_init(&priv->filters_lock);
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 63b1aeae2c03..cbab8741d60f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -546,10 +546,8 @@ struct mlx4_en_priv {
struct work_struct linkstate_task;
struct delayed_work stats_task;
struct delayed_work service_task;
-#ifdef CONFIG_MLX4_EN_VXLAN
struct work_struct vxlan_add_task;
struct work_struct vxlan_del_task;
-#endif
struct mlx4_en_perf_stats pstats;
struct mlx4_en_pkt_stats pkstats;
struct mlx4_en_counter_stats pf_stats;
^ permalink raw reply related
* Re: [PATCH net-next 14/14] ip4ip6: Support for GSO/GRO
From: Alexander Duyck @ 2016-05-05 17:48 UTC (permalink / raw)
To: Tom Herbert; +Cc: Eric Dumazet, David Miller, Netdev, Kernel Team
In-Reply-To: <CALx6S37w8526zZNLbguatYkDv63iJaGyht2BYCfym=-XoPTxEw@mail.gmail.com>
On Thu, May 5, 2016 at 9:48 AM, Tom Herbert <tom@herbertland.com> wrote:
> On Wed, May 4, 2016 at 8:26 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Wed, May 4, 2016 at 6:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Wed, 2016-05-04 at 18:02 -0700, Tom Herbert wrote:
>>>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>>>> ---
>>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>>> index 928b456..6a811fa 100644
>>>> --- a/include/linux/skbuff.h
>>>> +++ b/include/linux/skbuff.h
>>>> @@ -484,6 +484,8 @@ enum {
>>>> SKB_GSO_TUNNEL_REMCSUM = 1 << 14,
>>>>
>>>> SKB_GSO_IP6IP6 = 1 << 15,
>>>> +
>>>> + SKB_GSO_IP4IP6 = 1 << 16,
>>>> };
>>>>
>>>
>>> Houston, we have a problem.
>>>
>>> gso_type is 16bit (unsigned short), or maybe I missed something ?
>>>
>>> struct skb_shared_info {
>>> unsigned char nr_frags;
>>> __u8 tx_flags;
>>> unsigned short gso_size;
>>> unsigned short gso_segs;
>>> unsigned short gso_type; <<-->>
>>
>> No, I am pretty sure you have it right. We are out of bits.
>>
>> Also it seems like we are generating a number of duplicate entries.
>> What is the difference between IP6IP6 and SIT over IPv6? I'm not
>> really seeing the difference.
>>
>> I'm wondering if maybe we shouldn't look at the possibly using the
>> IPIP and SIT bits to instead indicate that the frame is encapsulated
>> in an outer IPv4 or outer IPv6 header since we already have TCPV4 and
>> TCPV6 to indicate if the inner network type is a V4 or V6. Then there
>> is no need for this patch set to introduce any new tunnel types to be
>> segmented since all cases should be covered. As far as I can tell
>> SKB_GSO_IPIP/SIT were never really being tested against anyway so we
>> might want to go the IPIPV4 IPIPV6 route instead as that is probably
>> closer to what most device limitations would be.
>>
> My worry is that the current public interface means IPIP is IPv4 over
> IPv4, and SIT means IPv6 over IPv4. There are some drivers advertising
> offload support for these so I don't think we safely redefine
> SKB_GSO_IPIP/SIT.
The group is pretty small, and they all advertise support for SIT and
IPIP. Even if they don't support an outer IPv6 tunnel it just means
we are essentially combining the 2 bits into 1.
In the case of the Intel drivers that advertise support for it they
could support the change without any issue since the use the header
pointers to set the offsets of the inner and outer headers and don't
care if they are v4 or v6.
> For finding more bits in gso_type there are some SKB_GOS_* that are
> not really types at all but more flags. I'm going try to turn
> SKB_GSO_DODGY into a skbuff for the purposes here. We'll still have
> the problem of running out bits next time a new type is added (maybe
> SKB_GSO_SCTP?) but can probably make room for one or two more. Longer
> term I think the the solution is too eliminate gso_type altogether as
> we are once again running into the problem of trying to indicate a
> combinatorial set of constraints and complex layering in a just few
> flag bits.
Still, I don't think there is much gain to be had by specifying the
inner network type twice, once in the outer tunnel segmentation type,
and then again in the inner TCP segmentation type. That is why I was
thinking it would be better to just specify an IPIPV4 and IPIPV6 since
then you can run v4 or v6 on the inside and let TSOV4 or TSOV6 in the
hw_enc_features take care of specifying if you can support inner IPV6
or not.
- Alex
^ permalink raw reply
* Re: [PATCH 3/3] net-next: mediatek: add RX delay support
From: John Crispin @ 2016-05-05 17:37 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linux-mediatek, David S. Miller, linux-kernel, nbd
In-Reply-To: <20160505121353.GE7972@lunn.ch>
On 05/05/2016 14:13, Andrew Lunn wrote:
> On Thu, May 05, 2016 at 11:17:36AM +0200, John Crispin wrote:
>> If an external Gigabit PHY is connected to either of the MACs we need to
>> tell the to use a RX delay. Not doing so will result in heavy packet loss
>> and/or data corruption of RX traffic.
>
> Hi John
>
> Is this comment correct? Reading the code, all this switch statement
> does is select between RGMII, MII and RMII. It has nothing to do with
> delay. I suspect the PHY is doing the delay, not the MAC, since you
> pass the phy mode to of_phy_connect().
>
> If my interpretation of the code is correct, you might also want to
> handle PHY_INTERFACE_MODE_RGMII_TXID and PHY_INTERFACE_MODE_RGMII_ID
> which are also RGMII modes.
>
> Andrew
Hi Andrew,
the comment is indeed incorrect and the PHY needs to handle the delay. i
will send a V2 and also add _TXID and _ID
John
^ permalink raw reply
* Re: [PATCH v9 net-next 4/7] openvswitch: add layer 3 flow/port support
From: pravin shelar @ 2016-05-05 17:37 UTC (permalink / raw)
To: Simon Horman; +Cc: ovs dev, Linux Kernel Network Developers
In-Reply-To: <1462347393-22354-5-git-send-email-simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
On Wed, May 4, 2016 at 12:36 AM, Simon Horman
<simon.horman@netronome.com> wrote:
> From: Lorand Jakab <lojakab@cisco.com>
>
> Implementation of the pop_eth and push_eth actions in the kernel, and
> layer 3 flow support.
>
> This doesn't actually do anything yet as no layer 2 tunnel ports are
> supported yet. The original patch by Lorand was against the Open vSwtich
> tree which has L2 LISP tunnels but that is not supported in mainline Linux.
> I (Simon) plan to follow up with support for non-TEB GRE ports based on
> work by Thomas Morin.
>
> Cc: Thomas Morin <thomas.morin@orange.com>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
>
> ---
...
> diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
> index 0ea128eeeab2..6e174ea5f2bb 100644
> --- a/net/openvswitch/flow.c
> +++ b/net/openvswitch/flow.c
> @@ -468,28 +468,31 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
>
> skb_reset_mac_header(skb);
>
> - /* Link layer. We are guaranteed to have at least the 14 byte Ethernet
> - * header in the linear data area.
> - */
> - eth = eth_hdr(skb);
> - ether_addr_copy(key->eth.src, eth->h_source);
> - ether_addr_copy(key->eth.dst, eth->h_dest);
> + /* Link layer. */
> + if (key->phy.is_layer3) {
> + key->eth.tci = 0;
> + key->eth.type = skb->protocol;
> + } else {
> + eth = eth_hdr(skb);
> + ether_addr_copy(key->eth.src, eth->h_source);
> + ether_addr_copy(key->eth.dst, eth->h_dest);
>
> - __skb_pull(skb, 2 * ETH_ALEN);
> - /* We are going to push all headers that we pull, so no need to
> - * update skb->csum here.
> - */
> + __skb_pull(skb, 2 * ETH_ALEN);
> + /* We are going to push all headers that we pull, so no need to
> + * update skb->csum here.
> + */
>
> - key->eth.tci = 0;
> - if (skb_vlan_tag_present(skb))
> - key->eth.tci = htons(skb->vlan_tci);
> - else if (eth->h_proto == htons(ETH_P_8021Q))
> - if (unlikely(parse_vlan(skb, key)))
> - return -ENOMEM;
> + key->eth.tci = 0;
> + if (skb_vlan_tag_present(skb))
> + key->eth.tci = htons(skb->vlan_tci);
> + else if (eth->h_proto == htons(ETH_P_8021Q))
> + if (unlikely(parse_vlan(skb, key)))
> + return -ENOMEM;
>
> - key->eth.type = parse_ethertype(skb);
> - if (unlikely(key->eth.type == htons(0)))
> - return -ENOMEM;
> + key->eth.type = parse_ethertype(skb);
> + if (unlikely(key->eth.type == htons(0)))
> + return -ENOMEM;
> + }
>
> skb_reset_network_header(skb);
> skb_reset_mac_len(skb);
> @@ -696,11 +699,23 @@ int ovs_flow_key_update(struct sk_buff *skb, struct sw_flow_key *key)
> int ovs_flow_key_extract(const struct ip_tunnel_info *tun_info,
> struct sk_buff *skb, struct sw_flow_key *key)
> {
> + bool is_layer3 = false;
> + bool is_teb = false;
is_layer3 and is_teb are mutually exclusive, so can't we use single
boolean here?
> + int err;
> +
> /* Extract metadata from packet. */
> if (tun_info) {
> key->tun_proto = ip_tunnel_info_af(tun_info);
> memcpy(&key->tun_key, &tun_info->key, sizeof(key->tun_key));
>
> + if (OVS_CB(skb)->input_vport->dev->type != ARPHRD_ETHER) {
> + if (skb->protocol == htons(ETH_P_TEB))
> + is_teb = true;
> + else
> + is_layer3 = true;
> + }
> +
On transmit side you are using mac_len to detect l3 packet, why not do
same while extracting the key?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH v9 net-next 3/7] openvswitch: add support to push and pop mpls for layer3 packets
From: pravin shelar @ 2016-05-05 17:35 UTC (permalink / raw)
To: Simon Horman; +Cc: ovs dev, Linux Kernel Network Developers
In-Reply-To: <1462347393-22354-4-git-send-email-simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
On Wed, May 4, 2016 at 12:36 AM, Simon Horman
<simon.horman@netronome.com> wrote:
> Allow push and pop mpls actions to act on layer 3 packets by teaching
> them not to access non-existent L2 headers of such packets.
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
> v9
> * New Patch
> ---
> net/openvswitch/actions.c | 22 ++++++++++++++--------
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 879185fe183f..fe885a89f501 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -160,8 +160,10 @@ static int push_mpls(struct sk_buff *skb, struct sw_flow_key *key,
>
> skb_postpush_rcsum(skb, new_mpls_lse, MPLS_HLEN);
>
> - hdr = eth_hdr(skb);
> - hdr->h_proto = mpls->mpls_ethertype;
> + if (skb->mac_len) {
can you move hdr definition to this block?
> + hdr = eth_hdr(skb);
> + hdr->h_proto = mpls->mpls_ethertype;
> + }
>
We need to update skb checksum here. This bug is not related to your
patch. since you are changing this code can you also fix this?
> if (!skb->inner_protocol)
> skb_set_inner_protocol(skb, skb->protocol);
> @@ -174,7 +176,6 @@ static int push_mpls(struct sk_buff *skb, struct sw_flow_key *key,
> static int pop_mpls(struct sk_buff *skb, struct sw_flow_key *key,
> const __be16 ethertype)
> {
> - struct ethhdr *hdr;
> int err;
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [PATCH] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring
From: Wang YanQing @ 2016-05-05 17:19 UTC (permalink / raw)
To: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
Cc: chaoming_li-kXabqFNEczNtrwSWzY7KCg, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
We can't use kfree_skb in irq disable context, because spin_lock_irqsave
make sure we are always in irq disable context, use dev_kfree_skb_irq
instead of kfree_skb is better than dev_kfree_skb_any.
This patch fix below kernel warning:
[ 7612.095528] ------------[ cut here ]------------
[ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80()
[ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common
[ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G W 4.4.0+ #4
[ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015
[ 7612.095574] 00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454
[ 7612.095584] 00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400
[ 7612.095594] f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8
[ 7612.095604] Call Trace:
[ 7612.095614] [<c12ce7c5>] dump_stack+0x41/0x5c
[ 7612.095620] [<c104cc59>] warn_slowpath_common+0x89/0xc0
[ 7612.095628] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095634] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095640] [<c104ccad>] warn_slowpath_null+0x1d/0x20
[ 7612.095646] [<c10508a8>] __local_bh_enable_ip+0x58/0x80
[ 7612.095653] [<c16b7d34>] destroy_conntrack+0x64/0xa0
[ 7612.095660] [<c16b300f>] nf_conntrack_destroy+0xf/0x20
[ 7612.095665] [<c1677565>] skb_release_head_state+0x55/0xa0
[ 7612.095670] [<c16775bb>] skb_release_all+0xb/0x20
[ 7612.095674] [<c167760b>] __kfree_skb+0xb/0x60
[ 7612.095679] [<c16776f0>] kfree_skb+0x30/0x70
[ 7612.095686] [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095692] [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095698] [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci]
[ 7612.095705] [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi]
[ 7612.095712] [<c17e3f16>] drv_start+0x36/0xc0
[ 7612.095717] [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890
[ 7612.095725] [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60
[ 7612.095730] [<c17f60bd>] ieee80211_open+0x4d/0x50
[ 7612.095736] [<c16891b3>] __dev_open+0xa3/0x130
[ 7612.095742] [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20
[ 7612.095748] [<c1689499>] __dev_change_flags+0x89/0x140
[ 7612.095753] [<c127c70d>] ? selinux_capable+0xd/0x10
[ 7612.095759] [<c1689589>] dev_change_flags+0x29/0x60
[ 7612.095765] [<c1700b93>] devinet_ioctl+0x553/0x670
[ 7612.095772] [<c12db758>] ? _copy_to_user+0x28/0x40
[ 7612.095777] [<c17018b5>] inet_ioctl+0x85/0xb0
[ 7612.095783] [<c166e647>] sock_ioctl+0x67/0x260
[ 7612.095788] [<c166e5e0>] ? sock_fasync+0x80/0x80
[ 7612.095795] [<c115c99b>] do_vfs_ioctl+0x6b/0x550
[ 7612.095800] [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0
[ 7612.095807] [<c10a8914>] ? timekeeping_suspend+0x294/0x320
[ 7612.095813] [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210
[ 7612.095820] [<c1276e24>] ? security_file_ioctl+0x34/0x50
[ 7612.095827] [<c115cef0>] SyS_ioctl+0x70/0x80
[ 7612.095832] [<c1001804>] do_fast_syscall_32+0x84/0x120
[ 7612.095839] [<c183ff91>] sysenter_past_esp+0x36/0x55
[ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
Signed-off-by: Wang YanQing <udknight-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 1ac41b8..99a3a03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
true,
HW_DESC_TXBUFF_ADDR),
skb->len, PCI_DMA_TODEVICE);
- kfree_skb(skb);
+ dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
ring->idx = 0;
--
1.8.5.6.2.g3d8a54e.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: mlx5 core/en oops in 4.6-rc6+
From: Doug Ledford @ 2016-05-05 17:16 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: Linux Netdev List
In-Reply-To: <CALzJLG9_PLzU=Qwvv=_3aEd0KQr1c9rZyfcrfuLPo8wF=F_B0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5654 bytes --]
On 05/05/2016 12:42 PM, Saeed Mahameed wrote:
> On Thu, May 5, 2016 at 7:00 PM, Doug Ledford <dledford@redhat.com> wrote:
>> Just had this pop up during testing, happened very soon after bootup:
>>
[ snip oops ]
> Hi Doug,
>
> did you by change configure TC queues for the netdev ? i.e. dev->num_tc > 1
> if not i would be happy to get more info in you network configuration.
That depends on which interface actually generated the oops. If it was
the base interface, then I don't manually set any special params on it.
If it's one of the vlan interfaces, then there is a NetworkManager
dispatcher script that is intended to set the tc count on interface up:
[root@rdma-virt-03 ~]$ more /etc/NetworkManager/dispatcher.d/98-mlx5_roce.4*
::::::::::::::
/etc/NetworkManager/dispatcher.d/98-mlx5_roce.43-egress.conf
::::::::::::::
#!/bin/sh
interface=$1
status=$2
[ "$interface" = mlx5_roce.43 ] || exit 0
case $status in
up)
tc qdisc add dev mlx5_roce root mqprio num_tc 8 map 5 5 5 5 5 5 5 5 5 5
5 5 5 5 5 5
# tc_wrap.py -i mlx5_roce -u 5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
;;
esac
--More--(Next file:
/etc/NetworkManager/dispatcher.d/98-mlx5_roce.45-egress.conf::::::::::::::
/etc/NetworkManager/dispatcher.d/98-mlx5_roce.45-egress.conf
::::::::::::::
#!/bin/sh
interface=$1
status=$2
[ "$interface" = mlx5_roce.45 ] || exit 0
case $status in
up)
tc qdisc add dev mlx5_roce root mqprio num_tc 8 map 5 5 5 5 5 5 5 5 5 5
5 5 5 5 5 5
# tc_wrap.py -i mlx5_roce -u 5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
;;
esac
[root@rdma-virt-03 ~]$
However, I should note that this usage of tc is a bit out of date last I
checked and doesn't even work any more. Let me double check...
[root@rdma-virt-02 vlan]$ cd /proc/net/vlan/
[root@rdma-virt-02 vlan]$ ls
config mlx5_roce.43 mlx5_roce.45
[root@rdma-virt-02 vlan]$
[root@rdma-virt-02 vlan]$ for i in *; do echo "$i:"; cat $i; echo; done
config:
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
mlx5_roce.45 | 45 | mlx5_roce
mlx5_roce.43 | 43 | mlx5_roce
mlx5_roce.43:
mlx5_roce.43 VID: 43 REORDER_HDR: 1 dev->priv_flags: 1001
total frames received 57
total bytes received 5010
Broadcast/Multicast Rcvd 0
total frames transmitted 20
total bytes transmitted 2525
Device: mlx5_roce
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:3 1:3 2:3 3:3 4:3 5:3 6:3 7:3
mlx5_roce.45:
mlx5_roce.45 VID: 45 REORDER_HDR: 1 dev->priv_flags: 1001
total frames received 57
total bytes received 5010
Broadcast/Multicast Rcvd 0
total frames transmitted 21
total bytes transmitted 2603
Device: mlx5_roce
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5
OK, so the vlans have egress mappings, but they don't match what the
mlx5_roce.43 egress.conf file should have enabled. Digging a little
further on this machine:
[root@rdma-virt-03 vlan]$ more
/etc/sysconfig/network-scripts/ifcfg-mlx5_roce.4?
::::::::::::::
/etc/sysconfig/network-scripts/ifcfg-mlx5_roce.43
::::::::::::::
DEVICE=mlx5_roce.43
VLAN=yes
VLAN_ID=43
VLAN_EGRESS_PRIORITY_MAP=0:3,1:3,2:3,3:3,4:3,5:3,6:3,7:3
TYPE=Vlan
ONBOOT=yes
BOOTPROTO=dhcp
DEFROUTE=no
PEERDNS=no
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=no
IPV6_PEERDNS=no
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=mlx5_roce.43
::::::::::::::
/etc/sysconfig/network-scripts/ifcfg-mlx5_roce.45
::::::::::::::
DEVICE=mlx5_roce.45
VLAN=yes
VLAN_ID=45
VLAN_EGRESS_PRIORITY_MAP=0:5,1:5,2:5,3:5,4:5,5:5,6:5,7:5
TYPE=Vlan
ONBOOT=yes
BOOTPROTO=dhcp
DEFROUTE=no
PEERDNS=no
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=no
IPV6_PEERDNS=no
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=mlx5_roce.45
[root@rdma-virt-03 vlan]$
This is a Fedora rawhide machine, using NetworkManager to handle the
network interfaces. So, the egress priority mappings are being set by
NM. I don't know if they are overriding the egress mapping dispatchers
or if the egress mapping dispatchers are failing to work/run properly.
It might be the latter. Let me double check the command...
OK, re-reading the egress dispatchers above, they work on the base
interface, not on the vlan interface that triggers them. That's why
they both use the same command (mapping to egress 5) instead of being
like the ifcfg files, which map the 43 vlan to egress priority 3, and
the 45 vlan to egress priority 5. Running tc qdisc | grep mlx5_roce
shows that the egress mapping is being applied (although I'm not sure it
should be...I made that mapping many kernels ago when that was the right
thing to do, the modern mlx5 ethernet drivers create their own mappings
that are drastically different).
So, to answer your question, yes, num_tc > 1, num_tc == 8, and I
probably need to reconfigure that egress dispatcher to do what I want it
to do (which is merely to make sure that all packets from specific
interfaces are tagged with specific vlan priorities so per-priority flow
control between the card and switch works properly, the base interface
is supposed to have no priority tag, the 43 vlan is supposed to have
priority tag 3, and vlan 45 is supposed to have priority tag 5) on
modern kernels.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 14/14] ip4ip6: Support for GSO/GRO
From: Tom Herbert @ 2016-05-05 16:48 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Eric Dumazet, David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0UciiUQMfPodReb3MyX-Y+X9do9vGmz5kwcttQtsLJVRRA@mail.gmail.com>
On Wed, May 4, 2016 at 8:26 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Wed, May 4, 2016 at 6:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Wed, 2016-05-04 at 18:02 -0700, Tom Herbert wrote:
>>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>>> ---
>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>> index 928b456..6a811fa 100644
>>> --- a/include/linux/skbuff.h
>>> +++ b/include/linux/skbuff.h
>>> @@ -484,6 +484,8 @@ enum {
>>> SKB_GSO_TUNNEL_REMCSUM = 1 << 14,
>>>
>>> SKB_GSO_IP6IP6 = 1 << 15,
>>> +
>>> + SKB_GSO_IP4IP6 = 1 << 16,
>>> };
>>>
>>
>> Houston, we have a problem.
>>
>> gso_type is 16bit (unsigned short), or maybe I missed something ?
>>
>> struct skb_shared_info {
>> unsigned char nr_frags;
>> __u8 tx_flags;
>> unsigned short gso_size;
>> unsigned short gso_segs;
>> unsigned short gso_type; <<-->>
>
> No, I am pretty sure you have it right. We are out of bits.
>
> Also it seems like we are generating a number of duplicate entries.
> What is the difference between IP6IP6 and SIT over IPv6? I'm not
> really seeing the difference.
>
> I'm wondering if maybe we shouldn't look at the possibly using the
> IPIP and SIT bits to instead indicate that the frame is encapsulated
> in an outer IPv4 or outer IPv6 header since we already have TCPV4 and
> TCPV6 to indicate if the inner network type is a V4 or V6. Then there
> is no need for this patch set to introduce any new tunnel types to be
> segmented since all cases should be covered. As far as I can tell
> SKB_GSO_IPIP/SIT were never really being tested against anyway so we
> might want to go the IPIPV4 IPIPV6 route instead as that is probably
> closer to what most device limitations would be.
>
My worry is that the current public interface means IPIP is IPv4 over
IPv4, and SIT means IPv6 over IPv4. There are some drivers advertising
offload support for these so I don't think we safely redefine
SKB_GSO_IPIP/SIT.
For finding more bits in gso_type there are some SKB_GOS_* that are
not really types at all but more flags. I'm going try to turn
SKB_GSO_DODGY into a skbuff for the purposes here. We'll still have
the problem of running out bits next time a new type is added (maybe
SKB_GSO_SCTP?) but can probably make room for one or two more. Longer
term I think the the solution is too eliminate gso_type altogether as
we are once again running into the problem of trying to indicate a
combinatorial set of constraints and complex layering in a just few
flag bits.
Tom
> - Alex
^ permalink raw reply
* Re: [PATCH 2/3] net/mlx5e: make VXLAN support conditional
From: Saeed Mahameed @ 2016-05-05 16:44 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, Achiad Shochat, Tariq Toukan,
Gal Pressman
In-Reply-To: <1462365116-3856622-1-git-send-email-arnd@arndb.de>
On Wed, May 4, 2016 at 3:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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@arndb.de>
> 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.
> ---
Hi Arnd,
I didn't post a fix up since it is not needed anymore, see
b7aade15485a ('vxlan: break dependency with netdev drivers') in
net-next.
The new issue is introduced due to : "net/mlx5: Kconfig: Fix
MLX5_EN/VXLAN build issue" which was merged from net tree.
Dave shouldn't have merged it into net-next, I explicitly asked him
that in the cover letter. Maybe he missed it.
I just checked and It is sufficient to only take the revert patch:
[PATCH 1/3] Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
to net-next.
Can you please confirm that with only the revert patch, you don't see
the issue ?
^ permalink raw reply
* Re: mlx5 core/en oops in 4.6-rc6+
From: Saeed Mahameed @ 2016-05-05 16:42 UTC (permalink / raw)
To: Doug Ledford; +Cc: Linux Netdev List
In-Reply-To: <56df9c0a-39dd-6e07-9466-23195dc60860@redhat.com>
On Thu, May 5, 2016 at 7:00 PM, Doug Ledford <dledford@redhat.com> wrote:
> Just had this pop up during testing, happened very soon after bootup:
>
> [ 47.235925] BUG: unable to handle kernel NULL pointer dereference at
> 00000000000001e8
> [ 47.245057] IP: [<ffffffffc0328b9c>] mlx5e_sq_xmit+0x1c/0xd80 [mlx5_core]
> [ 47.252822] PGD 0
> [ 47.255218] Oops: 0000 [#1] SMP
> [ 47.259070] Modules linked in: sch_mqprio bridge 8021q garp mrp stp
> llc ib_iser libiscsi scsi_transport_iscsi ib_srp scsi_transport_srp
> ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa
> ib_mad x86_pkg_temp_thermal coretd
> [ 47.352984] CPU: 18 PID: 1358 Comm: NetworkManager Not tainted
> 4.6.0-rc6-00004-g7199787 #102
> [ 47.362460] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS
> 1.6.2 01/08/2016
> [ 47.370869] task: ffff88103369d000 ti: ffff88103751c000 task.ti:
> ffff88103751c000
> [ 47.379263] RIP: 0010:[<ffffffffc0328b9c>] [<ffffffffc0328b9c>]
> mlx5e_sq_xmit+0x1c/0xd80 [mlx5_core]
> [ 47.389627] RSP: 0018:ffff88103751f7d0 EFLAGS: 00010282
> [ 47.395574] RAX: ffff880fe6f51d00 RBX: 0000000000000000 RCX:
> 0000000000000081
> [ 47.403571] RDX: ffff880ff1dc3000 RSI: ffff880fe6f51d00 RDI:
> 0000000000000000
> [ 47.411561] RBP: ffff88103751f828 R08: 0000000000020c80 R09:
> ffffffff81871e04
> [ 47.419563] R10: ffffea003f9bd400 R11: ffff88100116de00 R12:
> 000000000000003e
> [ 47.427566] R13: ffff880fe6f51d00 R14: ffff8810240d0090 R15:
> ffff8810240d0068
> [ 47.435557] FS: 00007fd79b882dc0(0000) GS:ffff88103ee40000(0000)
> knlGS:0000000000000000
> [ 47.444625] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 47.451062] CR2: 00000000000001e8 CR3: 0000001cf86c5000 CR4:
> 00000000001406e0
> [ 47.459053] Stack:
> [ 47.461306] ffffffff81875480 ffff880fe6f50c00 ffff881d02f9b800
> ffff88103751f838
> [ 47.469647] ffffffff81a08415 ffff88103751f818 ffff880fe6f51d00
> 000000000000003e
> [ 47.477964] ffff881d02f9bd00 ffff8810240d0090 ffff8810240d0068
> ffff88103751f838
> [ 47.486279] Call Trace:
> [ 47.489019] [<ffffffff81875480>] ? consume_skb+0x80/0x150
> [ 47.495178] [<ffffffff81a08415>] ? packet_rcv+0x65/0x6d0
> [ 47.501244] [<ffffffffc03299ae>] mlx5e_xmit+0x2e/0x40 [mlx5_core]
> [ 47.508169] [<ffffffff818959d4>] dev_hard_start_xmit+0x384/0x650
> [ 47.515007] [<ffffffff818951bb>] ? validate_xmit_skb.isra.80+0x4b/0x4e0
> [ 47.522516] [<ffffffff818d036f>] sch_direct_xmit+0x19f/0x360
> [ 47.528963] [<ffffffff81896565>] __dev_queue_xmit+0x6e5/0xaa0
> [ 47.535502] [<ffffffff81875480>] ? consume_skb+0x80/0x150
> [ 47.542723] [<ffffffff81896958>] dev_queue_xmit+0x18/0x30
> [ 47.549856] [<ffffffffc08d1d54>]
> vlan_dev_hard_start_xmit+0x104/0x210 [8021q]
> [ 47.558933] [<ffffffff818959d4>] dev_hard_start_xmit+0x384/0x650
> [ 47.566738] [<ffffffff8189675a>] __dev_queue_xmit+0x8da/0xaa0
> [ 47.574246] [<ffffffff81896958>] dev_queue_xmit+0x18/0x30
> [ 47.581349] [<ffffffff818a2d07>] neigh_connected_output+0x107/0x170
> [ 47.589433] [<ffffffff819a3e9f>] ip6_finish_output2+0x23f/0x720
> [ 47.597128] [<ffffffff81430f32>] ? selinux_ipv6_postroute+0x22/0x30
> [ 47.605207] [<ffffffff819a666b>] ip6_finish_output+0x13b/0x1e0
> [ 47.612809] [<ffffffff819a6777>] ip6_output+0x67/0x1c0
> [ 47.619619] [<ffffffff819a6530>] ? ip6_fragment+0xd80/0xd80
> [ 47.626903] [<ffffffff819fb80d>] ip6_local_out+0x4d/0x60
> [ 47.633884] [<ffffffff819a703b>] ip6_send_skb+0x2b/0xb0
> [ 47.640773] [<ffffffff819a713d>] ip6_push_pending_frames+0x7d/0x90
> [ 47.648710] [<ffffffff819d533d>] rawv6_sendmsg+0xd2d/0x1210
> [ 47.655938] [<ffffffff8128f70a>] ? do_wp_page+0x3ba/0x910
> [ 47.662944] [<ffffffff8142a970>] ? sock_has_perm+0x80/0xb0
> [ 47.670020] [<ffffffff8194f2c7>] inet_sendmsg+0x97/0xf0
> [ 47.676778] [<ffffffff818673f8>] sock_sendmsg+0x58/0x90
> [ 47.683505] [<ffffffff81868148>] SYSC_sendto+0x138/0x1b0
> [ 47.690302] [<ffffffff8109d5a8>] ? __do_page_fault+0x338/0x9d0
> [ 47.697656] [<ffffffff8116b131>] ? ktime_get_with_offset+0x71/0x130
> [ 47.705481] [<ffffffff81163ee7>] ? posix_get_boottime+0x37/0x60
> [ 47.712904] [<ffffffff81868b36>] SyS_sendto+0x16/0x20
> [ 47.719346] [<ffffffff81a336b2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> [ 47.727230] Code: 05 a9 9f 03 00 01 66 31 47 48 5d c3 0f 1f 00 0f 1f
> 44 00 00 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 53 48 89 fb 48 83
> ec 30 <0f> b7 87 e8 01 00 00 0f b6 8f ea 01 00 00 45 8b 95 80 00 00 00
> [ 47.750336] RIP [<ffffffffc0328b9c>] mlx5e_sq_xmit+0x1c/0xd80
> [mlx5_core]
> [ 47.758755] RSP <ffff88103751f7d0>
> [ 47.763368] CR2: 00000000000001e8
> [ 47.767779] ---[ end trace 35565b04ca44e521 ]---
>
> It appears to be intermittent as this machine has booted this kernel
> multiple times without hitting this. Network setup includes both vlan
> and non-vlan interfaces. If you need more info from me, please include
> me on the Cc: as I don't follow netdev@
>
Hi Doug,
did you by change configure TC queues for the netdev ? i.e. dev->num_tc > 1
if not i would be happy to get more info in you network configuration.
^ permalink raw reply
* [PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE
From: Thadeu Lima de Souza Cascardo @ 2016-05-05 16:36 UTC (permalink / raw)
To: netdev
Use ARPHRD_VXLANGPE to identify VxLAN GPE interfaces. This is going to be used
to allow GPE interfaces to be added as openvswitch ports.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Simon Horman <simon.horman@netronome.com>
---
drivers/net/vxlan.c | 2 +-
include/uapi/linux/if_arp.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2668e52..9da962f 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2603,7 +2603,7 @@ static void vxlan_ether_setup(struct net_device *dev)
static void vxlan_raw_setup(struct net_device *dev)
{
dev->header_ops = NULL;
- dev->type = ARPHRD_NONE;
+ dev->type = ARPHRD_VXLANGPE;
dev->hard_header_len = 0;
dev->addr_len = 0;
dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
index 4d024d7..52a8175 100644
--- a/include/uapi/linux/if_arp.h
+++ b/include/uapi/linux/if_arp.h
@@ -95,6 +95,7 @@
#define ARPHRD_IP6GRE 823 /* GRE over IPv6 */
#define ARPHRD_NETLINK 824 /* Netlink header */
#define ARPHRD_6LOWPAN 825 /* IPv6 over LoWPAN */
+#define ARPHRD_VXLANGPE 826 /* VxLAN GPE */
#define ARPHRD_VOID 0xFFFF /* Void type, nothing is known */
#define ARPHRD_NONE 0xFFFE /* zero header length */
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net-next 01/14] gso: Remove arbitrary checks for unsupported GSO
From: Tom Herbert @ 2016-05-05 16:11 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0Uc32UBGMAiPRhbGiQXrnqsfG7_6tdKLp7AuOT8W7qm39A@mail.gmail.com>
On Thu, May 5, 2016 at 9:09 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Wed, May 4, 2016 at 7:59 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Wed, May 4, 2016 at 6:02 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> In several gso_segment functions there are checks of gso_type against
>>> a seemingly abitrary list of SKB_GSO_* flags. This seems like an
>>> attempt to identify unsupported GSO types, but since the stack is
>>> the one that set these GSO types in the first place this seems
>>> unnecessary to do. If a combination isn't valid in the first
>>> place that stack should not allow setting it.
>>
>> You would think that was the case. The problem is I have already seen
>> one issue with GUE allowing an unsupported combination of GRE_CSUM and
>> UDP tunnels.
>
> I thought about this some more and it isn't as if the checks would
> have caught this anyway as the GRE bits were being skipped over. I'd
> say we can probably just drop all these checks and save ourselves the
> space. So I retract my earlier comments against this specific patch
> and will Ack it when we get the issues with the other patches in the
> series resolved.
>
Wow, you sent this ten seconds before I hit send for a well crafted reply. :-)
Thanks,
Tom
> - Alex
^ permalink raw reply
* Re: [PATCH net-next 01/14] gso: Remove arbitrary checks for unsupported GSO
From: Alexander Duyck @ 2016-05-05 16:09 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0UeZWv7pnHNC8b5zjPe=SxZBz9EBUGkxnnjnqkmhDe34xg@mail.gmail.com>
On Wed, May 4, 2016 at 7:59 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Wed, May 4, 2016 at 6:02 PM, Tom Herbert <tom@herbertland.com> wrote:
>> In several gso_segment functions there are checks of gso_type against
>> a seemingly abitrary list of SKB_GSO_* flags. This seems like an
>> attempt to identify unsupported GSO types, but since the stack is
>> the one that set these GSO types in the first place this seems
>> unnecessary to do. If a combination isn't valid in the first
>> place that stack should not allow setting it.
>
> You would think that was the case. The problem is I have already seen
> one issue with GUE allowing an unsupported combination of GRE_CSUM and
> UDP tunnels.
I thought about this some more and it isn't as if the checks would
have caught this anyway as the GRE bits were being skipped over. I'd
say we can probably just drop all these checks and save ourselves the
space. So I retract my earlier comments against this specific patch
and will Ack it when we get the issues with the other patches in the
series resolved.
- Alex
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support
From: Dan Williams @ 2016-05-05 16:07 UTC (permalink / raw)
To: Wei-Ning Huang, Linux-Wireless
Cc: LKML, Johannes Berg, Sameer Nanda, Todd Broch, davem, netdev
In-Reply-To: <1462430663-9448-1-git-send-email-wnhuang@chromium.org>
On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
> Recent new hardware has the ability to switch between tablet mode and
> clamshell mode. To optimize WiFi performance, we want to be able to
> use
> different power table between modes. This patch adds a new netlink
> message type and cfg80211_ops function to allow userspace to trigger
> a
> power mode switch for a given wireless interface.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
> ---
> include/net/cfg80211.h | 11 +++++++++++
> include/uapi/linux/nl80211.h | 21 +++++++++++++++++++++
> net/wireless/nl80211.c | 16 ++++++++++++++++
> net/wireless/rdev-ops.h | 22 ++++++++++++++++++++++
> net/wireless/trace.h | 20 ++++++++++++++++++++
> 5 files changed, 90 insertions(+)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 9e1b24c..aa77fa0 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
> * @get_tx_power: store the current TX power into the dbm variable;
> * return 0 if successful
> *
> + * @set_tx_power_mode: set the transmit power mode. Some device have
> the ability
> + * to transform between different mode such as clamshell and
> tablet mode.
> + * set_tx_power_mode allows setting of different TX power
> mode at runtime.
> + * @get_tx_power_mode: store the current TX power mode into the mode
> variable;
> + * return 0 if successful
> + *
> * @set_wds_peer: set the WDS peer for a WDS interface
> *
> * @rfkill_poll: polls the hw rfkill line, use cfg80211 reporting
> @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
> int (*get_tx_power)(struct wiphy *wiphy, struct
> wireless_dev *wdev,
> int *dbm);
>
> + int (*set_tx_power_mode)(struct wiphy *wiphy,
> + enum nl80211_tx_power_mode
> mode);
> + int (*get_tx_power_mode)(struct wiphy *wiphy,
> + enum nl80211_tx_power_mode
> *mode);
> +
> int (*set_wds_peer)(struct wiphy *wiphy, struct
> net_device *dev,
> const u8 *addr);
>
> diff --git a/include/uapi/linux/nl80211.h
> b/include/uapi/linux/nl80211.h
> index 5a30a75..9b1888a 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1796,6 +1796,9 @@ enum nl80211_commands {
> * connecting to a PCP, and in %NL80211_CMD_START_AP to start
> * a PCP instead of AP. Relevant for DMG networks only.
> *
> + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
> + * &enum nl80211_tx_power_mode for possible values.
> + *
> * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
>
> NL80211_ATTR_PBSS,
>
> + NL80211_ATTR_WIPHY_TX_POWER_MODE,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> @@ -3703,6 +3708,22 @@ enum nl80211_tx_power_setting {
> };
>
> /**
> + * enum nl80211_tx_power_mode - TX power mode setting
> + * @NL80211_TX_POWER_LOW: general low TX power mode
> + * @NL80211_TX_POWER_MEDIUM: general medium TX power mode
> + * @NL80211_TX_POWER_HIGH: general high TX power mode
> + * @NL80211_TX_POWER_CLAMSHELL: clamshell mode TX power mode
> + * @NL80211_TX_POWER_TABLET: tablet mode TX power mode
> + */
> +enum nl80211_tx_power_mode {
> + NL80211_TX_POWER_LOW,
> + NL80211_TX_POWER_MEDIUM,
> + NL80211_TX_POWER_HIGH,
> + NL80211_TX_POWER_CLAMSHELL,
> + NL80211_TX_POWER_TABLET,
"clamshell" and "tablet" probably mean many different things to many
different people with respect to whether or not they should do anything
with power saving or wifi. I feel like a more generic interface is
needed here.
Could this be already done by:
@NL80211_ATTR_WIPHY_TX_POWER_SETTING = NL80211_TX_POWER_LIMITED
@NL80211_ATTR_WIPHY_TX_POWER_LEVEL = <limit for clamshell/tablet mode>
and then the device would be able to change its TX power as it saw fit
up to that limit set by your application which figures out whether it's
in clamshell or tablet mode?
Dan
> +};
> +
> +/**
> * enum nl80211_packet_pattern_attr - packet pattern attribute
> * @__NL80211_PKTPAT_INVALID: invalid number for nested attribute
> * @NL80211_PKTPAT_PATTERN: the pattern, values where the mask has
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 056a730..61b474d 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -402,6 +402,7 @@ static const struct nla_policy
> nl80211_policy[NUM_NL80211_ATTR] = {
> [NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
> [NL80211_ATTR_REG_INDOOR] = { .type = NLA_FLAG },
> [NL80211_ATTR_PBSS] = { .type = NLA_FLAG },
> + [NL80211_ATTR_WIPHY_TX_POWER_MODE] = { .type = NLA_U32 },
> };
>
> /* policy for the key attributes */
> @@ -2218,6 +2219,21 @@ static int nl80211_set_wiphy(struct sk_buff
> *skb, struct genl_info *info)
> return result;
> }
>
> + if (info->attrs[NL80211_ATTR_WIPHY_TX_POWER_MODE]) {
> + enum nl80211_tx_power_mode mode;
> + int idx = 0;
> +
> + if (!rdev->ops->set_tx_power_mode)
> + return -EOPNOTSUPP;
> +
> + idx = NL80211_ATTR_WIPHY_TX_POWER_MODE;
> + mode = nla_get_u32(info->attrs[idx]);
> +
> + result = rdev_set_tx_power_mode(rdev, mode);
> + if (result)
> + return result;
> + }
> +
> if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
> info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
> u32 tx_ant, rx_ant;
> diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
> index 8ae0c04..c3a1035 100644
> --- a/net/wireless/rdev-ops.h
> +++ b/net/wireless/rdev-ops.h
> @@ -552,6 +552,28 @@ static inline int rdev_get_tx_power(struct
> cfg80211_registered_device *rdev,
> return ret;
> }
>
> +static inline int
> +rdev_set_tx_power_mode(struct cfg80211_registered_device *rdev,
> + enum nl80211_tx_power_mode mode)
> +{
> + int ret;
> + trace_rdev_set_tx_power_mode(&rdev->wiphy, mode);
> + ret = rdev->ops->set_tx_power_mode(&rdev->wiphy, mode);
> + trace_rdev_return_int(&rdev->wiphy, ret);
> + return ret;
> +}
> +
> +static inline int
> +rdev_get_tx_power_mode(struct cfg80211_registered_device *rdev,
> + enum nl80211_tx_power_mode *mode)
> +{
> + int ret;
> + trace_rdev_get_tx_power_mode(&rdev->wiphy);
> + ret = rdev->ops->get_tx_power_mode(&rdev->wiphy, mode);
> + trace_rdev_return_int_int(&rdev->wiphy, ret, *mode);
> + return ret;
> +}
> +
> static inline int rdev_set_wds_peer(struct
> cfg80211_registered_device *rdev,
> struct net_device *dev, const u8
> *addr)
> {
> diff --git a/net/wireless/trace.h b/net/wireless/trace.h
> index 09b242b..132c8c2 100644
> --- a/net/wireless/trace.h
> +++ b/net/wireless/trace.h
> @@ -1420,6 +1420,26 @@ TRACE_EVENT(rdev_set_tx_power,
> WIPHY_PR_ARG, WDEV_PR_ARG,__entry->type, __entry-
> >mbm)
> );
>
> +DEFINE_EVENT(wiphy_only_evt, rdev_get_tx_power_mode,
> + TP_PROTO(struct wiphy *wiphy),
> + TP_ARGS(wiphy)
> +);
> +
> +TRACE_EVENT(rdev_set_tx_power_mode,
> + TP_PROTO(struct wiphy *wiphy, enum nl80211_tx_power_mode
> mode),
> + TP_ARGS(wiphy, mode),
> + TP_STRUCT__entry(
> + WIPHY_ENTRY
> + __field(enum nl80211_tx_power_mode, mode)
> + ),
> + TP_fast_assign(
> + WIPHY_ASSIGN;
> + __entry->mode = mode;
> + ),
> + TP_printk(WIPHY_PR_FMT ", mode: %d",
> + WIPHY_PR_ARG, __entry->mode)
> +);
> +
> TRACE_EVENT(rdev_return_int_int,
> TP_PROTO(struct wiphy *wiphy, int func_ret, int func_fill),
> TP_ARGS(wiphy, func_ret, func_fill),
^ permalink raw reply
* mlx5 core/en oops in 4.6-rc6+
From: Doug Ledford @ 2016-05-05 16:00 UTC (permalink / raw)
To: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 4931 bytes --]
Just had this pop up during testing, happened very soon after bootup:
[ 47.235925] BUG: unable to handle kernel NULL pointer dereference at
00000000000001e8
[ 47.245057] IP: [<ffffffffc0328b9c>] mlx5e_sq_xmit+0x1c/0xd80 [mlx5_core]
[ 47.252822] PGD 0
[ 47.255218] Oops: 0000 [#1] SMP
[ 47.259070] Modules linked in: sch_mqprio bridge 8021q garp mrp stp
llc ib_iser libiscsi scsi_transport_iscsi ib_srp scsi_transport_srp
ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa
ib_mad x86_pkg_temp_thermal coretd
[ 47.352984] CPU: 18 PID: 1358 Comm: NetworkManager Not tainted
4.6.0-rc6-00004-g7199787 #102
[ 47.362460] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS
1.6.2 01/08/2016
[ 47.370869] task: ffff88103369d000 ti: ffff88103751c000 task.ti:
ffff88103751c000
[ 47.379263] RIP: 0010:[<ffffffffc0328b9c>] [<ffffffffc0328b9c>]
mlx5e_sq_xmit+0x1c/0xd80 [mlx5_core]
[ 47.389627] RSP: 0018:ffff88103751f7d0 EFLAGS: 00010282
[ 47.395574] RAX: ffff880fe6f51d00 RBX: 0000000000000000 RCX:
0000000000000081
[ 47.403571] RDX: ffff880ff1dc3000 RSI: ffff880fe6f51d00 RDI:
0000000000000000
[ 47.411561] RBP: ffff88103751f828 R08: 0000000000020c80 R09:
ffffffff81871e04
[ 47.419563] R10: ffffea003f9bd400 R11: ffff88100116de00 R12:
000000000000003e
[ 47.427566] R13: ffff880fe6f51d00 R14: ffff8810240d0090 R15:
ffff8810240d0068
[ 47.435557] FS: 00007fd79b882dc0(0000) GS:ffff88103ee40000(0000)
knlGS:0000000000000000
[ 47.444625] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 47.451062] CR2: 00000000000001e8 CR3: 0000001cf86c5000 CR4:
00000000001406e0
[ 47.459053] Stack:
[ 47.461306] ffffffff81875480 ffff880fe6f50c00 ffff881d02f9b800
ffff88103751f838
[ 47.469647] ffffffff81a08415 ffff88103751f818 ffff880fe6f51d00
000000000000003e
[ 47.477964] ffff881d02f9bd00 ffff8810240d0090 ffff8810240d0068
ffff88103751f838
[ 47.486279] Call Trace:
[ 47.489019] [<ffffffff81875480>] ? consume_skb+0x80/0x150
[ 47.495178] [<ffffffff81a08415>] ? packet_rcv+0x65/0x6d0
[ 47.501244] [<ffffffffc03299ae>] mlx5e_xmit+0x2e/0x40 [mlx5_core]
[ 47.508169] [<ffffffff818959d4>] dev_hard_start_xmit+0x384/0x650
[ 47.515007] [<ffffffff818951bb>] ? validate_xmit_skb.isra.80+0x4b/0x4e0
[ 47.522516] [<ffffffff818d036f>] sch_direct_xmit+0x19f/0x360
[ 47.528963] [<ffffffff81896565>] __dev_queue_xmit+0x6e5/0xaa0
[ 47.535502] [<ffffffff81875480>] ? consume_skb+0x80/0x150
[ 47.542723] [<ffffffff81896958>] dev_queue_xmit+0x18/0x30
[ 47.549856] [<ffffffffc08d1d54>]
vlan_dev_hard_start_xmit+0x104/0x210 [8021q]
[ 47.558933] [<ffffffff818959d4>] dev_hard_start_xmit+0x384/0x650
[ 47.566738] [<ffffffff8189675a>] __dev_queue_xmit+0x8da/0xaa0
[ 47.574246] [<ffffffff81896958>] dev_queue_xmit+0x18/0x30
[ 47.581349] [<ffffffff818a2d07>] neigh_connected_output+0x107/0x170
[ 47.589433] [<ffffffff819a3e9f>] ip6_finish_output2+0x23f/0x720
[ 47.597128] [<ffffffff81430f32>] ? selinux_ipv6_postroute+0x22/0x30
[ 47.605207] [<ffffffff819a666b>] ip6_finish_output+0x13b/0x1e0
[ 47.612809] [<ffffffff819a6777>] ip6_output+0x67/0x1c0
[ 47.619619] [<ffffffff819a6530>] ? ip6_fragment+0xd80/0xd80
[ 47.626903] [<ffffffff819fb80d>] ip6_local_out+0x4d/0x60
[ 47.633884] [<ffffffff819a703b>] ip6_send_skb+0x2b/0xb0
[ 47.640773] [<ffffffff819a713d>] ip6_push_pending_frames+0x7d/0x90
[ 47.648710] [<ffffffff819d533d>] rawv6_sendmsg+0xd2d/0x1210
[ 47.655938] [<ffffffff8128f70a>] ? do_wp_page+0x3ba/0x910
[ 47.662944] [<ffffffff8142a970>] ? sock_has_perm+0x80/0xb0
[ 47.670020] [<ffffffff8194f2c7>] inet_sendmsg+0x97/0xf0
[ 47.676778] [<ffffffff818673f8>] sock_sendmsg+0x58/0x90
[ 47.683505] [<ffffffff81868148>] SYSC_sendto+0x138/0x1b0
[ 47.690302] [<ffffffff8109d5a8>] ? __do_page_fault+0x338/0x9d0
[ 47.697656] [<ffffffff8116b131>] ? ktime_get_with_offset+0x71/0x130
[ 47.705481] [<ffffffff81163ee7>] ? posix_get_boottime+0x37/0x60
[ 47.712904] [<ffffffff81868b36>] SyS_sendto+0x16/0x20
[ 47.719346] [<ffffffff81a336b2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
[ 47.727230] Code: 05 a9 9f 03 00 01 66 31 47 48 5d c3 0f 1f 00 0f 1f
44 00 00 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 53 48 89 fb 48 83
ec 30 <0f> b7 87 e8 01 00 00 0f b6 8f ea 01 00 00 45 8b 95 80 00 00 00
[ 47.750336] RIP [<ffffffffc0328b9c>] mlx5e_sq_xmit+0x1c/0xd80
[mlx5_core]
[ 47.758755] RSP <ffff88103751f7d0>
[ 47.763368] CR2: 00000000000001e8
[ 47.767779] ---[ end trace 35565b04ca44e521 ]---
It appears to be intermittent as this machine has booted this kernel
multiple times without hitting this. Network setup includes both vlan
and non-vlan interfaces. If you need more info from me, please include
me on the Cc: as I don't follow netdev@
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 03/14] udp: Don't set skb->encapsulation with RCO
From: Alexander Duyck @ 2016-05-05 15:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CALx6S37tNu-F3EU1ES37FCzm6-0TCfuFNig1==hnCa08A3FrQw@mail.gmail.com>
On Thu, May 5, 2016 at 8:38 AM, Tom Herbert <tom@herbertland.com> wrote:
> On Wed, May 4, 2016 at 7:42 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Wed, May 4, 2016 at 6:02 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> When RCO is in effect we want to ensure that the outer checksum is
>>> properly offloaded. Don't set skb->encapsulation in this case to
>>> ensure that checksum offload is later considered for hw_features
>>> instead of hw_enc_features.
>>>
>>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>>> ---
>>> net/ipv4/udp_offload.c | 10 ++++++----
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>>> index b556ef6..4eedec6 100644
>>> --- a/net/ipv4/udp_offload.c
>>> +++ b/net/ipv4/udp_offload.c
>>> @@ -94,11 +94,13 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,
>>> do {
>>> unsigned int len;
>>>
>>> - if (remcsum)
>>> + if (remcsum) {
>>> skb->ip_summed = CHECKSUM_NONE;
>>> -
>>> - /* Set up inner headers if we are offloading inner checksum */
>>> - if (skb->ip_summed == CHECKSUM_PARTIAL) {
>>> + skb->encapsulation = 0;
>>> + } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
>>> + /* Set up inner headers if we are offloading inner
>>> + * checksum
>>> + */
>>> skb_reset_inner_headers(skb);
>>> skb->encapsulation = 1;
>>> }
>>
>>
>> Why are you wasting cycles clearing a value that should have already
>> been cleared?
>>
>> We set skb->encapsulation to 0 for the incoming skb before we segment
>> it. As such all of the segments we get should also not have it set.
>> It seems like you are just wasting cycles writing it again even though
>> it isn't written.
>>
> I believe this is needed because skb->encapsulation could have been
> set at a lower inner GRO, like if we were encapsulating GRE in UDP...
That cannot happen. The GRE header processing is completely skipped
as we use the inner_mac_header to determine the next header to jump
to. The L3 types use encap_level and we reset that as well so there
should be no risk of skb->encapsulation being set for a remote
checksum offloaded frame.
- Alex
^ permalink raw reply
* Re: [PATCH net-next 03/14] udp: Don't set skb->encapsulation with RCO
From: Tom Herbert @ 2016-05-05 15:38 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0UeUTpuENPxOr7APFZ1YrVkCha=10qk=hh67eNb1u3Pexg@mail.gmail.com>
On Wed, May 4, 2016 at 7:42 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Wed, May 4, 2016 at 6:02 PM, Tom Herbert <tom@herbertland.com> wrote:
>> When RCO is in effect we want to ensure that the outer checksum is
>> properly offloaded. Don't set skb->encapsulation in this case to
>> ensure that checksum offload is later considered for hw_features
>> instead of hw_enc_features.
>>
>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>> ---
>> net/ipv4/udp_offload.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>> index b556ef6..4eedec6 100644
>> --- a/net/ipv4/udp_offload.c
>> +++ b/net/ipv4/udp_offload.c
>> @@ -94,11 +94,13 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,
>> do {
>> unsigned int len;
>>
>> - if (remcsum)
>> + if (remcsum) {
>> skb->ip_summed = CHECKSUM_NONE;
>> -
>> - /* Set up inner headers if we are offloading inner checksum */
>> - if (skb->ip_summed == CHECKSUM_PARTIAL) {
>> + skb->encapsulation = 0;
>> + } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
>> + /* Set up inner headers if we are offloading inner
>> + * checksum
>> + */
>> skb_reset_inner_headers(skb);
>> skb->encapsulation = 1;
>> }
>
>
> Why are you wasting cycles clearing a value that should have already
> been cleared?
>
> We set skb->encapsulation to 0 for the incoming skb before we segment
> it. As such all of the segments we get should also not have it set.
> It seems like you are just wasting cycles writing it again even though
> it isn't written.
>
I believe this is needed because skb->encapsulation could have been
set at a lower inner GRO, like if we were encapsulating GRE in UDP...
Tom
> - Alex
^ permalink raw reply
* [PATCH v2] rtlwifi: Remove double check for cnt_after_linked
From: Wang YanQing @ 2016-05-05 15:08 UTC (permalink / raw)
To: Larry.Finger; +Cc: chaoming_li, kvalo, linux-wireless, netdev, linux-kernel
rtl_lps_enter does two successive check for cnt_after_linked
to make sure some time has elapsed after linked. The second
check isn't necessary, because if cnt_after_linked is bigger
than 5, it is bigger than 2 of course!
This patch remove the second check code.
Signed-off-by: Wang YanQing <udknight@gmail.com>
---
Changes
v1-v2:
1: rewrite subject and commit message.
2: fix issues report by checkpatch.pl.
drivers/net/wireless/realtek/rtlwifi/ps.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c b/drivers/net/wireless/realtek/rtlwifi/ps.c
index b69321d..93579ca 100644
--- a/drivers/net/wireless/realtek/rtlwifi/ps.c
+++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
@@ -443,14 +443,10 @@ void rtl_lps_enter(struct ieee80211_hw *hw)
spin_lock_irqsave(&rtlpriv->locks.lps_lock, flag);
- /* Idle for a while if we connect to AP a while ago. */
- if (mac->cnt_after_linked >= 2) {
- if (ppsc->dot11_psmode == EACTIVE) {
- RT_TRACE(rtlpriv, COMP_POWER, DBG_LOUD,
- "Enter 802.11 power save mode...\n");
-
- rtl_lps_set_psmode(hw, EAUTOPS);
- }
+ if (ppsc->dot11_psmode == EACTIVE) {
+ RT_TRACE(rtlpriv, COMP_POWER, DBG_LOUD,
+ "Enter 802.11 power save mode...\n");
+ rtl_lps_set_psmode(hw, EAUTOPS);
}
spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
--
1.8.5.6.2.g3d8a54e.dirty
^ permalink raw reply related
* Re: [PATCH net-next 06/13] net: original ingress device index in PKTINFO
From: David Ahern @ 2016-05-05 15:00 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
In-Reply-To: <alpine.LFD.2.11.1605051040320.2118@ja.home.ssi.bg>
On 5/5/16 2:41 AM, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 4 May 2016, David Ahern wrote:
>
>> Applications such as OSPF and BFD need the original ingress device not
>> the VRF device; the latter can be derived from the former. To that end
>> add the skb_iif to inet_skb_parm and set it in ipv4 code after clearing
>> the skb control buffer similar to IPv6. From there the pktinfo can just
>> pull it from cb with the PKTINFO_SKB_CB cast.
>>
>> The previous patch moving the skb->dev change to L3 means nothing else
>> is needed for IPv6; it just works.
>>
>> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> include/net/ip.h | 1 +
>> net/ipv4/ip_input.c | 1 +
>> net/ipv4/ip_sockglue.c | 9 +++++++--
>> 3 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/net/ip.h b/include/net/ip.h
>> index 247ac82e9cf2..37165fba3741 100644
>> --- a/include/net/ip.h
>> +++ b/include/net/ip.h
>> @@ -36,6 +36,7 @@
>> struct sock;
>>
>> struct inet_skb_parm {
>> + int iif;
>> struct ip_options opt; /* Compiled IP options */
>> unsigned char flags;
>>
>> diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
>> index 37375eedeef9..4b351af3e67b 100644
>> --- a/net/ipv4/ip_input.c
>> +++ b/net/ipv4/ip_input.c
>> @@ -478,6 +478,7 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
>>
>> /* Remove any debris in the socket control block */
>> memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
>> + IPCB(skb)->iif = skb->skb_iif;
>
> For loopback traffic (including looped back multicast)
> this is now a zero :( Can inet_iif be moved to ip_rcv_finish
> instead? Still, we spend cycles in fast path in case nobody
> listens for such info.
Why is that? skb_iif is set to skb->dev->index in
__netif_receive_skb_core and ip_rcv is called it. Is there another path
to it?
>
>> /* Must drop socket now because of tproxy. */
>> skb_orphan(skb);
>> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
>> index bdb222c0c6a2..dbcd027c38e7 100644
>> --- a/net/ipv4/ip_sockglue.c
>> +++ b/net/ipv4/ip_sockglue.c
>> @@ -476,9 +476,9 @@ static bool ipv4_datagram_support_cmsg(const struct sock *sk,
>> (!skb->dev))
>> return false;
>>
>> + /* see comment in ipv4_pktinfo_prepare about CB re-use */
>> info = PKTINFO_SKB_CB(skb);
>> info->ipi_spec_dst.s_addr = ip_hdr(skb)->saddr;
>> - info->ipi_ifindex = skb->dev->ifindex;
>
> This code is only for SOF_TIMESTAMPING_OPT_CMSG.
> I'm not sure skb passes ip_rcv in all cases. So, we can not
> easily remove it.
ok.
^ permalink raw reply
* Re: [net-next 08/15] i40e: Allow user to change input set mask for flow director
From: Patil, Kiran @ 2016-05-05 15:00 UTC (permalink / raw)
To: John Fastabend, David Miller, jeffrey.t.kirsher
Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <572ABC76.2080600@gmail.com>
On 5/4/2016 8:22 PM, John Fastabend wrote:
> On 16-05-04 07:47 PM, Patil, Kiran wrote:
>> On 4/26/2016 8:48 PM, David Miller wrote:
>>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> Date: Tue, 26 Apr 2016 13:55:41 -0700
>>>
>>>> From: Kiran Patil <kiran.patil@intel.com>
>>>>
>>>> This patch implements feature, which allows user to change
>>>> input set mask for flow director using side-band channel.
>>>> This patch adds definition of FLOW_TYPE_MASK into the header file.
>>>> With this patch, user can now specify less than 4 tuple(src ip, dsp ip,
>>>> src port, dst port) for flow type TCP4/UDP4.
>>>>
>>>> Change-Id: I90052508f8c172c0da5a4b78b949704b4a59ea78
>>>> Signed-off-by: Kiran Patil <kiran.patil@intel.com>
>>>> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
>>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>>
>>> If you want to do this, you have to define the semantics generically
>>> in include/uapi/linux/ethtool.h so that other drivers can implement
>>> this too.
>>>
>>> Please don't ever implement private, driver specific, interpretations
>>> of the generic ethtool facilitites.
>>>
>>> The semantics and interpretations of the values must absolutely be
>>> consistent across all drivers in the tree.
>>>
>>> Otherwise the user experience is terrible.
>>>
>>> Thanks.
>>>
>> This is not new feature implemented in i40e driver. This is the original
>> feature of ethtool which allows user to specify subset of tuple for
>> setting up flow director.
>>
>> i40e driver using it same way as ixgbe.
>>
>> Please let us know if I misinterpreted your response.
>>
>> Would you recommend that we re-submit patch with better patch
>> description (indicating that it is not new feature but just enabling
>> feature).
>>
>> Thanks,
>> -- Kiran P.
>
> At least define FLOW_TYPE_MASK in ethtool.h then its not
> sort of hobbled together in the driver and others can use it
> instead of the normal ~FLOW_EXT which I see other drivers used.
> Another benefit if its near the definition of the flow types
> you have a chance of someone seeing it if they add a flag
> past 0xff.
>
> And maybe do it as a separate patch. So you aren't adding normal
> driver ethtool implementation and a new #define for all drivers
> in the same patch.
>
> .John
>
Now I see what the problem is (FLOW_TYPE_MASK). Unfortunately it was
never meant to be part of this patch since it was introduced by other
patch (Cloud filter support) and was suggested to move into this header
file. As suggested, we can create another patch just for this
FLOW_TYPE_MASK in ethtool.h and re-work original patch to not have
define for FLOW_TYPE_MASK.
May be we can go back and think, it this define absolutely needed or not.
Thanks,
-- Kiran P.
^ permalink raw reply
* Re: [PATCH net-next 03/13] net: l3mdev: Allow send on enslaved interface
From: David Ahern @ 2016-05-05 14:50 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
In-Reply-To: <alpine.LFD.2.11.1605051026380.2118@ja.home.ssi.bg>
On 5/5/16 1:40 AM, Julian Anastasov wrote:
>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>> index 8c8c655bb2c4..a1f2830d8110 100644
>> --- a/net/ipv4/route.c
>> +++ b/net/ipv4/route.c
>> @@ -2146,6 +2146,7 @@ struct rtable *__ip_route_output_key_hash(struct net *net, struct flowi4 *fl4,
>> unsigned int flags = 0;
>> struct fib_result res;
>> struct rtable *rth;
>> + int master_idx;
>> int orig_oif;
>> int err = -ENETUNREACH;
>>
>> @@ -2155,6 +2156,9 @@ struct rtable *__ip_route_output_key_hash(struct net *net, struct flowi4 *fl4,
>>
>> orig_oif = fl4->flowi4_oif;
>>
>> + master_idx = l3mdev_master_ifindex_by_index(net, fl4->flowi4_oif);
>> + if (master_idx)
>> + fl4->flowi4_oif = master_idx;
>
> Changing the flowi4_oif at this point can have
> bad effects. I remember for recent commit for __mkroute_output
> where the route caching is disabled if traffic is redirected
> to loopback. I think, such change can affect the route
> caching, for example, now we use nexthop on master_idx to
> cache routes for orig_oif. Such problems with the caching
> in the past always caused lookups to return wrong cached result
> for other users. But this is only my fears, I don't know
> the actual result of this change. May be you are trying to
> change flowi4_oif at one place instead of every caller.
Yes. VRFs require the oif to be the master index so that the FIB rules
direct the lookup to the proper table. Without it we get the wrong result.
^ permalink raw reply
* Your mailbox is almost full
From: Paul Machado @ 2016-05-05 13:28 UTC (permalink / raw)
To: info@ServiceDesk.org
Self
This e-mail address is now blocked from sending e-mail to other emails To keep your email active Click Here<https://www.powr.io/plugins/form-builder/view?id=4448384&mode=page>
Service Desk
^ permalink raw reply
* [patch] qede: uninitialized variable in qede_start_xmit()
From: Dan Carpenter @ 2016-05-05 13:21 UTC (permalink / raw)
To: Yuval Mintz
Cc: Ariel Elior, everest-linux-l2, netdev, linux-kernel,
kernel-janitors
"data_split" was never set to false. It's just uninitialized.
Fixes: 2950219d87b0 ('qede: Add basic network device support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 60a61c3..d98f35e 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -429,7 +429,7 @@ netdev_tx_t qede_start_xmit(struct sk_buff *skb,
u8 xmit_type;
u16 idx;
u16 hlen;
- bool data_split;
+ bool data_split = false;
/* Get tx-queue context and netdev index */
txq_index = skb_get_queue_mapping(skb);
^ permalink raw reply related
* [patch] netxen: netxen_rom_fast_read() doesn't return -1
From: Dan Carpenter @ 2016-05-05 13:20 UTC (permalink / raw)
To: Manish Chopra
Cc: Sony Chacko, Rajesh Borundia, netdev, linux-kernel,
kernel-janitors
The error handling is broken here. netxen_rom_fast_read() returns zero
on success and -EIO on error. It never returns -1.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index fd362b6..9c6eed9 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -852,7 +852,8 @@ netxen_check_options(struct netxen_adapter *adapter)
ptr32 = (__le32 *)&serial_num;
offset = NX_FW_SERIAL_NUM_OFFSET;
for (i = 0; i < 8; i++) {
- if (netxen_rom_fast_read(adapter, offset, &val) == -1) {
+ err = netxen_rom_fast_read(adapter, offset, &val);
+ if (err) {
dev_err(&pdev->dev, "error reading board info\n");
adapter->driver_mismatch = 1;
return;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox