* Re: [PATCH v3 net 1/2] net/sched: act_vlan: Push skb->data to mac_header prior calling skb_vlan_*() functions
From: David Miller @ 2016-10-04 1:42 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: netdev, jhs, daniel, pshelar, jiri
In-Reply-To: <1475140241-23586-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Thu, 29 Sep 2016 12:10:40 +0300
> Generic skb_vlan_push/skb_vlan_pop functions don't properly handle the
> case where the input skb data pointer does not point at the mac header:
>
> - They're doing push/pop, but fail to properly unwind data back to its
> original location.
> For example, in the skb_vlan_push case, any subsequent
> 'skb_push(skb, skb->mac_len)' calls make the skb->data point 4 bytes
> BEFORE start of frame, leading to bogus frames that may be transmitted.
>
> - They update rcsum per the added/removed 4 bytes tag.
> Alas if data is originally after the vlan/eth headers, then these
> bytes were already pulled out of the csum.
>
> OTOH calling skb_vlan_push/skb_vlan_pop with skb->data at mac_header
> present no issues.
>
> act_vlan is the only caller to skb_vlan_*() that has skb->data pointing
> at network header (upon ingress).
> Other calles (ovs, bpf) already adjust skb->data at mac_header.
>
> This patch fixes act_vlan to point to the mac_header prior calling
> skb_vlan_*() functions, as other callers do.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v3 net 2/2] net: skbuff: Limit skb_vlan_pop/push() to expect skb->data at mac header
From: David Miller @ 2016-10-04 1:42 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: netdev, jhs, daniel, pshelar, jiri
In-Reply-To: <1475140241-23586-2-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Thu, 29 Sep 2016 12:10:41 +0300
> skb_vlan_pop/push were too generic, trying to support the cases where
> skb->data is at mac header, and cases where skb->data is arbitrarily
> elsewhere.
>
> Supporting an arbitrary skb->data was complex and bogus:
> - It failed to unwind skb->data to its original location post actual
> pop/push.
> (Also, semantic is not well defined for unwinding: If data was into
> the eth header, need to use same offset from start; But if data was
> at network header or beyond, need to adjust the original offset
> according to the push/pull)
> - It mangled the rcsum post actual push/pop, without taking into account
> that the eth bytes might already have been pulled out of the csum.
>
> Most callers (ovs, bpf) already had their skb->data at mac_header upon
> invoking skb_vlan_pop/push.
> Last caller that failed to do so (act_vlan) has been recently fixed.
>
> Therefore, to simplify things, no longer support arbitrary skb->data
> inputs for skb_vlan_pop/push().
>
> skb->data is expected to be exactly at mac_header; WARN otherwise.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: David Miller @ 2016-10-04 1:45 UTC (permalink / raw)
To: shmulik.ladkani
Cc: jhs, xiyou.wangcong, edumazet, daniel, netdev, eric.dumazet
In-Reply-To: <1475147012-15538-5-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Thu, 29 Sep 2016 14:03:32 +0300
> skb2->skb_iif = skb->dev->ifindex;
> skb2->dev = dev;
> - err = dev_queue_xmit(skb2);
> + if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
> + err = dev_queue_xmit(skb2);
> + else
> + netif_receive_skb(skb2);
Can you address the feedback about lack of checking the return
value of netif_receive_skb()? It seems like a legitimate issue,
thanks.
^ permalink raw reply
* Re: [PATCH] af_unix: fix garbage collect vs. MSG_PEEK
From: David Miller @ 2016-10-04 1:51 UTC (permalink / raw)
To: mszeredi; +Cc: netdev, linux-kernel, hannes, kernel
In-Reply-To: <1475150954-10152-1-git-send-email-mszeredi@redhat.com>
From: Miklos Szeredi <mszeredi@redhat.com>
Date: Thu, 29 Sep 2016 14:09:14 +0200
> @@ -1550,6 +1550,17 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb)
> return max_level;
> }
>
> +static void unix_peek_fds(struct scm_cookie *scm, struct sk_buff *skb)
> +{
> + scm->fp = scm_fp_dup(UNIXCB(skb).fp);
> + /*
> + * During garbage collection it is assumed that in-flight sockets don't
> + * get a new external reference. So we need to wait until current run
> + * finishes.
> + */
> + unix_gc_barrier();
> +}
...
> @@ -266,6 +266,11 @@ void wait_for_unix_gc(void)
> wait_event(unix_gc_wait, gc_in_progress == false);
> }
>
> +void unix_gc_barrier(void)
> +{
> + spin_unlock_wait(&unix_gc_lock);
> +}
Can you explain why wait_for_unix_gc() isn't appropriate? I'm a little
bit uncomfortable with a spinlock wait like this, and would rather see
something like the existing helper used.
Thanks.
^ permalink raw reply
* Re: [PATCH v3] net: hns: mark symbols static where possible
From: David Miller @ 2016-10-04 1:52 UTC (permalink / raw)
To: baoyou.xie
Cc: yisen.zhuang, salil.mehta, yankejian, huangdaode, lisheng011,
xieqianqian, fabf, lipeng321, colin.king, simon.horman, arnd,
andrew, ivecera, chenny.xu, xypron.glpk, netdev, linux-kernel,
xie.baoyou, han.fei, tang.qiang007
In-Reply-To: <1475309726-21334-1-git-send-email-baoyou.xie@linaro.org>
From: Baoyou Xie <baoyou.xie@linaro.org>
Date: Sat, 1 Oct 2016 16:15:26 +0800
> We get a few warnings when building kernel with W=1:
...
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> So this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Still doesn't apply to net-next.
^ permalink raw reply
* Re: [PATCH -next] net: qcom/emac: fix return value check in emac_sgmii_config()
From: David Miller @ 2016-10-04 1:53 UTC (permalink / raw)
To: weiyj.lk; +Cc: timur, weiyongjun1, netdev
In-Reply-To: <1475313149-15233-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Sat, 1 Oct 2016 09:12:29 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> In case of error, the function ioremap() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test.
>
> Also add check for return value of platform_get_resource().
>
> Fixes: 54e19bc74f33 ("net: qcom/emac: do not use devm on internal
> phy pdev")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ptp: Fix resource leak in case of error
From: David Miller @ 2016-10-04 1:54 UTC (permalink / raw)
To: christophe.jaillet; +Cc: richardcochran, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1475391856-15046-1-git-send-email-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sun, 2 Oct 2016 09:04:16 +0200
> A call to 'ida_simple_remove()' is missing in the error handling path.
>
> This as been spotted with the following coccinelle script which tries to
> detect missing 'ida_simple_remove()' call in error handling paths.
...
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied.
^ permalink raw reply
* Re: [PATCH net] vti6: flush x-netns xfrm cache when vti interface is removed
From: Lance Richardson @ 2016-10-04 2:19 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, steffen klassert, netdev
In-Reply-To: <1475226667-22404-1-git-send-email-nicolas.dichtel@6wind.com>
> From: "Nicolas Dichtel" <nicolas.dichtel@6wind.com>
> To: davem@davemloft.net, "steffen klassert" <steffen.klassert@secunet.com>
> Cc: netdev@vger.kernel.org, "Nicolas Dichtel" <nicolas.dichtel@6wind.com>, "Lance Richardson" <lrichard@redhat.com>
> Sent: Friday, September 30, 2016 5:11:07 AM
> Subject: [PATCH net] vti6: flush x-netns xfrm cache when vti interface is removed
>
> This is the same fix than commit a5d0dc810abf ("vti: flush x-netns xfrm
> cache when vti interface is removed")
>
> This patch fixes a refcnt problem when a x-netns vti6 interface is removed:
> unregister_netdevice: waiting for vti6_test to become free. Usage count = 1
>
> Here is a script to reproduce the problem:
>
> ip link set dev ntfp2 up
> ip addr add dev ntfp2 2001::1/64
> ip link add vti6_test type vti6 local 2001::1 remote 2001::2 key 1
> ip netns add secure
> ip link set vti6_test netns secure
> ip netns exec secure ip link set vti6_test up
> ip netns exec secure ip link s lo up
> ip netns exec secure ip addr add dev vti6_test 2003::1/64
> ip -6 xfrm policy add dir out tmpl src 2001::1 dst 2001::2 proto esp \
> mode tunnel mark 1
> ip -6 xfrm policy add dir in tmpl src 2001::2 dst 2001::1 proto esp \
> mode tunnel mark 1
> ip xfrm state add src 2001::1 dst 2001::2 proto esp spi 1 mode tunnel \
> enc des3_ede 0x112233445566778811223344556677881122334455667788 mark 1
> ip xfrm state add src 2001::2 dst 2001::1 proto esp spi 1 mode tunnel \
> enc des3_ede 0x112233445566778811223344556677881122334455667788 mark 1
> ip netns exec secure ping6 -c 4 2003::2
> ip netns del secure
>
> CC: Lance Richardson <lrichard@redhat.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
Looks good, corresponds closely to the ipv4 version of the fix.
Acked-by: Lance Richardson <lrichard@redhat.com>
^ permalink raw reply
* [net-next 1/3] i40e: check if vectors are already depleted when doing VMDq allocation
From: Jeff Kirsher @ 2016-10-04 2:25 UTC (permalink / raw)
To: davem
Cc: Stefan Assmann, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1475547903-22168-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Stefan Assmann <sassmann@kpanic.de>
During MSI-X vector allocation for VMDq, a check for "no vectors left"
was missing, add it. This prevents more vectors to be allocated than
available.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 8176596..66d2ca0 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7674,18 +7674,23 @@ static int i40e_init_msix(struct i40e_pf *pf)
int vmdq_vecs_wanted = pf->num_vmdq_vsis * pf->num_vmdq_qps;
int vmdq_vecs = min_t(int, vectors_left, vmdq_vecs_wanted);
- /* if we're short on vectors for what's desired, we limit
- * the queues per vmdq. If this is still more than are
- * available, the user will need to change the number of
- * queues/vectors used by the PF later with the ethtool
- * channels command
- */
- if (vmdq_vecs < vmdq_vecs_wanted)
- pf->num_vmdq_qps = 1;
- pf->num_vmdq_msix = pf->num_vmdq_qps;
+ if (!vectors_left) {
+ pf->num_vmdq_msix = 0;
+ pf->num_vmdq_qps = 0;
+ } else {
+ /* if we're short on vectors for what's desired, we limit
+ * the queues per vmdq. If this is still more than are
+ * available, the user will need to change the number of
+ * queues/vectors used by the PF later with the ethtool
+ * channels command
+ */
+ if (vmdq_vecs < vmdq_vecs_wanted)
+ pf->num_vmdq_qps = 1;
+ pf->num_vmdq_msix = pf->num_vmdq_qps;
- v_budget += vmdq_vecs;
- vectors_left -= vmdq_vecs;
+ v_budget += vmdq_vecs;
+ vectors_left -= vmdq_vecs;
+ }
}
pf->msix_entries = kcalloc(v_budget, sizeof(struct msix_entry),
--
2.7.4
^ permalink raw reply related
* [net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2016-10-03
From: Jeff Kirsher @ 2016-10-04 2:25 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene,
guru.anbalagane
This series contains fixes to i40e only.
Stefan Assmann provides the changes in this series to resolve an issue
where when we run out of MSIx vectors, iWARP gets disabled automatically.
First adds a check for "no vectors left" during MSIx vector allocation
for VMDq, which will prevent more vectors being allocated than available.
Then fixed the MSIx vector redistribution when we reach the hardware limit
for vectors so that additional features like VMDq, iWARP, etc do not get
starved for vectors because the PF is hogging all the resources. Lastly,
fix the issue for flow director by moving the check for the reaching the
vector limit earlier in the code so that a decision can be made on
disabling flow director.
The following are changes since commit b9118b7221ebb12156d2b08d4d5647bc6076d6bb:
ptp: Fix resource leak in case of error
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Stefan Assmann (3):
i40e: check if vectors are already depleted when doing VMDq allocation
i40e: fix MSI-X vector redistribution if hw limit is reached
i40e: fix sideband flow director vector allocation
drivers/net/ethernet/intel/i40e/i40e_main.c | 76 ++++++++++++++++++-----------
1 file changed, 47 insertions(+), 29 deletions(-)
--
2.7.4
^ permalink raw reply
* [net-next 2/3] i40e: fix MSI-X vector redistribution if hw limit is reached
From: Jeff Kirsher @ 2016-10-04 2:25 UTC (permalink / raw)
To: davem
Cc: Stefan Assmann, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1475547903-22168-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Stefan Assmann <sassmann@kpanic.de>
The driver allocates 1 vector per CPU thread and the current hardware
limit for vectors is 129 per PF. On systems with 128 or more threads
this currently means all vectors are used by the PF leaving no room for
additional features like VMDq, iWARP, etc...
The code that should redistribute the vectors in this case is broken and
never triggers. Fixed the code so that it actually triggers if the
hardware limit is reached and adjust the number of queue pairs
accordingly.
Also the number of initially requested iWARP vectors was not properly
saved when the vector limit was reached, and therefore always zero.
Comparison with debug statement.
Before:
i40e 0000:2d:00.0: VMDq disabled, not enough MSI-X vectors
i40e 0000:2d:00.0: IWARP disabled, not enough MSI-X vectors
i40e 00.0 MSI-X vector distribution: PF 128, VMDq 0, FDSB 0, iWARP 0
After:
i40e 0000:2d:00.0: MSI-X vector limit reached, attempting to redistribute vectors
i40e 00.0 MSI-X vector distribution: PF 78, VMDq 8, FDSB 0, iWARP 42
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 38 +++++++++++++++++------------
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 66d2ca0..ca7dd43 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7661,6 +7661,8 @@ static int i40e_init_msix(struct i40e_pf *pf)
#endif
/* can we reserve enough for iWARP? */
if (pf->flags & I40E_FLAG_IWARP_ENABLED) {
+ iwarp_requested = pf->num_iwarp_msix;
+
if (!vectors_left)
pf->num_iwarp_msix = 0;
else if (vectors_left < pf->num_iwarp_msix)
@@ -7702,21 +7704,6 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->msix_entries[i].entry = i;
v_actual = i40e_reserve_msix_vectors(pf, v_budget);
- if (v_actual != v_budget) {
- /* If we have limited resources, we will start with no vectors
- * for the special features and then allocate vectors to some
- * of these features based on the policy and at the end disable
- * the features that did not get any vectors.
- */
- iwarp_requested = pf->num_iwarp_msix;
- pf->num_iwarp_msix = 0;
-#ifdef I40E_FCOE
- pf->num_fcoe_qps = 0;
- pf->num_fcoe_msix = 0;
-#endif
- pf->num_vmdq_msix = 0;
- }
-
if (v_actual < I40E_MIN_MSIX) {
pf->flags &= ~I40E_FLAG_MSIX_ENABLED;
kfree(pf->msix_entries);
@@ -7730,9 +7717,16 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->num_lan_qps = 1;
pf->num_lan_msix = 1;
- } else if (v_actual != v_budget) {
+ } else if (!vectors_left) {
+ /* If we have limited resources, we will start with no vectors
+ * for the special features and then allocate vectors to some
+ * of these features based on the policy and at the end disable
+ * the features that did not get any vectors.
+ */
int vec;
+ dev_info(&pf->pdev->dev,
+ "MSI-X vector limit reached, attempting to redistribute vectors\n");
/* reserve the misc vector */
vec = v_actual - 1;
@@ -7740,6 +7734,10 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->num_vmdq_msix = 1; /* force VMDqs to only one vector */
pf->num_vmdq_vsis = 1;
pf->num_vmdq_qps = 1;
+#ifdef I40E_FCOE
+ pf->num_fcoe_qps = 0;
+ pf->num_fcoe_msix = 0;
+#endif
pf->flags &= ~I40E_FLAG_FD_SB_ENABLED;
/* partition out the remaining vectors */
@@ -7775,6 +7773,7 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->num_lan_msix = min_t(int,
(vec - (pf->num_iwarp_msix + pf->num_vmdq_vsis)),
pf->num_lan_msix);
+ pf->num_lan_qps = pf->num_lan_msix;
#ifdef I40E_FCOE
/* give one vector to FCoE */
if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
@@ -7804,6 +7803,13 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->flags &= ~I40E_FLAG_FCOE_ENABLED;
}
#endif
+ i40e_debug(&pf->hw, I40E_DEBUG_INIT,
+ "MSI-X vector distribution: PF %d, VMDq %d, FDSB %d, iWARP %d\n",
+ pf->num_lan_msix,
+ pf->num_vmdq_msix * pf->num_vmdq_vsis,
+ pf->num_fdsb_msix,
+ pf->num_iwarp_msix);
+
return v_actual;
}
--
2.7.4
^ permalink raw reply related
* [net-next 3/3] i40e: fix sideband flow director vector allocation
From: Jeff Kirsher @ 2016-10-04 2:25 UTC (permalink / raw)
To: davem
Cc: Stefan Assmann, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1475547903-22168-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Stefan Assmann <sassmann@kpanic.de>
Currently if the MSI-X vector limit is reached the sideband flow
director gets disabled. A bit too early to make that decision, as
vectors may get re-distributed. So move the check further back.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ca7dd43..0044c29 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7641,7 +7641,6 @@ static int i40e_init_msix(struct i40e_pf *pf)
vectors_left--;
} else {
pf->num_fdsb_msix = 0;
- pf->flags &= ~I40E_FLAG_FD_SB_ENABLED;
}
}
@@ -7738,7 +7737,6 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->num_fcoe_qps = 0;
pf->num_fcoe_msix = 0;
#endif
- pf->flags &= ~I40E_FLAG_FD_SB_ENABLED;
/* partition out the remaining vectors */
switch (vec) {
@@ -7770,6 +7768,10 @@ static int i40e_init_msix(struct i40e_pf *pf)
pf->num_vmdq_vsis = min_t(int, (vec / 2),
I40E_DEFAULT_NUM_VMDQ_VSI);
}
+ if (pf->flags & I40E_FLAG_FD_SB_ENABLED) {
+ pf->num_fdsb_msix = 1;
+ vec--;
+ }
pf->num_lan_msix = min_t(int,
(vec - (pf->num_iwarp_msix + pf->num_vmdq_vsis)),
pf->num_lan_msix);
@@ -7785,6 +7787,11 @@ static int i40e_init_msix(struct i40e_pf *pf)
}
}
+ if ((pf->flags & I40E_FLAG_FD_SB_ENABLED) &&
+ (pf->num_fdsb_msix == 0)) {
+ dev_info(&pf->pdev->dev, "Sideband Flowdir disabled, not enough MSI-X vectors\n");
+ pf->flags &= ~I40E_FLAG_FD_SB_ENABLED;
+ }
if ((pf->flags & I40E_FLAG_VMDQ_ENABLED) &&
(pf->num_vmdq_msix == 0)) {
dev_info(&pf->pdev->dev, "VMDq disabled, not enough MSI-X vectors\n");
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2
From: R. Parameswaran @ 2016-10-04 3:12 UTC (permalink / raw)
To: James Chapman
Cc: R. Parameswaran, kleptog, netdev, davem, linux-kernel, nprachan,
rshearma, dfawcus, stephen, acme, lboccass, bhong
In-Reply-To: <1cec5be4-0719-0dca-d3c6-8c794c867672@katalix.com>
Hi James,
Please see inline, thanks for the reply:
On Sat, 1 Oct 2016, James Chapman wrote:
> On 30/09/16 03:39, R. Parameswaran wrote:
> >
> >>> + /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/
> >>> + if (tunnel->sock->sk_family == AF_INET)
> >>> + overhead += (ETH_HLEN + sizeof(struct iphdr));
> >>> + else if (tunnel->sock->sk_family == AF_INET6)
> >>> + overhead += (ETH_HLEN + sizeof(struct ipv6hdr));
> >> What about options in the IP header? If certain options are set on the
> >> socket, the IP header may be larger.
> >>
> > Thanks for the reply - It looks like IP options can only be
> > enabled through setsockopt on an application's socket (if there's any
> > other way to turn on IP options, please let me know - didn't see any
> > sysctl setting for transmit). This scenario would come
> > into picture when an application opens a raw IP or UDP socket such that it
> > routes into the L2TP logical interface.
>
> No. An L2TP daemon (userspace) will open a socket for each tunnel that
> it creates. Control and data packets use the same socket, which is the
> socket used by this code. It may set any options on its sockets. L2TP
> tunnel sockets can be created either by an L2TP daemon (managed tunnels)
> or by ip l2tp commands (unmanaged tunnels).
>
One Q I have is whether it would be sufficient to solve this for the
common case (i.e no IP options) and have an expectation that the
administrator will explicitly provision the mtu using the 'ip link ...
mtu' command when dealing with infrequent occurences like IP options?
But looking at the code, it looks to be possible to pick up whether
options are enabled and how long the options are, from the ip_options struct
embedded in the tunnel socket. If you want me to, I can repost the patch
with this change (will need a few days) - please let me know if this is
what you had in mind.
thanks,
Ramkumar
> > If you take the case of a plain IP (ethernet) interface, even if an
> > application opened a socket turning on IP options, it would not change
> > the MTU of the underlying interface, and it would not affect other
> > applications transacting packets on the same interface. I know its not an
> > exact parallel to this case, but since the IP option control is per
> > application, we probably should not factor it into the L2TP logical interface?
> > We cannot affect other applications/processes running on the same L2TP
> > tunnel. Also, since the application using IP options knows that it has turned
> > on IP options, maybe we can count on it to factor the size of the options
> > into the size of the payload it sends into the socket, or set the mtu on the
> > L2TP interface through config?
>
> No. See above.
>
> >
> > Other than this, I don't see keepalives or anything else in which the
> > kernel will source its own packet into the L2TP interface, outside of
> > an application injected packet - if there is something like that, please
> > let me know. The user space L2TP daemon would probably fall in the
> > category of applications.
> >
> > thanks,
> >
> > Ramkumar
> >
> >
>
>
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: David Miller @ 2016-10-04 3:24 UTC (permalink / raw)
To: Yuval.Mintz
Cc: netdev, linux-rdma, Ram.Amrani, Michal.Kalderon, Ariel.Elior,
dledford
In-Reply-To: <1475348401-31392-1-git-send-email-Yuval.Mintz@caviumnetworks.com>
From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Date: Sat, 1 Oct 2016 21:59:54 +0300
> In the last couple of weeks we've been sending RFCs for the qedr
> driver - the RoCE driver for QLogic FastLinQ 4xxxx line of adapters.
> Latest RFC can be found at [1].
>
> At Doug's advice [2], we've decided to split the series into two:
> - first part contains the qed backbone that's necessary for all the
> configurations relating to the qedr driver, as well as the qede
> infrastructure that is used for communication between the qedr and qede.
> - Second part consists of the actual qedr driver and introduces almost
> no changes to qed/qede.
>
> This is the first of said two parts. The second half would be sent
> later this week.
>
> The only 'oddity' in the devision are the Kconfig options -
> As this series introduces both LL2 and QEDR-based logic in qed/qede,
> I wanted to add the CONFIG_INFINIBAND_QEDR option here [with default n].
> Otherwise, a lot of the code introduced would be dead-code [won't even
> be compiled] until qedr is accepted.
> As a result I've placed the config option in an odd place - under
> qlogic's Kconfig. The second series would then remove that option
> and add it in its correct place under the infiniband Kconfig.
> [I'm fine with pushing it there to begin with, but I didn't want to
> 'contaminate' non-qlogic configuration files with half-baked options].
>
> Dave - I don't think you were E-mailed with Doug's suggestion.
> I think the notion was to have the two halves accepted side-by-side,
> but actually the first has no dependency issues, so it's also
> possible to simply take this first to net-next, and push the qedr
> into rdma once it's merged. But it's basically up to you and Doug;
> We'd align with whatever suits you best.
I'll take this, series applied, thanks.
^ permalink raw reply
* Re: [net-next 0/2][pull request] 100GbE Intel Wired LAN Driver Updates 2016-10-02
From: David Miller @ 2016-10-04 3:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1475476843-23405-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 2 Oct 2016 23:40:41 -0700
> This series contains updates to fm10k only.
>
> Jake fixes an issue where PTP applications requesting software timestamps
> may complain that the requested mode is not supported, so add a generic
> callback for those drivers that have software transmit timestamp support
> enabled. Then provides a trivial cleanup where a code was not wrapped
> properly. Got make sure that code looks good in a 80 character limit.
>
> The following are changes since commit 7c70c4f8b2bf5ed777120f3d70efe35e64930c10:
> cxgb4: unexport cxgb4_dcb_enabled
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 100GbE
Pulled.
^ permalink raw reply
* Re: [net-next] i40e: avoid NULL pointer dereference and recursive errors on early PCI error
From: David Miller @ 2016-10-04 3:29 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: gpiccoli, netdev, nhorman, sassmann, jogreene, guru.anbalagane,
stable
In-Reply-To: <1475479872-112822-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 3 Oct 2016 00:31:12 -0700
> From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
>
> Although rare, it's possible to hit PCI error early on device
> probe, meaning possibly some structs are not entirely initialized,
> and some might even be completely uninitialized, leading to NULL
> pointer dereference.
>
> The i40e driver currently presents a "bad" behavior if device hits
> such early PCI error: firstly, the struct i40e_pf might not be
> attached to pci_dev yet, leading to a NULL pointer dereference on
> access to pf->state.
>
> Even checking if the struct is NULL and avoiding the access in that
> case isn't enough, since the driver cannot recover from PCI error
> that early; in our experiments we saw multiple failures on kernel
> log, like:
>
> [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
> [549.664] i40e: probe of 0007:01:00.1 failed with error -15
> [...]
> [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
> device firmware failed to init. Try updating your NVM image.
> [871.644] i40e: probe of 0007:01:00.1 failed with error -32
> [...]
> [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored
>
> Between the first probe failure (error -15) and the second (error -32)
> another PCI error happened due to the first bad probe. Also, driver
> started to flood console with those ARQ event messages.
>
> This patch will prevent these issues by allowing error recovery
> mechanism to remove the failed device from the system instead of
> trying to recover from early PCI errors during device probe.
>
> CC: <stable@vger.kernel.org>
> Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
> Acked-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2016-10-03
From: David Miller @ 2016-10-04 3:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1475547903-22168-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 3 Oct 2016 19:25:00 -0700
> This series contains fixes to i40e only.
>
> Stefan Assmann provides the changes in this series to resolve an issue
> where when we run out of MSIx vectors, iWARP gets disabled automatically.
> First adds a check for "no vectors left" during MSIx vector allocation
> for VMDq, which will prevent more vectors being allocated than available.
> Then fixed the MSIx vector redistribution when we reach the hardware limit
> for vectors so that additional features like VMDq, iWARP, etc do not get
> starved for vectors because the PF is hogging all the resources. Lastly,
> fix the issue for flow director by moving the check for the reaching the
> vector limit earlier in the code so that a decision can be made on
> disabling flow director.
>
> The following are changes since commit b9118b7221ebb12156d2b08d4d5647bc6076d6bb:
> ptp: Fix resource leak in case of error
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] vmxnet3: Wake queue from reset work
From: David Miller @ 2016-10-04 4:36 UTC (permalink / raw)
To: bpoirier; +Cc: netdev, skhare, pv-drivers
In-Reply-To: <20161003024750.30015-1-bpoirier@suse.com>
From: Benjamin Poirier <bpoirier@suse.com>
Date: Mon, 3 Oct 2016 10:47:50 +0800
> vmxnet3_reset_work() expects tx queues to be stopped (via
> vmxnet3_quiesce_dev -> netif_tx_disable). However, this races with the
> netif_wake_queue() call in netif_tx_timeout() such that the driver's
> start_xmit routine may be called unexpectedly, triggering one of the BUG_ON
> in vmxnet3_map_pkt with a stack trace like this:
...
> Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: disallow rtr_solicits < -1
From: David Miller @ 2016-10-04 4:38 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, ek, lorenzo
In-Reply-To: <1475476917-17382-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Sun, 2 Oct 2016 23:41:57 -0700
> From: Maciej Żenczykowski <maze@google.com>
>
> This disallows setting /proc/sys/net/ipv6/conf/*/router_solicitations
> to values below -1.
>
> -1 continues to mean an unlimited number of retransmits.
>
> Note: this depends on 'ipv6 addrconf: remove addrconf_sysctl_hop_limit()'
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
Please remove the const qualifier and the casts to be consistent
with how we handle this elsewhere.
Thanks.
^ permalink raw reply
* Re: [PATCH v5 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: David Miller @ 2016-10-04 4:48 UTC (permalink / raw)
To: Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
Allan.Nielsen-dzo6w/eZyo2tG0bUXCXiUA, andrew-g2DYL2Zd6BY
In-Reply-To: <1475479393-24308-1-git-send-email-Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>
From: Raju Lakkaraju <Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>
Date: Mon, 3 Oct 2016 12:53:13 +0530
> From: Raju Lakkaraju <Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>
>
> Edge-rate:
> As system and networking speeds increase, a signal's output transition,
> also know as the edge rate or slew rate (V/ns), takes on greater importance
> because high-speed signals come with a price. That price is an assortment of
> interference problems like ringing on the line, signal overshoot and
> undershoot, extended signal settling times, crosstalk noise, transmission
> line reflections, false signal detection by the receiving device and
> electromagnetic interference (EMI) -- all of which can negate the potential
> gains designers are seeking when they try to increase system speeds through
> the use of higher performance logic devices. The fact is, faster signaling
> edge rates can cause a higher level of electrical noise or other type of
> interference that can actually lead to slower line speeds and lower maximum
> system frequencies. This parameter allow the board designers to change the
> driving strange, and thereby change the EMI behavioral.
>
> Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
>
> Tested on Beaglebone Black with VSC 8531 PHY.
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/7] xen-netback: guest rx side refactor
From: David Miller @ 2016-10-04 4:51 UTC (permalink / raw)
To: paul.durrant; +Cc: netdev, xen-devel
In-Reply-To: <1475479872-23717-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Mon, 3 Oct 2016 08:31:05 +0100
> This series refactors the guest rx side of xen-netback:
>
> - The code is moved into its own source module.
>
> - The prefix variant of GSO handling is retired (since it is no longer
> in common use, and alternatives exist).
>
> - The code is then simplified and modifications made to improve
> performance.
This doesn't apply cleanly to net-next, please respin.
^ permalink raw reply
* [PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode
From: Mike Looijmans @ 2016-10-04 5:52 UTC (permalink / raw)
To: netdev; +Cc: f.fainelli, linux-kernel, Mike Looijmans
In-Reply-To: <1475499870-11465-1-git-send-email-mike.looijmans@topic.nl>
Set bit 0 in register 1C.23 to enable the EDPD feature of the
KSZ9031 PHY. This reduces power consumption when the link is
down.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
v2: Unconditionally enable EDPD mode
drivers/net/phy/micrel.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 885ac9c..081df68 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -439,6 +439,10 @@ static int ksz9021_config_init(struct phy_device *phydev)
#define MII_KSZ9031RN_TX_DATA_PAD_SKEW 6
#define MII_KSZ9031RN_CLK_PAD_SKEW 8
+/* MMD Address 0x1C */
+#define MII_KSZ9031RN_EDPD 0x23
+#define MII_KSZ9031RN_EDPD_ENABLE BIT(0)
+
static int ksz9031_extended_write(struct phy_device *phydev,
u8 mode, u32 dev_addr, u32 regnum, u16 val)
{
@@ -510,6 +514,18 @@ static int ksz9031_center_flp_timing(struct phy_device *phydev)
return genphy_restart_aneg(phydev);
}
+/* Enable energy-detect power-down mode */
+static int ksz9031_enable_edpd(struct phy_device *phydev)
+{
+ int reg;
+
+ reg = ksz9031_extended_read(phydev, OP_DATA, 0x1C, MII_KSZ9031RN_EDPD);
+ if (reg < 0)
+ return reg;
+ return ksz9031_extended_write(phydev, OP_DATA, 0x1C, MII_KSZ9031RN_EDPD,
+ reg | MII_KSZ9031RN_EDPD_ENABLE);
+}
+
static int ksz9031_config_init(struct phy_device *phydev)
{
const struct device *dev = &phydev->mdio.dev;
@@ -525,6 +541,11 @@ static int ksz9031_config_init(struct phy_device *phydev)
};
static const char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
const struct device *dev_walker;
+ int result;
+
+ result = ksz9031_enable_edpd(phydev);
+ if (result < 0)
+ return result;
/* The Micrel driver has a deprecated option to place phy OF
* properties in the MAC node. Walk up the tree of devices to
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] Add netdev all_adj_list refcnt propagation to fix panic
From: David Miller @ 2016-10-04 6:06 UTC (permalink / raw)
To: acollins; +Cc: dsa, netdev, vfalico, nikolay
In-Reply-To: <1475523782-6358-1-git-send-email-acollins@cradlepoint.com>
From: Andrew Collins <acollins@cradlepoint.com>
Date: Mon, 3 Oct 2016 13:43:02 -0600
> This is a respin of a patch to fix a relatively easily reproducible kernel
> panic related to the all_adj_list handling for netdevs in recent kernels.
>
> The following sequence of commands will reproduce the issue:
>
> ip link add link eth0 name eth0.100 type vlan id 100
> ip link add link eth0 name eth0.200 type vlan id 200
> ip link add name testbr type bridge
> ip link set eth0.100 master testbr
> ip link set eth0.200 master testbr
> ip link add link testbr mac0 type macvlan
> ip link delete dev testbr
>
> This creates an upper/lower tree of (excuse the poor ASCII art):
>
> /---eth0.100-eth0
> mac0-testbr-
> \---eth0.200-eth0
>
> When testbr is deleted, the all_adj_lists are walked, and eth0 is deleted twice from
> the mac0 list. Unfortunately, during setup in __netdev_upper_dev_link, only one
> reference to eth0 is added, so this results in a panic.
>
> This change adds reference count propagation so things are handled properly.
>
> Matthias Schiffer reported a similar crash in batman-adv:
>
> https://github.com/freifunk-gluon/gluon/issues/680
> https://www.open-mesh.org/issues/247
>
> which this patch also seems to resolve.
>
> Signed-off-by: Andrew Collins <acollins@cradlepoint.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] net/ncsi: NCSI Improvment and bug fixes
From: David Miller @ 2016-10-04 6:13 UTC (permalink / raw)
To: gwshan; +Cc: netdev, joel, yuvali, benh
In-Reply-To: <1475540754-31169-1-git-send-email-gwshan@linux.vnet.ibm.com>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
Date: Tue, 4 Oct 2016 11:25:46 +1100
> This series of patches improves NCSI stack according to the comments
> I received after the NCSI code was merged to 4.8.rc1:
>
> * PATCH[1/8] fixes the build warning caused by xchg() with ia64-linux-gcc.
> The atomic operations are removed. The NCSI's lock should be taken when
> reading or updating its state and chained state.
> * Channel ID (0x1f) is the reserved one and it cannot be valid channel ID.
> So we needn't try to probe channel whose ID is 0x1f. PATCH[2/8] and
> PATCH[3/8] are addressing this issue.
> * The request IDs are assigned in round-robin fashion, but it's broken.
> PATCH[4/8] make it work.
> * PATCH[5/8] and PATCH[6/8] reworks the channel monitoring to improve the
> code readability and its robustness.
> * PATCH[7/8] and PATCH[8/8] introduces ncsi_stop_dev() so that the network
> device can be closed and opened afterwards. No error will be seen.
>
> Changelog
> =========
> v2:
> * The NCSI's lock is taken when reading or updating its state as the
> {READ,WRITE}_ONCE() isn't reliable.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] Panic when tc_lookup_action_n finds a partially initialized action.
From: Krister Johansen @ 2016-10-04 6:38 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Krister Johansen, netdev, Cong Wang
In-Reply-To: <92102cf9-9f27-3a9f-06b6-f45201dbc55c@mojatatu.com>
On Sun, Oct 02, 2016 at 09:18:06PM -0400, Jamal Hadi Salim wrote:
> On 16-10-01 11:13 PM, Krister Johansen wrote:
> >A tc_action_ops structure is visibile as soon as it is placed in the
> >act_base list. When tcf_regsiter_action adds an item to this list and
> >drops act_mod_lock, registration is not complete until
> >register_pernet_subsys() finishes.
> >
> >If two threads attempt to modify a tc action in a way that triggers a
> >module load, the thread that wins the race ends up defeferencing a NULL
> >pointer after tcf_action_init_1() invokes a_o->init(). In the
> >particular case that this submitter encountered, the panic occurred in
> >tcf_gact_init() when net_generic() returned a NULL tc_action_net
> >pointer. The gact_net_id needed to fetch the correct pointer was not
> >yet set, because the register_pernet_subsys() call was pending in
> >another thread.
> >
> >Fixes: ddf97ccdd7cb ("net_sched: add network namespace support for tc actions")
> >Signed-off-by: Krister Johansen <kjlx@templeofstupid.com>
>
> Looks reasonable to me but will let Cong a closer look since he added
> that code.
Thanks, I appreicate you taking a look. I'll follow up with Cong.
-K
^ 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