* [net-next 07/14] i40e/i40evf: make IPv6 ATR code clearer
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170726103123.76743-1-jeffrey.t.kirsher@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
This just reorders some local vars and makes the code flow
clearer.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index b936febc315a..c9a149678926 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2451,9 +2451,15 @@ static void i40e_atr(struct i40e_ring *tx_ring, struct sk_buff *skb,
hlen = (hdr.network[0] & 0x0F) << 2;
l4_proto = hdr.ipv4->protocol;
} else {
- hlen = hdr.network - skb->data;
- l4_proto = ipv6_find_hdr(skb, &hlen, IPPROTO_TCP, NULL, NULL);
- hlen -= hdr.network - skb->data;
+ /* find the start of the innermost ipv6 header */
+ unsigned int inner_hlen = hdr.network - skb->data;
+ unsigned int h_offset = inner_hlen;
+
+ /* this function updates h_offset to the end of the header */
+ l4_proto =
+ ipv6_find_hdr(skb, &h_offset, IPPROTO_TCP, NULL, NULL);
+ /* hlen will contain our best estimate of the tcp header */
+ hlen = h_offset - inner_hlen;
}
if (l4_proto != IPPROTO_TCP)
--
2.13.3
^ permalink raw reply related
* [net-next 06/14] i40e: fix odd formatting and indent
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170726103123.76743-1-jeffrey.t.kirsher@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
The compiler warned on an oddly indented bit of code, and when
investigating that, noted that the functions themselves had
an odd flow. The if condition was checked, and would exclude
a call to AQ, but then the aq_ret would be checked unconditionally
which just looks really weird, and is likely to cause objections.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index ba327e90f32a..2e261bb59d10 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1741,16 +1741,14 @@ static int i40e_vc_config_promiscuous_mode_msg(struct i40e_vf *vf,
NULL);
} else if (i40e_getnum_vf_vsi_vlan_filters(vsi)) {
hash_for_each(vsi->mac_filter_hash, bkt, f, hlist) {
- aq_ret = 0;
- if (f->vlan >= 0 && f->vlan <= I40E_MAX_VLANID) {
- aq_ret =
- i40e_aq_set_vsi_uc_promisc_on_vlan(hw,
- vsi->seid,
- alluni,
- f->vlan,
- NULL);
- aq_err = pf->hw.aq.asq_last_status;
- }
+ if (f->vlan < 0 || f->vlan > I40E_MAX_VLANID)
+ continue;
+ aq_ret = i40e_aq_set_vsi_uc_promisc_on_vlan(hw,
+ vsi->seid,
+ alluni,
+ f->vlan,
+ NULL);
+ aq_err = pf->hw.aq.asq_last_status;
if (aq_ret)
dev_err(&pf->pdev->dev,
"Could not add VLAN %d to Unicast promiscuous domain err %s aq_err %s\n",
--
2.13.3
^ permalink raw reply related
* [net-next 05/14] i40e: fix up 32 bit timespec references
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170726103123.76743-1-jeffrey.t.kirsher@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
As it turns out there was only a small set of errors
on 32 bit, and we just needed to be using the right calls
for dealing with timespec64 variables.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
index 1a0be835fa06..0129ed3b78ec 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
@@ -158,13 +158,12 @@ static int i40e_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
static int i40e_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
{
struct i40e_pf *pf = container_of(ptp, struct i40e_pf, ptp_caps);
- struct timespec64 now, then;
+ struct timespec64 now;
- then = ns_to_timespec64(delta);
mutex_lock(&pf->tmreg_lock);
i40e_ptp_read(pf, &now);
- now = timespec64_add(now, then);
+ timespec64_add_ns(&now, delta);
i40e_ptp_write(pf, (const struct timespec64 *)&now);
mutex_unlock(&pf->tmreg_lock);
--
2.13.3
^ permalink raw reply related
* [net-next 04/14] i40e: Handle admin Q timeout when releasing NVM
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem
Cc: Paul M Stillwell Jr, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170726103123.76743-1-jeffrey.t.kirsher@intel.com>
From: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com>
There are some rare cases where the release resource call will return an
admin Q timeout. In these cases the code needs to try to release the
resource again until it succeeds or it times out.
Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_nvm.c b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
index 800bd55d0159..17607a2c0a65 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -134,8 +134,25 @@ i40e_status i40e_acquire_nvm(struct i40e_hw *hw,
**/
void i40e_release_nvm(struct i40e_hw *hw)
{
- if (!hw->nvm.blank_nvm_mode)
- i40e_aq_release_resource(hw, I40E_NVM_RESOURCE_ID, 0, NULL);
+ i40e_status ret_code = I40E_SUCCESS;
+ u32 total_delay = 0;
+
+ if (hw->nvm.blank_nvm_mode)
+ return;
+
+ ret_code = i40e_aq_release_resource(hw, I40E_NVM_RESOURCE_ID, 0, NULL);
+
+ /* there are some rare cases when trying to release the resource
+ * results in an admin Q timeout, so handle them correctly
+ */
+ while ((ret_code == I40E_ERR_ADMIN_QUEUE_TIMEOUT) &&
+ (total_delay < hw->aq.asq_cmd_timeout)) {
+ usleep_range(1000, 2000);
+ ret_code = i40e_aq_release_resource(hw,
+ I40E_NVM_RESOURCE_ID,
+ 0, NULL);
+ total_delay++;
+ }
}
/**
--
2.13.3
^ permalink raw reply related
* [net-next 03/14] i40e: remove WQ_UNBOUND and the task limit of our workqueue
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170726103123.76743-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
During certain events such as a CORER, multiple devices will run a work
task to handle some cleanup. This can cause issues due to
a single-threaded workqueue which can mean that a device doesn't cleanup
in time. Prevent this by removing the single-threaded restriction on the
module workqueue. This avoids the need to add more complex yielding
logic in our service task routine. This is also similar to what other
drivers such as fm10k do.
Signed-off-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>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 933b8e357ee4..22e60841cb22 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -12180,12 +12180,14 @@ static int __init i40e_init_module(void)
i40e_driver_string, i40e_driver_version_str);
pr_info("%s: %s\n", i40e_driver_name, i40e_copyright);
- /* we will see if single thread per module is enough for now,
- * it can't be any worse than using the system workqueue which
- * was already single threaded
+ /* There is no need to throttle the number of active tasks because
+ * each device limits its own task using a state bit for scheduling
+ * the service task, and the device tasks do not interfere with each
+ * other, so we don't set a max task limit. We must set WQ_MEM_RECLAIM
+ * since we need to be able to guarantee forward progress even under
+ * memory pressure.
*/
- i40e_wq = alloc_workqueue("%s", WQ_UNBOUND | WQ_MEM_RECLAIM, 1,
- i40e_driver_name);
+ i40e_wq = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0, i40e_driver_name);
if (!i40e_wq) {
pr_err("%s: Failed to create workqueue\n", i40e_driver_name);
return -ENOMEM;
--
2.13.3
^ permalink raw reply related
* [net-next 02/14] i40e: Fix for trace found with S4 state
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem; +Cc: Carolyn Wyborny, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170726103123.76743-1-jeffrey.t.kirsher@intel.com>
From: Carolyn Wyborny <carolyn.wyborny@intel.com>
This patch fixes a problem found in systems when entering
S4 state. This patch fixes the problem by ensuring that
the misc vector's IRQ is disabled as well. Without this
patch a stack trace can be seen upon entering S4 state.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
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 | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 2db93d3f6d23..933b8e357ee4 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -12089,7 +12089,10 @@ static int i40e_suspend(struct pci_dev *pdev, pm_message_t state)
wr32(hw, I40E_PFPM_WUFC, (pf->wol_en ? I40E_PFPM_WUFC_MAG_MASK : 0));
i40e_stop_misc_vector(pf);
-
+ if (pf->msix_entries) {
+ synchronize_irq(pf->msix_entries[0].vector);
+ free_irq(pf->msix_entries[0].vector, pf);
+ }
retval = pci_save_state(pdev);
if (retval)
return retval;
@@ -12129,6 +12132,15 @@ static int i40e_resume(struct pci_dev *pdev)
/* handling the reset will rebuild the device state */
if (test_and_clear_bit(__I40E_SUSPENDED, pf->state)) {
clear_bit(__I40E_DOWN, pf->state);
+ if (pf->msix_entries) {
+ err = request_irq(pf->msix_entries[0].vector,
+ i40e_intr, 0, pf->int_name, pf);
+ if (err) {
+ dev_err(&pf->pdev->dev,
+ "request_irq for %s failed: %d\n",
+ pf->int_name, err);
+ }
+ }
i40e_reset_and_rebuild(pf, false, false);
}
--
2.13.3
^ permalink raw reply related
* [net-next 01/14] i40e: fix incorrect variable assignment
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem; +Cc: Gustavo A R Silva, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170726103123.76743-1-jeffrey.t.kirsher@intel.com>
From: Gustavo A R Silva <garsilva@embeddedor.com>
Fix incorrect variable assignment.
Based on line 1511: aq_ret = I40_ERR_PARAM; the correct variable to be
used in this instance is aq_ret instead of ret. Also, variable ret is
updated at line 1602 just before return, so assigning a value to this
variable in this code block is useless.
Addresses-Coverity-ID: 1397693
Signed-off-by: Gustavo A R Silva <garsilva@embeddedor.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index ecbe40ea8ffe..ba327e90f32a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1567,7 +1567,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg)
dev_err(&pf->pdev->dev,
"VF %d requested polling mode: this feature is supported only when the device is running in single function per port (SFP) mode\n",
vf->vf_id);
- ret = I40E_ERR_PARAM;
+ aq_ret = I40E_ERR_PARAM;
goto err;
}
vfres->vf_offload_flags |= VIRTCHNL_VF_OFFLOAD_RX_POLLING;
--
2.13.3
^ permalink raw reply related
* [net-next 00/14][pull request] 40GbE Intel Wired LAN Driver Updates 2017-07-25
From: Jeff Kirsher @ 2017-07-26 10:31 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to i40e and i40evf only.
Gustavo Silva fixes a variable assignment, where the incorrect variable
was being used to store the error parameter.
Carolyn provides a fix for a problem found in systems when entering S4
state, by ensuring that the misc vector's IRQ is disabled as well.
Jake removes the single-threaded restriction on the module workqueue,
which was causing issues with events such as CORER. Does some future
proofing, by changing how the driver displays the UDP tunnel type.
Paul adds a retry in releasing resources if the admin queue times out
during the first attempt to release the resources.
Jesse fixes up references to 32bit timspec, since there are a small set
of errors on 32 bit, so we need to be using the right calls for dealing
with timespec64 variables. Cleaned up code indentation and corrected
an "if" conditional check, as well as making the code flow more clear.
Cast or changed the types to remove warnings for comparing signed and
unsigned types. Adds missing includes in i40evf, which were being used
but were not being directly included.
Daniel Borkmann fixes i40e to fill the XDP prog_id with the id just like
other XDP enabled drivers, so that on dump we can retrieve the attached
program based on the id and dump BPF insns, opcodes, etc back to user
space.
Tushar Dave adds le32_to_cpu while evaluating the hardware descriptor
fields, since they are in little-endian format. Also removed
unnecessary "__packed" to a couple of i40evf structures.
Stefan Assmann fixes an issue when an administratively set MAC was set
and should now be switched back to 00:00:00:00:00:00, the pf_set_mac
flag is not being toggled back to false.
The following are changes since commit 34c8c10a766c8daf42293664f5c9ca5516fa3f41:
Merge branch 'bnxt_en-Fix-kbuild-errors-and-rename-phys_port_name'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Carolyn Wyborny (1):
i40e: Fix for trace found with S4 state
Daniel Borkmann (1):
i40e: report BPF prog id during XDP_QUERY_PROG
Gustavo A R Silva (1):
i40e: fix incorrect variable assignment
Jacob Keller (2):
i40e: remove WQ_UNBOUND and the task limit of our workqueue
i40e: display correct UDP tunnel type name
Jesse Brandeburg (5):
i40e: fix up 32 bit timespec references
i40e: fix odd formatting and indent
i40e/i40evf: make IPv6 ATR code clearer
i40e/i40evf: remove mismatched type warnings
i40evf: add some missing includes
Paul M Stillwell Jr (1):
i40e: Handle admin Q timeout when releasing NVM
Stefan Assmann (1):
i40e: handle setting administratively set MAC address back to zero
Tushar Dave (2):
i40evf: Use le32_to_cpu before evaluating HW desc fields
i40evf: remove unnecessary __packed
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 6 +--
drivers/net/ethernet/intel/i40e/i40e_main.c | 57 ++++++++++++++++------
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 21 +++++++-
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 5 +-
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 18 ++++---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 32 +++++++-----
drivers/net/ethernet/intel/i40evf/i40e_osdep.h | 4 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 6 +--
drivers/net/ethernet/intel/i40evf/i40evf.h | 11 +++++
drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 4 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 14 +++---
11 files changed, 122 insertions(+), 56 deletions(-)
--
2.13.3
^ permalink raw reply
* Re: [PATCH V2 net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission
From: Sergei Shtylyov @ 2017-07-26 10:02 UTC (permalink / raw)
To: Mao Wenan, netdev, davem, ncardwell, ycheng, nanditad,
weiyongjun1, chenweilong, wangkefeng.wang
In-Reply-To: <1501062285-9648-1-git-send-email-maowenan@huawei.com>
On 7/26/2017 12:44 PM, Mao Wenan wrote:
> If there is one TLP probe went out(TLP use the write_queue_tail packet
> as TLP probe, we assume this first TLP probe named A), and this TLP
> probe was not acked by receive side.
>
> Then the transmit side sent the next two packetes out(named B,C), but
> unfortunately these two packets are also not acked by receive side.
>
> And then there is one data packet with ack_seq A arrive
> at transmit side, in tcp_ack() will call tcp_schedule_loss_probe()
> to rearm PTO, the handler tcp_send_loss_probe() is to check
> if(tp->tlp_high_seq) then go to rearm_timer(because there is
> one outstanding TLP named A),
> so the new TLP probe can't be sent out and it needs to rearm the RTO
> timer(timeout is relative to the transmit time of the write queue head).
>
> After that, there is another data packet with ack_seq A is received,
> if the tlp_time_stamp is greater than rto_time_stamp, it will reset the
> TLP timeout, which is before previous RTO timeout, so PTO is rearm and previous
> RTO is cleared. Because there is no retransmission packet was sent or
> no TLP sack receive, tp->tlp_high_seq can't be reset to zero and the next
> TLP probe also can't be sent out, so there is no way(or very long time)
> to retransmit the lost packet.
>
> This fix is to check(tp->tlp_high_seq) in tcp_schedule_loss_probe()
> when TLP PTO is after RTO, It is not needed to reschedule PTO when there
> is one outstanding TLP retransmission, so if the TLP A is lost RTO can
> retransmit lost packet, then tp->tlp_high_seq will be set to 0, and TLP
> will go to the normal work process.
>
> v1->v2
> refine some words of code and patch comments.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> net/ipv4/tcp_output.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 886d874..f85c7ef 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2423,6 +2423,12 @@ bool tcp_schedule_loss_probe(struct sock *sk)
> tlp_time_stamp = tcp_jiffies32 + timeout;
> rto_time_stamp = (u32)inet_csk(sk)->icsk_timeout;
> if ((s32)(tlp_time_stamp - rto_time_stamp) > 0) {
> + /* It is not needed to reschedule PTO when there
> + * is one outstanding TLP retransmission.
> + */
> + if (tp->tlp_high_seq) {
> + return false;
> + }
I have already told you to remove the needless {}... :-/
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH V2 net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission
From: Mao Wenan @ 2017-07-26 9:44 UTC (permalink / raw)
To: netdev, davem, ncardwell, ycheng, nanditad, weiyongjun1,
chenweilong, wangkefeng.wang
If there is one TLP probe went out(TLP use the write_queue_tail packet
as TLP probe, we assume this first TLP probe named A), and this TLP
probe was not acked by receive side.
Then the transmit side sent the next two packetes out(named B,C), but
unfortunately these two packets are also not acked by receive side.
And then there is one data packet with ack_seq A arrive
at transmit side, in tcp_ack() will call tcp_schedule_loss_probe()
to rearm PTO, the handler tcp_send_loss_probe() is to check
if(tp->tlp_high_seq) then go to rearm_timer(because there is
one outstanding TLP named A),
so the new TLP probe can't be sent out and it needs to rearm the RTO
timer(timeout is relative to the transmit time of the write queue head).
After that, there is another data packet with ack_seq A is received,
if the tlp_time_stamp is greater than rto_time_stamp, it will reset the
TLP timeout, which is before previous RTO timeout, so PTO is rearm and previous
RTO is cleared. Because there is no retransmission packet was sent or
no TLP sack receive, tp->tlp_high_seq can't be reset to zero and the next
TLP probe also can't be sent out, so there is no way(or very long time)
to retransmit the lost packet.
This fix is to check(tp->tlp_high_seq) in tcp_schedule_loss_probe()
when TLP PTO is after RTO, It is not needed to reschedule PTO when there
is one outstanding TLP retransmission, so if the TLP A is lost RTO can
retransmit lost packet, then tp->tlp_high_seq will be set to 0, and TLP
will go to the normal work process.
v1->v2
refine some words of code and patch comments.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_output.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 886d874..f85c7ef 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2423,6 +2423,12 @@ bool tcp_schedule_loss_probe(struct sock *sk)
tlp_time_stamp = tcp_jiffies32 + timeout;
rto_time_stamp = (u32)inet_csk(sk)->icsk_timeout;
if ((s32)(tlp_time_stamp - rto_time_stamp) > 0) {
+ /* It is not needed to reschedule PTO when there
+ * is one outstanding TLP retransmission.
+ */
+ if (tp->tlp_high_seq) {
+ return false;
+ }
s32 delta = rto_time_stamp - tcp_jiffies32;
if (delta > 0)
timeout = delta;
--
2.5.0
^ permalink raw reply related
* Re: [PATCH net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission.
From: kbuild test robot @ 2017-07-26 9:35 UTC (permalink / raw)
To: Mao Wenan; +Cc: kbuild-all, netdev, davem, weiyongjun1, chenweilong
In-Reply-To: <1500971735-21852-1-git-send-email-maowenan@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 5995 bytes --]
Hi Mao,
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Mao-Wenan/TLP-Don-t-reschedule-PTO-when-there-s-one-outstanding-TLP-retransmission/20170726-172222
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
net//ipv4/tcp_output.c: In function 'tcp_schedule_loss_probe':
>> net//ipv4/tcp_output.c:2430:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
s32 delta = rto_time_stamp - tcp_jiffies32;
^~~
vim +2430 net//ipv4/tcp_output.c
6ba8a3b1 Nandita Dukkipati 2013-03-11 2374
6ba8a3b1 Nandita Dukkipati 2013-03-11 2375 bool tcp_schedule_loss_probe(struct sock *sk)
6ba8a3b1 Nandita Dukkipati 2013-03-11 2376 {
6ba8a3b1 Nandita Dukkipati 2013-03-11 2377 struct inet_connection_sock *icsk = inet_csk(sk);
6ba8a3b1 Nandita Dukkipati 2013-03-11 2378 struct tcp_sock *tp = tcp_sk(sk);
6ba8a3b1 Nandita Dukkipati 2013-03-11 2379 u32 timeout, tlp_time_stamp, rto_time_stamp;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2380
6ba8a3b1 Nandita Dukkipati 2013-03-11 2381 /* No consecutive loss probes. */
6ba8a3b1 Nandita Dukkipati 2013-03-11 2382 if (WARN_ON(icsk->icsk_pending == ICSK_TIME_LOSS_PROBE)) {
6ba8a3b1 Nandita Dukkipati 2013-03-11 2383 tcp_rearm_rto(sk);
6ba8a3b1 Nandita Dukkipati 2013-03-11 2384 return false;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2385 }
6ba8a3b1 Nandita Dukkipati 2013-03-11 2386 /* Don't do any loss probe on a Fast Open connection before 3WHS
6ba8a3b1 Nandita Dukkipati 2013-03-11 2387 * finishes.
6ba8a3b1 Nandita Dukkipati 2013-03-11 2388 */
f9b99582 Yuchung Cheng 2015-09-18 2389 if (tp->fastopen_rsk)
6ba8a3b1 Nandita Dukkipati 2013-03-11 2390 return false;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2391
6ba8a3b1 Nandita Dukkipati 2013-03-11 2392 /* TLP is only scheduled when next timer event is RTO. */
6ba8a3b1 Nandita Dukkipati 2013-03-11 2393 if (icsk->icsk_pending != ICSK_TIME_RETRANS)
6ba8a3b1 Nandita Dukkipati 2013-03-11 2394 return false;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2395
6ba8a3b1 Nandita Dukkipati 2013-03-11 2396 /* Schedule a loss probe in 2*RTT for SACK capable connections
6ba8a3b1 Nandita Dukkipati 2013-03-11 2397 * in Open state, that are either limited by cwnd or application.
6ba8a3b1 Nandita Dukkipati 2013-03-11 2398 */
bec41a11 Yuchung Cheng 2017-01-12 2399 if ((sysctl_tcp_early_retrans != 3 && sysctl_tcp_early_retrans != 4) ||
bec41a11 Yuchung Cheng 2017-01-12 2400 !tp->packets_out || !tcp_is_sack(tp) ||
bec41a11 Yuchung Cheng 2017-01-12 2401 icsk->icsk_ca_state != TCP_CA_Open)
6ba8a3b1 Nandita Dukkipati 2013-03-11 2402 return false;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2403
6ba8a3b1 Nandita Dukkipati 2013-03-11 2404 if ((tp->snd_cwnd > tcp_packets_in_flight(tp)) &&
6ba8a3b1 Nandita Dukkipati 2013-03-11 2405 tcp_send_head(sk))
6ba8a3b1 Nandita Dukkipati 2013-03-11 2406 return false;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2407
bb4d991a Yuchung Cheng 2017-07-19 2408 /* Probe timeout is 2*rtt. Add minimum RTO to account
f9b99582 Yuchung Cheng 2015-09-18 2409 * for delayed ack when there's one outstanding packet. If no RTT
f9b99582 Yuchung Cheng 2015-09-18 2410 * sample is available then probe after TCP_TIMEOUT_INIT.
6ba8a3b1 Nandita Dukkipati 2013-03-11 2411 */
bb4d991a Yuchung Cheng 2017-07-19 2412 if (tp->srtt_us) {
bb4d991a Yuchung Cheng 2017-07-19 2413 timeout = usecs_to_jiffies(tp->srtt_us >> 2);
6ba8a3b1 Nandita Dukkipati 2013-03-11 2414 if (tp->packets_out == 1)
bb4d991a Yuchung Cheng 2017-07-19 2415 timeout += TCP_RTO_MIN;
bb4d991a Yuchung Cheng 2017-07-19 2416 else
bb4d991a Yuchung Cheng 2017-07-19 2417 timeout += TCP_TIMEOUT_MIN;
bb4d991a Yuchung Cheng 2017-07-19 2418 } else {
bb4d991a Yuchung Cheng 2017-07-19 2419 timeout = TCP_TIMEOUT_INIT;
bb4d991a Yuchung Cheng 2017-07-19 2420 }
6ba8a3b1 Nandita Dukkipati 2013-03-11 2421
6ba8a3b1 Nandita Dukkipati 2013-03-11 2422 /* If RTO is shorter, just schedule TLP in its place. */
ac9517fc Eric Dumazet 2017-05-16 2423 tlp_time_stamp = tcp_jiffies32 + timeout;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2424 rto_time_stamp = (u32)inet_csk(sk)->icsk_timeout;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2425 if ((s32)(tlp_time_stamp - rto_time_stamp) > 0) {
e41572cd Mao Wenan 2017-07-25 2426 /*It is no need to reschedule PTO when there is one outstanding TLP retransmission*/
e41572cd Mao Wenan 2017-07-25 2427 if (tp->tlp_high_seq) {
e41572cd Mao Wenan 2017-07-25 2428 return false;
e41572cd Mao Wenan 2017-07-25 2429 }
ac9517fc Eric Dumazet 2017-05-16 @2430 s32 delta = rto_time_stamp - tcp_jiffies32;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2431 if (delta > 0)
6ba8a3b1 Nandita Dukkipati 2013-03-11 2432 timeout = delta;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2433 }
6ba8a3b1 Nandita Dukkipati 2013-03-11 2434
6ba8a3b1 Nandita Dukkipati 2013-03-11 2435 inet_csk_reset_xmit_timer(sk, ICSK_TIME_LOSS_PROBE, timeout,
6ba8a3b1 Nandita Dukkipati 2013-03-11 2436 TCP_RTO_MAX);
6ba8a3b1 Nandita Dukkipati 2013-03-11 2437 return true;
6ba8a3b1 Nandita Dukkipati 2013-03-11 2438 }
6ba8a3b1 Nandita Dukkipati 2013-03-11 2439
:::::: The code at line 2430 was first introduced by commit
:::::: ac9517fcf310327fa3e3b0d8366e4b11236b1b4b tcp: replace misc tcp_time_stamp to tcp_jiffies32
:::::: TO: Eric Dumazet <edumazet@google.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27789 bytes --]
^ permalink raw reply
* [PATCH net] udp: unbreak build lacking CONFIG_XFRM
From: Paolo Abeni @ 2017-07-26 9:33 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Paul Moore, kbuild-all
In-Reply-To: <201707260327.pfv8cNFg%fengguang.wu@intel.com>
We must use pre-processor conditional block or suitable accessors to
manipulate skb->sp elsewhere builds lacking the CONFIG_XFRM will break.
Fixes: dce4551cb2ad ("udp: preserve head state for IP_CMSG_PASSSEC")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv4/udp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index d243772f6efc..fac7cb9e3b0f 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1786,7 +1786,7 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
* the IP options and the cmsg flags, elsewhere can we clear all
* pending head states while they are hot in the cache
*/
- if (likely(IPCB(skb)->opt.optlen == 0 && !skb->sp))
+ if (likely(IPCB(skb)->opt.optlen == 0 && !skb_sec_path(skb)))
skb_release_head_state(skb);
rc = __udp_enqueue_schedule_skb(sk, skb);
--
2.13.3
^ permalink raw reply related
* Re: [RFC] switchdev: clarify ndo_get_phys_port_name() formats
From: Or Gerlitz @ 2017-07-26 9:23 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jiri Pirko, Linux Netdev List, Or Gerlitz, Michael Chan,
Sathya Perla, Simon Horman, David Miller
In-Reply-To: <20170726011310.5db489ed@cakuba.netronome.com>
On Wed, Jul 26, 2017 at 11:13 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Wed, 26 Jul 2017 07:48:40 +0200, Jiri Pirko wrote:
>> I think it would make sense if the driver would just fill-up a struct in
>> the ndo call and core would generate the string.
> I do like the idea of core generating the string. I have a temptation
> to try to involve devlink in this somehow, since port id and split info
> is already available there. Perhaps that would only overcomplicate
> things.
> The other question is: can we remove the option to generate an arbitrary
> string completely? I think Or and mlx5 folks may object since it would
> mean mlx5 VF repr names would change.
What we have today is the representor driver instance setting the VF index as
the of phys port name and we're telling users to have this sort of udev rule:
SUBSYSTEM=="net", ACTION=="add",
ATTR{phys_switch_id}=="<phys_switch_id>", \ ATTR{phys_port_name}!="",
NAME="$PF_NIC$attr{phys_port_name}"
that has affiliation to the PF where this VF belongs. AFAIK this
model/assumption is now under push to
higher level (open stack), so lets see if/what we want to change here
w.r.t to sriov offloading drivers.
I would opt for an approach where the value returned by the kernel is
the minimal possible and
user-space has flexibility to further orchestrate that with udev
rules. I wasn't fully clear on Jakub's suggestion
which parts must come from the kernel. Do we have any length
limitation for the phys port name?
Or.
^ permalink raw reply
* [PATCHv3 net] ipv6: no need to return rt->dst.error if it is prohibit entry
From: Hangbin Liu @ 2017-07-26 9:20 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Roopa Prabhu, David Ahern, Hangbin Liu
In-Reply-To: <1500562286-14312-1-git-send-email-liuhangbin@gmail.com>
After commit 18c3a61c4264 ("net: ipv6: RTM_GETROUTE: return matched fib
result when requested"). When we get a prohibit ertry, we will return
-EACCES directly.
Before:
+ ip netns exec client ip -6 route get 2003::1
prohibit 2003::1 dev lo table unspec proto kernel src 2001::1 metric
4294967295 error -13
After:
+ ip netns exec server ip -6 route get 2002::1
RTNETLINK answers: Permission denied
Fix this by add prohibit and blk hole check.
At the same time, after commit
2f460933f58e ("ipv6: initialize route null entry in addrconf_init()") and
242d3a49a2a1 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf")
We will init rt6i_idev correctly. So we could dump ip6_null_entry
(unreachable route entry) safely now.
Fixes: 18c3a61c4264 ("net: ipv6: RTM_GETROUTE: return matched fib...")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv6/route.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 4d30c96..b05da74 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3637,13 +3637,12 @@ static int inet6_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,
dst = ip6_route_lookup(net, &fl6, 0);
rt = container_of(dst, struct rt6_info, dst);
- if (rt->dst.error) {
- err = rt->dst.error;
- ip6_rt_put(rt);
- goto errout;
- }
-
- if (rt == net->ipv6.ip6_null_entry) {
+ if (rt->dst.error &&
+#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+ rt != net->ipv6.ip6_prohibit_entry &&
+ rt != net->ipv6.ip6_blk_hole_entry &&
+#endif
+ rt != net->ipv6.ip6_null_entry) {
err = rt->dst.error;
ip6_rt_put(rt);
goto errout;
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net] ipv6: no need to return rt->dst.error if it is not null entry.
From: Hangbin Liu @ 2017-07-26 9:18 UTC (permalink / raw)
To: Cong Wang; +Cc: network dev, Roopa Prabhu, David Ahern
In-Reply-To: <CAM_iQpXvyZR6EZ8s_P6JcKZhHN9t5N+2s4cTqHy0RLdGEMeg0A@mail.gmail.com>
On Tue, Jul 25, 2017 at 10:49:05AM -0700, Cong Wang wrote:
> On Mon, Jul 24, 2017 at 5:08 PM, Hangbin Liu <liuhangbin@gmail.com> wrote:
> > But what we want in inet6_rtm_getroute() and rt6_dump_route() is to
> > get/dump the route info. So we should get the info even it's unreachable or
> > prohibit.
>
> If you want to dump prohibit/blackhole entry, then you have to check
> for null_entry, and rt->dst.error check is still needed because we
I could not reproduce the NULL rt6i_idev issue after you route init fix, So
I think it's also safe to dump null_entry now. There is a v3 patch. After
the patch, we could dump unreachable route info like:
+ ip netns exec client ip -6 route get 2003::1
unreachable 2003::1 dev lo table unspec proto kernel metric 4294967295 error -101
> could return error on other normal entries too, IOW, your v2 is correct
> if dumping prohibit/blackhole is expected.
Would you hlep review the v3 patch? I prepare not touch the check in
function rt6_dump_route() now.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH net-next 10/10] bnxt_en: add support for port_attr_get and and get_phys_port_name
From: Or Gerlitz @ 2017-07-26 9:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Michael Chan, David Miller, Linux Netdev List, Sathya Perla,
Jiri Pirko
In-Reply-To: <20170724214521.75bf5857@cakuba.netronome.com>
On Tue, Jul 25, 2017 at 7:45 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> This is even worse. We already have two naming conventions in the
> kernel, mlx5 uses "%d" for legacy reasons. nfp uses pf%dvf%d for vfs,
To make it clear, in mlx5 this is used only for the offloads/switchdev mode
and not for legacy mode, in the latter mode, a VF probed to VM doesn't
have host side representation so there's no where to use that.
Or.
> which is better for two reasons: (a) it works with multi-PF devices;
> (b) naming something representor from switchdev perspective is
> pointless, you're not calling the external port netdev a physical port
> representor, even though it has the exact same relation to the port as
> with VFs (i.e. egressing traffic on the netdev will cause the switch
> to send to the given port).
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnxt_en: define sriov_lock unconditionally
From: Arnd Bergmann @ 2017-07-26 9:05 UTC (permalink / raw)
To: Michael Chan
Cc: David S. Miller, Sathya Perla, Somnath Kotur, Deepak Khungar,
Netdev, open list
In-Reply-To: <CACKFLimnZx7v9jV7v27XMP62BWG577D8=zkTijQYa6Pi1Ct7yA@mail.gmail.com>
On Tue, Jul 25, 2017 at 6:36 PM, Michael Chan <michael.chan@broadcom.com> wrote:
> On Tue, Jul 25, 2017 at 8:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> The sriov_lock is used to serialize the sriov code with the vfr code.
>> However, when SRIOV is disabled, the lock is not there at all, leading
>> to a build error:
>>
>> drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c: In function 'bnxt_dl_eswitch_mode_set':
>> drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c:410:16: error: 'struct bnxt' has no member named 'sriov_lock'
>>
>> We can either provide the mutex in this configuration, too, or
>> disable both SRIOV and VFR together. This implements the first
>> approach, since it seems like a reasonable configuration for
>> guest kernels to have, and the extra lock will be harmless when
>> there is no contention.
>>
>> Fixes: 4ab0c6a8ffd7 ("bnxt_en: add support to enable VF-representors")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Sathya already sent 3 patches to fix some of these issues. But I need
> to rework one of his patch and resend.
Ok, thanks. I just ran into one more issue, and don't know if that's included
as well. If not, please also add the patch below (or fold it into the one
that adds the switchdev dependency to the ethernet driver):
8<----------
Subject: [PATCH] RDMA/bnxt_re: add NET_SWITCHDEV dependency
The rdma side of BNXT enables the ethernet driver and has a list
of its dependencies. However, the ethernet driver now also depends
on NET_SWITCHDEV, so we have to add that dependency for both:
warning: (INFINIBAND_BNXT_RE) selects BNXT which has unmet direct
dependencies (NETDEVICES && ETHERNET && NET_VENDOR_BROADCOM && PCI &&
MAY_USE_DEVLINK && NET_SWITCHDEV)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/infiniband/hw/bnxt_re/Kconfig
b/drivers/infiniband/hw/bnxt_re/Kconfig
index 19982a4a9bba..0c296f00e74f 100644
--- a/drivers/infiniband/hw/bnxt_re/Kconfig
+++ b/drivers/infiniband/hw/bnxt_re/Kconfig
@@ -1,6 +1,7 @@
config INFINIBAND_BNXT_RE
tristate "Broadcom Netxtreme HCA support"
depends on ETHERNET && NETDEVICES && PCI && INET && DCB
+ depends on NET_SWITCHDEV
select NET_VENDOR_BROADCOM
select BNXT
---help---
^ permalink raw reply related
* Re: TC-pedit man page examples error
From: Phil Sutter @ 2017-07-26 8:43 UTC (permalink / raw)
To: Tyler Bautista; +Cc: netdev
In-Reply-To: <CAEPezq43wKM1ivHAUu6pFoGqz9+nCJ1FT9xQV702S_BCQvropA@mail.gmail.com>
Hi Tyler,
On Tue, Jul 25, 2017 at 08:33:40AM -0700, Tyler Bautista wrote:
> To whom it may concern,
> I recently attempted to use simple tc action pedit commands on the man
> page and I ran into some errors. The following is some information
> about my version of iproute and my machine:
> ----------------------------
> the following is my iproute package information
>
> Loaded plugins: fastestmirror, langpacks
> iproute-3.10.0-74.el7.x86_64
This mailing list is for upstream issues only. Can you reproduce the
problem with vanilla iproute2?
You are using RHEL7's iproute package, which has a number of known
issues in pedit action:
https://bugzilla.redhat.com/show_bug.cgi?id=1322406
These are planned to be resolved for RHEL7.5, not sure when it will land
in CentOS.
Cheers, Phil
^ permalink raw reply
* Re: After a while of system running no incoming UDP any more?
From: Paolo Abeni @ 2017-07-26 8:33 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
In-Reply-To: <20170726081047.562anntu5uhwirze@torres.zugschlus.de>
On Wed, 2017-07-26 at 10:10 +0200, Marc Haber wrote:
> On Tue, Jul 25, 2017 at 02:17:52PM +0200, Paolo Abeni wrote:
> > On Tue, 2017-07-25 at 13:57 +0200, Marc Haber wrote:
> > > On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> > > > Once that a system enter the buggy status, do the packets reach the
> > > > relevant socket's queue?
> > > >
> > > > ss -u
> > >
> > > That one only shows table headers on an unaffected system in normal
> > > operation, right?
> >
> > This one shows the current lenght of the socket receive queue (Recv-Q,
> > the first column). If the packets land into the skbuff (and the user
> > space reader for some reason is not woken up) such value will grow over
> > time.
>
> Only that there is no value:
> [4/4992]mh@swivel:~ $ ss -u
> Recv-Q Send-Q Local Address:Port Peer Address:Port
> [5/4992]mh@swivel:~ $
>
> (is that the intended behavior on a system thiat is not affected by the
> issue?)
That means there are no open UDP connected sockets in the system at the
moment you run ss -u. I forgot to specify you must add also the '-a'
command line option to the 'ss' tool to show all udp sockets regardless
theis state:
ss -ua
Anyway this issue looks quite similar to:
https://bugzilla.kernel.org/show_bug.cgi?id=196469
Which contains some more information. I suggest to follow-up on such
bz.
Cheers,
Paolo
^ permalink raw reply
* [PATCH net] sctp: fix the check for _sctp_walk_params and _sctp_walk_errors
From: Xin Long @ 2017-07-26 8:24 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Neil Horman, glider
Commit b1f5bfc27a19 ("sctp: don't dereference ptr before leaving
_sctp_walk_{params, errors}()") tried to fix the issue that it
may overstep the chunk end for _sctp_walk_{params, errors} with
'chunk_end > offset(length) + sizeof(length)'.
But it introduced a side effect: When processing INIT, it verifies
the chunks with 'param.v == chunk_end' after iterating all params
by sctp_walk_params(). With the check 'chunk_end > offset(length)
+ sizeof(length)', it would return when the last param is not yet
accessed. Because the last param usually is fwdtsn supported param
whose size is 4 and 'chunk_end == offset(length) + sizeof(length)'
This is a badly issue even causing sctp couldn't process 4-shakes.
Client would always get abort when connecting to server, due to
the failure of INIT chunk verification on server.
The patch is to use 'chunk_end <= offset(length) + sizeof(length)'
instead of 'chunk_end < offset(length) + sizeof(length)' for both
_sctp_walk_params and _sctp_walk_errors.
Fixes: b1f5bfc27a19 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/sctp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 980807d..45fd4c6 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -469,7 +469,7 @@ _sctp_walk_params((pos), (chunk), ntohs((chunk)->chunk_hdr.length), member)
#define _sctp_walk_params(pos, chunk, end, member)\
for (pos.v = chunk->member;\
- (pos.v + offsetof(struct sctp_paramhdr, length) + sizeof(pos.p->length) <\
+ (pos.v + offsetof(struct sctp_paramhdr, length) + sizeof(pos.p->length) <=\
(void *)chunk + end) &&\
pos.v <= (void *)chunk + end - ntohs(pos.p->length) &&\
ntohs(pos.p->length) >= sizeof(struct sctp_paramhdr);\
@@ -481,7 +481,7 @@ _sctp_walk_errors((err), (chunk_hdr), ntohs((chunk_hdr)->length))
#define _sctp_walk_errors(err, chunk_hdr, end)\
for (err = (sctp_errhdr_t *)((void *)chunk_hdr + \
sizeof(struct sctp_chunkhdr));\
- ((void *)err + offsetof(sctp_errhdr_t, length) + sizeof(err->length) <\
+ ((void *)err + offsetof(sctp_errhdr_t, length) + sizeof(err->length) <=\
(void *)chunk_hdr + end) &&\
(void *)err <= (void *)chunk_hdr + end - ntohs(err->length) &&\
ntohs(err->length) >= sizeof(sctp_errhdr_t); \
--
2.1.0
^ permalink raw reply related
* Re: [RFC] switchdev: clarify ndo_get_phys_port_name() formats
From: Jakub Kicinski @ 2017-07-26 8:13 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, Or Gerlitz, Michael Chan, Sathya Perla, simon.horman,
davem
In-Reply-To: <20170726054840.GA1845@nanopsycho>
On Wed, 26 Jul 2017 07:48:40 +0200, Jiri Pirko wrote:
> Tue, Jul 25, 2017 at 07:13:44AM CEST, jakub.kicinski@netronome.com wrote:
> >We are still in position where we can suggest uniform naming
> >convention for ndo_get_phys_port_name(). switchdev.txt file
> >already contained a suggestion of how to name external ports.
> >Since the use of switchdev for SR-IOV NIC's eswitches is growing,
> >establish a format for ports of those devices as well.
> >
> >Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> >---
> > Documentation/networking/switchdev.txt | 14 +++++++++++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> >diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
> >index 3e7b946dea27..7c4b6025fb4b 100644
> >--- a/Documentation/networking/switchdev.txt
> >+++ b/Documentation/networking/switchdev.txt
> >@@ -119,9 +119,17 @@ into 4 10G ports, resulting in 4 port netdevs, the device can give a unique
> > SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="<phys_switch_id>", \
> > ATTR{phys_port_name}!="", NAME="swX$attr{phys_port_name}"
> >
> >-Suggested naming convention is "swXpYsZ", where X is the switch name or ID, Y
> >-is the port name or ID, and Z is the sub-port name or ID. For example, sw1p1s0
> >-would be sub-port 0 on port 1 on switch 1.
> >+Suggested formats of the port name returned by ndo_get_phys_port_name are:
> >+ - pA for external ports;
> >+ - pAsB for split external ports;
> >+ - pfC for PF ports (so called PF representors);
> >+ - pfCvfD for VF ports (so called VF representors).
>
> I think it would make sense if the driver would just fill-up a struct in
> the ndo call and core would generate the string.
I do like the idea of core generating the string. I have a temptation
to try to involve devlink in this somehow, since port id and split info
is already available there. Perhaps that would only overcomplicate
things.
The other question is: can we remove the option to generate an arbitrary
string completely? I think Or and mlx5 folks may object since it would
mean mlx5 VF repr names would change.
^ permalink raw reply
* Re: After a while of system running no incoming UDP any more?
From: Marc Haber @ 2017-07-26 8:10 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev
In-Reply-To: <1500985072.13149.4.camel@redhat.com>
On Tue, Jul 25, 2017 at 02:17:52PM +0200, Paolo Abeni wrote:
> On Tue, 2017-07-25 at 13:57 +0200, Marc Haber wrote:
> > On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> > > Once that a system enter the buggy status, do the packets reach the
> > > relevant socket's queue?
> > >
> > > ss -u
> >
> > That one only shows table headers on an unaffected system in normal
> > operation, right?
>
> This one shows the current lenght of the socket receive queue (Recv-Q,
> the first column). If the packets land into the skbuff (and the user
> space reader for some reason is not woken up) such value will grow over
> time.
Only that there is no value:
[4/4992]mh@swivel:~ $ ss -u
Recv-Q Send-Q Local Address:Port Peer Address:Port
[5/4992]mh@swivel:~ $
(is that the intended behavior on a system thiat is not affected by the
issue?)
> > > nstat |grep -e Udp -e Ip
> > >
> > > will help checking that.
> >
> > An unaffected system will show UdpInDatagrams, right?
> >
> > But where is the connection to the relevant socket's queue?
>
> If the socket queue lenght (as reported above) does not increase,
> IP/UDP stats could give an hint of where and why the packets stop
> traversing the network stack.
We'll see. Still waiting for the phenomenon to show up again.
> Beyond that, you can try using perf probes or kprobe/systemtap to [try
> to] track the relevant packets inside the kernel.
That's way beyond my kernel foo, I'm afraid.
Thanks for helping, I'll report back.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* [PATCH net] Revert "vhost: cache used event for better performance"
From: Jason Wang @ 2017-07-26 8:03 UTC (permalink / raw)
To: mst, jasowang; +Cc: virtualization, kvm, netdev, linux-kernel
This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
was reported to break vhost_net. We want to cache used event and use
it to check for notification. We try to valid cached used event by
checking whether or not it was ahead of new, but this is not correct
all the time, it could be stale and there's no way to know about this.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.c | 28 ++++++----------------------
drivers/vhost/vhost.h | 3 ---
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e4613a3..9cb3f72 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -308,7 +308,6 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->avail = NULL;
vq->used = NULL;
vq->last_avail_idx = 0;
- vq->last_used_event = 0;
vq->avail_idx = 0;
vq->last_used_idx = 0;
vq->signalled_used = 0;
@@ -1402,7 +1401,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp)
r = -EINVAL;
break;
}
- vq->last_avail_idx = vq->last_used_event = s.num;
+ vq->last_avail_idx = s.num;
/* Forget the cached index value. */
vq->avail_idx = vq->last_avail_idx;
break;
@@ -2241,6 +2240,10 @@ static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
__u16 old, new;
__virtio16 event;
bool v;
+ /* Flush out used index updates. This is paired
+ * with the barrier that the Guest executes when enabling
+ * interrupts. */
+ smp_mb();
if (vhost_has_feature(vq, VIRTIO_F_NOTIFY_ON_EMPTY) &&
unlikely(vq->avail_idx == vq->last_avail_idx))
@@ -2248,10 +2251,6 @@ static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
__virtio16 flags;
- /* Flush out used index updates. This is paired
- * with the barrier that the Guest executes when enabling
- * interrupts. */
- smp_mb();
if (vhost_get_avail(vq, flags, &vq->avail->flags)) {
vq_err(vq, "Failed to get flags");
return true;
@@ -2266,26 +2265,11 @@ static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
if (unlikely(!v))
return true;
- /* We're sure if the following conditions are met, there's no
- * need to notify guest:
- * 1) cached used event is ahead of new
- * 2) old to new updating does not cross cached used event. */
- if (vring_need_event(vq->last_used_event, new + vq->num, new) &&
- !vring_need_event(vq->last_used_event, new, old))
- return false;
-
- /* Flush out used index updates. This is paired
- * with the barrier that the Guest executes when enabling
- * interrupts. */
- smp_mb();
-
if (vhost_get_avail(vq, event, vhost_used_event(vq))) {
vq_err(vq, "Failed to get used event idx");
return true;
}
- vq->last_used_event = vhost16_to_cpu(vq, event);
-
- return vring_need_event(vq->last_used_event, new, old);
+ return vring_need_event(vhost16_to_cpu(vq, event), new, old);
}
/* This actually signals the guest, using eventfd. */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index f720958..bb7c29b 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -115,9 +115,6 @@ struct vhost_virtqueue {
/* Last index we used. */
u16 last_used_idx;
- /* Last used evet we've seen */
- u16 last_used_event;
-
/* Used flags */
u16 used_flags;
--
2.7.4
^ permalink raw reply related
* [PATCH] hamradio: dmascc: avoid -Wformat-overflow warning
From: Arnd Bergmann @ 2017-07-26 7:55 UTC (permalink / raw)
To: Joerg Reuter
Cc: Arnd Bergmann, David Howells, linux-hams, netdev, linux-kernel
gcc warns that the device name might overflow:
drivers/net/hamradio/dmascc.c: In function 'dmascc_init':
drivers/net/hamradio/dmascc.c:584:22: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
sprintf(dev->name, "dmascc%i", 2 * n + i);
drivers/net/hamradio/dmascc.c:584:3: note: 'sprintf' output between 8 and 17 bytes into a destination of size 16
sprintf(dev->name, "dmascc%i", 2 * n + i);
>From the static data in this file, I can tell that the index is
strictly limited to 16, so it won't overflow. This simply changes
the sprintf() to snprintf(), which is a good idea in general,
and shuts up this warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I ran into this for the first time today on linux-next randconfig
builds, but couldn't find an obvious commit that introduced it.
I guess it's just a very rare randconfig warning, so this can go
into net-next rather than net fixes.
---
drivers/net/hamradio/dmascc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index dec6b76bc0fb..cde41200f40a 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -581,7 +581,7 @@ static int __init setup_adapter(int card_base, int type, int n)
priv->param.dma = -1;
INIT_WORK(&priv->rx_work, rx_bh);
dev->ml_priv = priv;
- sprintf(dev->name, "dmascc%i", 2 * n + i);
+ snprintf(dev->name, sizeof(dev->name), "dmascc%i", 2 * n + i);
dev->base_addr = card_base;
dev->irq = irq;
dev->netdev_ops = &scc_netdev_ops;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH v2 00/10] Constify attribute_group structures
From: Arvind Yadav @ 2017-07-26 6:36 UTC (permalink / raw)
To: Kalle Valo; +Cc: sgruszka, netdev, linux-kernel, linux-wireless
In-Reply-To: <87fudkiskz.fsf@codeaurora.org>
Hi Kalle,
On Tuesday 25 July 2017 06:25 PM, Kalle Valo wrote:
> Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
>
>> attribute_groups are not supposed to change at runtime. So mark the
>> non-const structs as const.
>>
>> Arvind Yadav (10):
>> [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures.
>> [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures.
>> [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures.
>> [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures.
>> [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures.
>> [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures.
>> [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures.
>> [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures.
>> [PATCH v2 09/10] net: bonding: constify attribute_group structures.
>> [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures.
> Via which tree were you planning to push these? Is it ok if I take the
> wireless patches to my tree?
>
I have push these changes to linux-next branch. you can take this to
your branch.
~arvind
^ 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