* 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
* [patch 2/2] netxen: reversed condition in netxen_nic_set_link_parameters()
From: Dan Carpenter @ 2016-05-05 13:19 UTC (permalink / raw)
To: Manish Chopra
Cc: Sony Chacko, Rajesh Borundia, netdev, linux-kernel,
kernel-janitors
My static checker complains that we are using "autoneg" without
initializing it. The problem is the ->phy_read() condition is reversed
so we only set this on error instead of success.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index a320541..2b10f1b 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -1944,7 +1944,7 @@ void netxen_nic_set_link_parameters(struct netxen_adapter *adapter)
if (adapter->phy_read &&
adapter->phy_read(adapter,
NETXEN_NIU_GB_MII_MGMT_ADDR_AUTONEG,
- &autoneg) != 0)
+ &autoneg) == 0)
adapter->link_autoneg = autoneg;
} else
goto link_down;
^ permalink raw reply related
* [patch 1/2] netxen: fix error handling in netxen_get_flash_block()
From: Dan Carpenter @ 2016-05-05 13:18 UTC (permalink / raw)
To: Manish Chopra
Cc: Sony Chacko, Rajesh Borundia, netdev, linux-kernel,
kernel-janitors
My static checker complained that "v" can be used unintialized if
netxen_rom_fast_read() returns -EIO. That function never actually
returns -1.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index db80eb1..a320541 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -1015,20 +1015,24 @@ static int netxen_get_flash_block(struct netxen_adapter *adapter, int base,
{
int i, v, addr;
__le32 *ptr32;
+ int ret;
addr = base;
ptr32 = buf;
for (i = 0; i < size / sizeof(u32); i++) {
- if (netxen_rom_fast_read(adapter, addr, &v) == -1)
- return -1;
+ ret = netxen_rom_fast_read(adapter, addr, &v);
+ if (ret)
+ return ret;
+
*ptr32 = cpu_to_le32(v);
ptr32++;
addr += sizeof(u32);
}
if ((char *)buf + size > (char *)ptr32) {
__le32 local;
- if (netxen_rom_fast_read(adapter, addr, &v) == -1)
- return -1;
+ ret = netxen_rom_fast_read(adapter, addr, &v);
+ if (ret)
+ return ret;
local = cpu_to_le32(v);
memcpy(ptr32, &local, (char *)buf + size - (char *)ptr32);
}
^ permalink raw reply related
* [patch] i40e: fix an uninitialized variable bug
From: Dan Carpenter @ 2016-05-05 13:18 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg
Cc: Shannon Nelson, Carolyn Wyborny, Don Skidmore, Bruce Allan,
John Ronciak, Mitch Williams, intel-wired-lan, netdev,
linux-kernel, kernel-janitors
We removed this initialization but it is required. Let's put it back.
Fixes: 895106a577c4 ('i40e: trivial fixes')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/intel/i40e/i40e_hmc.c b/drivers/net/ethernet/intel/i40e/i40e_hmc.c
index 5ebe12d..a7c7b1d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_hmc.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_hmc.c
@@ -49,7 +49,7 @@ i40e_status i40e_add_sd_table_entry(struct i40e_hw *hw,
struct i40e_hmc_sd_entry *sd_entry;
bool dma_mem_alloc_done = false;
struct i40e_dma_mem mem;
- i40e_status ret_code;
+ i40e_status ret_code = I40E_SUCCESS;
u64 alloc_len;
if (NULL == hmc_info->sd_table.sd_entry) {
^ permalink raw reply related
* [PULL] virtio/qemu: fixes for 4.6
From: Michael S. Tsirkin @ 2016-05-05 13:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: kvm, mst, netdev, linux-kernel, virtualization, dan.carpenter
The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:
Linux 4.6-rc4 (2016-04-17 19:13:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to e00f7bd221292b318d4d09c3f0c2c8af9b1e5edf:
virtio: Silence uninitialized variable warning (2016-05-01 15:50:08 +0300)
----------------------------------------------------------------
virtio/qemu: fixes for 4.6
A couple of fixes for virtio and for the new QEMU fw cfg driver.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Dan Carpenter (2):
firmware: qemu_fw_cfg.c: potential unintialized variable
virtio: Silence uninitialized variable warning
drivers/firmware/qemu_fw_cfg.c | 2 +-
drivers/virtio/virtio_ring.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: A couple of questions about the SKB fragments
From: Sowmini Varadhan @ 2016-05-05 12:58 UTC (permalink / raw)
To: Edward Cree; +Cc: matvejchikov, netdev, Aleksey.Baulin
In-Reply-To: <572B2AEE.1020802@solarflare.com>
On (05/05/16 12:13), Edward Cree wrote:
> On 05/05/16 08:40, Ilya Matveychikov wrote:
> >
> > While working with fragmented SKBs we've got stuck with the following:
> > - is it possible for an SKB fragment in skb_shinfo(skb)->frag_list to
> > be fragmented too (i.e. to have SKBs in frag_list)?
> > - do skb->len and skb->data_len contain the whole SKB length,
> > including the length of all fragments (not only the paged parts)?
> >
> > Is there any docs except the kernel sources itself to refer to?
> davem has some docs up at http://vger.kernel.org/~davem/skb.html and
> http://vger.kernel.org/~davem/skb_data.html
> In particular note the following:
> "The frag_list is used to maintain a chain of SKBs organized for
> fragmentation purposes, it is _not_ used for maintaining paged data."
> So my reading would suggest there is no way to multiple-layer-fragment
> an SKB; the frags are page pointers and offsets, not entire sk_buff
> structs in their own right.
Actually (and perhaps I am mixing up skb_frag_t with the sk_buff in
skb_shinfo(skb)->frag_list) I think it is entirely possible in theory
for the frag_list to itself both skb_frag_t's as well as more sk_buffs
in the ->frag_list- at least that's why I understand fromcode
that recurses using skb_walk_frags(), such as tcp_md5_hash_skb_data().
AIUI, the statement about page pointers and offsets applies to the
skb_frag_t's in the skb_shared_info. The len and data_len should be
the sum-total for the whole skb, including skb_frag_t's and ->frag_list.
--Sowmini
^ permalink raw reply
* Re: [PATCH 00/12] net-next: mediatek: bug fixes and tx stall fixes
From: Andrew Lunn @ 2016-05-05 12:25 UTC (permalink / raw)
To: John Crispin; +Cc: David S. Miller, nbd, netdev, linux-mediatek, linux-kernel
In-Reply-To: <1462440385-51939-1-git-send-email-john@phrozen.org>
On Thu, May 05, 2016 at 11:26:13AM +0200, John Crispin wrote:
> This series is a collection of fixes for bugs that we stumble across while
> doing more performance testing and code level review.
Hi John
I just noticed the code uses kfree(mii_bus), rather than
mdiobus_free(mii_bus).
Andrew
^ permalink raw reply
* Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions
From: Guodong Xu @ 2016-05-05 12:19 UTC (permalink / raw)
To: Dean Jenkins
Cc: John Stultz, lkml, Mark Craske, David S. Miller, YongQin Liu,
linux-usb, netdev, Ivan Vecera, David B. Robins
In-Reply-To: <572B0023.9060505@mentor.com>
On 5 May 2016 at 16:11, Dean Jenkins <Dean_Jenkins@mentor.com> wrote:
> On 05/05/16 00:45, John Stultz wrote:
>>
>> On Tue, May 3, 2016 at 3:54 AM, Dean Jenkins <Dean_Jenkins@mentor.com>
>> wrote:
>>>
>>> On 03/05/16 11:04, Guodong Xu wrote:
>>>>
>>>> did you test on ARM 64-bit system or ARM 32-bit? I ask because HiKey
>>>> is an ARM 64-bit system. I suggest we should be careful on that. I saw
>>>> similar issues when transferring to a 64-bit system in other net
>>>> drivers.
>>>
>>> We used 32-bit ARM and never tested on 64-bit ARM so I suggest that the
>>> commits need to be reviewed with 64-bit OS in mind.
>>>>
>>>>
>>>> Do you have any suggestion on this regard?
>>>
>>> Try testing on a Linux PC x86 32-bit OS which has has a kernel containing
>>> my
>>> ASIX commits. This will help to confirm whether the failure is related to
>>> 32-bit or 64-bit OS. Then try with Linux PC x86 64-bit OS, this should
>>> fail
>>> otherwise it points to something specific in your ARM 64-bit platform.
>>
>> Just as a sample point, I have managed to reproduce exactly this issue
>> on an x86_64 system by simply scp'ing a large file.
>
> Please tell us the x86_64 kernel version number that you used and which
> Linux Distribution it was ? This allows other people a chance to reproduce
> your observations.
>
>>
>> [ 417.819276] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
>> synchronisation was lost, remaining 988
>
> It is interesting that the reported "remaining" value is 988. Is 988 always
> shown ? I mean that do you see any other "remaining" values for the "Data
> Header synchronisation was lost" error message ?
>
>> [ 417.823415] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0xef830347, offset 4
>
> The gap in the timestamps shows 417.823415 - 417.819276 = 0.004139 = 4ms
> which is a large gap in terms of USB 2.0 high speed communications. This gap
> is expected to be in the 100us range for consecutive URBs. So 4ms is
> strange.
>
> The expectation is that the "Data Header synchronisation was lost" error
> message resets the 32-bit header word synchronisation to the start of the
> next URB buffer. The "Bad Header Length, offset 4" is the expected outcome
> for the next URB because it is unlikely the 32-bit header word is at the
> start of URB buffer due to Ethernet frames spanning across URBs.
>>
>> [ 417.827502] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0x31e2b348, offset 4
>
> Timestamps show the gap to be 4ms which is strange for USB 2.0 high speed,
> are you sure high speed mode is being used ?
>>
>> [ 417.843779] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
>> synchronisation was lost, remaining 988
>> [ 417.847921] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0x8af91035, offset 4
>> [ 417.852004] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0x8521fa03, offset 4
>> [ 418.273394] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
>> synchronisation was lost, remaining 988
>> [ 418.277532] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0x33cd9c7c, offset 4
>> [ 418.281683] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0x3d850896, offset 4
>> [ 418.286227] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0x86443357, offset 4
>> [ 418.290319] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
>> 0xee6c81d1, offset 4
>>
>> I don't have any 32bit x86 installs around so I'm not sure I can easly
>> test there, but its clear its not arm64 specific.
>
> I agree the issue is not specific to your ARM 64 bit platform.
>
> Please can you supply the output of ifconfig for the USB to Ethernet
> adaptor, your example above shows eth1 as the device.
>
> Please show the output of ifconfig eth1 before and after the issue is seen.
> This will show us whether the kernel logs any network errors and how many
> bytes have been transferred.
>
> After the issue is seen, please can you show us the output of "dmesg | grep
> asix" so that we can see status messages from the ASIX driver that the USB
> to Ethernet adaptor is using. In particular we need to check that USB high
> speed operation (480Mbps) is being used and not full speed operation
> (12Mbps).
Hi, Dean
I am not sure why do you insist 'not full speed'. Actually, the tests
I run on ARM-64bit is at USB full speed mode. I pasted my log here:
http://paste.ubuntu.com/16236442/
, which includes the information you requested above, ifconfig, dmesg.
The interval between two consecutive errors varies from 10 to 40ms.
> It is interesting that the reported "remaining" value is 988. Is 988 always
> shown ? I mean that do you see any other "remaining" values for the "Data
> Header synchronisation was lost" error message ?
Yes and No. When doing iperf test in TCP mode, always 988. I have
never seen other "remaining" value.
But,
1. I tried "ping -f -s 1400 [my.arm.64bit.board.ip]", but this cannot
trigger the error.
2. Tried iperf in UDP mode, I saw "Data Header synchronisation was
lost" remaining value is 984 (again, seemingly always in several
tries). Log is pasted here. http://paste.ubuntu.com/16236764/
-Guodong Xu
>
> Thanks,
>
> Regards,
> Dean
>
>>
>> thanks
>> -john
>
>
>
> --
> Dean Jenkins
> Embedded Software Engineer
> Linux Transportation Solutions
> Mentor Embedded Software Division
> Mentor Graphics (UK) Ltd.
>
^ permalink raw reply
* Re: [PATCH 3/3] net-next: mediatek: add RX delay support
From: Andrew Lunn @ 2016-05-05 12:13 UTC (permalink / raw)
To: John Crispin; +Cc: David S. Miller, nbd, netdev, linux-mediatek, linux-kernel
In-Reply-To: <1462439856-51788-4-git-send-email-john@phrozen.org>
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
^ permalink raw reply
* Re: [PATCH 2/3] net-next: mediatek: add fixed-phy support
From: Andrew Lunn @ 2016-05-05 12:02 UTC (permalink / raw)
To: John Crispin; +Cc: David S. Miller, nbd, netdev, linux-mediatek, linux-kernel
In-Reply-To: <1462439856-51788-3-git-send-email-john@phrozen.org>
On Thu, May 05, 2016 at 11:17:35AM +0200, John Crispin wrote:
> The MT7623 SoC has a builtin gigabit switch. If we want to use it, GMAC1
> needs to be configured using a fixed link speed and flow control settings.
> The easiest way to do this is to used the fixed-phy driver, allowing us to
> reuse the existing mdio polling code to setup the MAC.
>
> Signed-off-by: John Crispin <john@phrozen.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Looks good.
Andrew
^ 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