* RE: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets
From: Dexuan Cui @ 2016-04-14 3:56 UTC (permalink / raw)
To: David Miller
Cc: olaf@aepfle.de, gregkh@linuxfoundation.org, jasowang@redhat.com,
linux-kernel@vger.kernel.org, joe@perches.com,
netdev@vger.kernel.org, apw@canonical.com,
devel@linuxdriverproject.org, Haiyang Zhang
In-Reply-To: <20160413.223027.844777521863481943.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, April 14, 2016 10:30
> To: Dexuan Cui <decui@microsoft.com>
> Cc: gregkh@linuxfoundation.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com; cavery@redhat.com; KY
> Srinivasan <kys@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>;
> joe@perches.com; vkuznets@redhat.com
> Subject: Re: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets
>
> From: Dexuan Cui <decui@microsoft.com>
> Date: Thu, 7 Apr 2016 18:36:51 -0700
>
> > +struct vmpipe_proto_header {
> > + u32 pkt_type;
> > + u32 data_size;
> > +} __packed;
>
> There is no reason to specify __packed here.
>
> The types are strongly sized to word aligned quantities.
> No holes are possible in this structure, nor is any padding
> possible either.
>
> Do not ever slap __packed onto protocol or HW defined structures,
> simply just define them properly with proper types and explicit
> padding when necessary.
Hi David,
Thank you very much for taking a look at the patch!
I'll remove all the 3 __packed usages in my patch.
> > + struct {
> > + struct vmpipe_proto_header hdr;
> > + char buf[HVSOCK_SND_BUF_SZ];
> > + } __packed send;
>
> And so on, and so forth..
I'll remove __packed and use u8 to replace the 'char' here.
> I'm really disappointed that I couldn't even get one hunk into this
> patch submission without finding a major problem.
David,
Could you please point out more issues in the patch?
I'm definitely happy to fix them. :-)
> I expect this patch to take several more iterations before I can even
> come close to applying it. So please set your expectations properly,
> and also it seems like nobody else wants to even review this stuff
> either. It is you who needs to find a way to change all of this, not
> me.
A few people took a look at the early versions of the patch and did
give me good suggestions on the interface APIs with VMBus and
some coding style issues, especially Vitaly from Redhat.
Cathy from Redhat was also looking into the patch recently and
gave me some good feedbacks.
I'll try to invite more people to review the patch.
And, I'm updating the patch to address some issues:
1) the feature is only properly supported on Windows 10/2016
build 14290 and later, so I'm going to not enable the feature on
old hosts.
2) there is actually some mechanism we can use to simplify
hvsock_open_connection() and help to better support
hvsock_shutdown().
Thanks,
-- Dexuan
^ permalink raw reply
* [net 2/2] fm10k: fix multi-bit VLAN update requests from VF
From: Jeff Kirsher @ 2016-04-14 3:47 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1460605632-112945-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The VF uses a multi-bit update request to clear unused VLANs whenever it
resets. However, an accident in a previous refector broke multi-bit
updates for VFs, due to misreading a comment in fm10k_vf.c and
attempting to reduce code duplication. The problem occurs because
a multi-bit request has a non-zero length, and the PF would simply drop
any request with the upper 16 bits set.
We can't simply remove the check of the upper 16 bits and the call to
fm10k_iov_select vid, because this would remove the checks for default
VID and for ensuring no other VLANs can be enabled except pf_vid when it
has been set. To resolve that issue, this revision uses the
iov_select_vid when we have a single-bit update, and denies any
multi-bit update when the VLAN was administratively set by the PF. This
should be ok since the PF properly updates VLAN_TABLE when it assigns
the PF vid. This ensures that requests to add or remove the PF vid work
as expected, but a rogue VF could not use the multi-bit update as
a loophole to attempt receiving traffic on other VLANs.
Reported-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 30 +++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
index 62ccebc..8cf943d 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pf.c
@@ -1223,18 +1223,32 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 **results,
if (err)
return err;
- /* verify upper 16 bits are zero */
- if (vid >> 16)
- return FM10K_ERR_PARAM;
-
set = !(vid & FM10K_VLAN_CLEAR);
vid &= ~FM10K_VLAN_CLEAR;
- err = fm10k_iov_select_vid(vf_info, (u16)vid);
- if (err < 0)
- return err;
+ /* if the length field has been set, this is a multi-bit
+ * update request. For multi-bit requests, simply disallow
+ * them when the pf_vid has been set. In this case, the PF
+ * should have already cleared the VLAN_TABLE, and if we
+ * allowed them, it could allow a rogue VF to receive traffic
+ * on a VLAN it was not assigned. In the single-bit case, we
+ * need to modify requests for VLAN 0 to use the default PF or
+ * SW vid when assigned.
+ */
- vid = err;
+ if (vid >> 16) {
+ /* prevent multi-bit requests when PF has
+ * administratively set the VLAN for this VF
+ */
+ if (vf_info->pf_vid)
+ return FM10K_ERR_PARAM;
+ } else {
+ err = fm10k_iov_select_vid(vf_info, (u16)vid);
+ if (err < 0)
+ return err;
+
+ vid = err;
+ }
/* update VSI info for VF in regards to VLAN table */
err = hw->mac.ops.update_vlan(hw, vid, vf_info->vsi, set);
--
2.5.5
^ permalink raw reply related
* [net 1/2] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Jeff Kirsher @ 2016-04-14 3:47 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1460605632-112945-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <aduyck@mirantis.com>
This patch addresses a bug introduced based on my interpretation of the
XL710 datasheet. Specifically section 8.4.1 states that "A single transmit
packet may span up to 8 buffers (up to 8 data descriptors per packet
including both the header and payload buffers)." It then later goes on to
say that each segment for a TSO obeys the previous rule, however it then
refers to TSO header and the segment payload buffers.
I believe the actual limit for fragments with TSO and a skbuff that has
payload data in the header portion of the buffer is actually only 7
fragments as the skb->data portion counts as 2 buffers, one for the TSO
header, and one for a segment payload buffer.
Fixes: 2d37490b82af ("i40e/i40evf: Rewrite logic for 8 descriptor per packet check")
Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 10 ++++--
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40evf/i40e_txrx.h | 10 ++++--
4 files changed, 62 insertions(+), 56 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 084d0ab..6a49b7a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2594,35 +2594,34 @@ int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
}
/**
- * __i40e_chk_linearize - Check if there are more than 8 fragments per packet
+ * __i40e_chk_linearize - Check if there are more than 8 buffers per packet
* @skb: send buffer
*
- * Note: Our HW can't scatter-gather more than 8 fragments to build
- * a packet on the wire and so we need to figure out the cases where we
- * need to linearize the skb.
+ * Note: Our HW can't DMA more than 8 buffers to build a packet on the wire
+ * and so we need to figure out the cases where we need to linearize the skb.
+ *
+ * For TSO we need to count the TSO header and segment payload separately.
+ * As such we need to check cases where we have 7 fragments or more as we
+ * can potentially require 9 DMA transactions, 1 for the TSO header, 1 for
+ * the segment payload in the first descriptor, and another 7 for the
+ * fragments.
**/
bool __i40e_chk_linearize(struct sk_buff *skb)
{
const struct skb_frag_struct *frag, *stale;
- int gso_size, nr_frags, sum;
-
- /* check to see if TSO is enabled, if so we may get a repreive */
- gso_size = skb_shinfo(skb)->gso_size;
- if (unlikely(!gso_size))
- return true;
+ int nr_frags, sum;
- /* no need to check if number of frags is less than 8 */
+ /* no need to check if number of frags is less than 7 */
nr_frags = skb_shinfo(skb)->nr_frags;
- if (nr_frags < I40E_MAX_BUFFER_TXD)
+ if (nr_frags < (I40E_MAX_BUFFER_TXD - 1))
return false;
/* We need to walk through the list and validate that each group
* of 6 fragments totals at least gso_size. However we don't need
- * to perform such validation on the first or last 6 since the first
- * 6 cannot inherit any data from a descriptor before them, and the
- * last 6 cannot inherit any data from a descriptor after them.
+ * to perform such validation on the last 6 since the last 6 cannot
+ * inherit any data from a descriptor after them.
*/
- nr_frags -= I40E_MAX_BUFFER_TXD - 1;
+ nr_frags -= I40E_MAX_BUFFER_TXD - 2;
frag = &skb_shinfo(skb)->frags[0];
/* Initialize size to the negative value of gso_size minus 1. We
@@ -2631,21 +2630,21 @@ bool __i40e_chk_linearize(struct sk_buff *skb)
* descriptors for a single transmit as the header and previous
* fragment are already consuming 2 descriptors.
*/
- sum = 1 - gso_size;
+ sum = 1 - skb_shinfo(skb)->gso_size;
- /* Add size of frags 1 through 5 to create our initial sum */
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
+ /* Add size of frags 0 through 4 to create our initial sum */
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
stale = &skb_shinfo(skb)->frags[0];
for (;;) {
- sum += skb_frag_size(++frag);
+ sum += skb_frag_size(frag++);
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
@@ -2655,7 +2654,7 @@ bool __i40e_chk_linearize(struct sk_buff *skb)
if (!--nr_frags)
break;
- sum -= skb_frag_size(++stale);
+ sum -= skb_frag_size(stale++);
}
return false;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.h b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
index cdd5dc0..a9bd705 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
@@ -413,10 +413,14 @@ static inline int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
**/
static inline bool i40e_chk_linearize(struct sk_buff *skb, int count)
{
- /* we can only support up to 8 data buffers for a single send */
- if (likely(count <= I40E_MAX_BUFFER_TXD))
+ /* Both TSO and single send will work if count is less than 8 */
+ if (likely(count < I40E_MAX_BUFFER_TXD))
return false;
- return __i40e_chk_linearize(skb);
+ if (skb_is_gso(skb))
+ return __i40e_chk_linearize(skb);
+
+ /* we can support up to 8 data buffers for a single send */
+ return count != I40E_MAX_BUFFER_TXD;
}
#endif /* _I40E_TXRX_H_ */
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index ebcc25c..cea97da 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1796,35 +1796,34 @@ static void i40e_create_tx_ctx(struct i40e_ring *tx_ring,
}
/**
- * __i40evf_chk_linearize - Check if there are more than 8 fragments per packet
+ * __i40evf_chk_linearize - Check if there are more than 8 buffers per packet
* @skb: send buffer
*
- * Note: Our HW can't scatter-gather more than 8 fragments to build
- * a packet on the wire and so we need to figure out the cases where we
- * need to linearize the skb.
+ * Note: Our HW can't DMA more than 8 buffers to build a packet on the wire
+ * and so we need to figure out the cases where we need to linearize the skb.
+ *
+ * For TSO we need to count the TSO header and segment payload separately.
+ * As such we need to check cases where we have 7 fragments or more as we
+ * can potentially require 9 DMA transactions, 1 for the TSO header, 1 for
+ * the segment payload in the first descriptor, and another 7 for the
+ * fragments.
**/
bool __i40evf_chk_linearize(struct sk_buff *skb)
{
const struct skb_frag_struct *frag, *stale;
- int gso_size, nr_frags, sum;
-
- /* check to see if TSO is enabled, if so we may get a repreive */
- gso_size = skb_shinfo(skb)->gso_size;
- if (unlikely(!gso_size))
- return true;
+ int nr_frags, sum;
- /* no need to check if number of frags is less than 8 */
+ /* no need to check if number of frags is less than 7 */
nr_frags = skb_shinfo(skb)->nr_frags;
- if (nr_frags < I40E_MAX_BUFFER_TXD)
+ if (nr_frags < (I40E_MAX_BUFFER_TXD - 1))
return false;
/* We need to walk through the list and validate that each group
* of 6 fragments totals at least gso_size. However we don't need
- * to perform such validation on the first or last 6 since the first
- * 6 cannot inherit any data from a descriptor before them, and the
- * last 6 cannot inherit any data from a descriptor after them.
+ * to perform such validation on the last 6 since the last 6 cannot
+ * inherit any data from a descriptor after them.
*/
- nr_frags -= I40E_MAX_BUFFER_TXD - 1;
+ nr_frags -= I40E_MAX_BUFFER_TXD - 2;
frag = &skb_shinfo(skb)->frags[0];
/* Initialize size to the negative value of gso_size minus 1. We
@@ -1833,21 +1832,21 @@ bool __i40evf_chk_linearize(struct sk_buff *skb)
* descriptors for a single transmit as the header and previous
* fragment are already consuming 2 descriptors.
*/
- sum = 1 - gso_size;
+ sum = 1 - skb_shinfo(skb)->gso_size;
- /* Add size of frags 1 through 5 to create our initial sum */
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
- sum += skb_frag_size(++frag);
+ /* Add size of frags 0 through 4 to create our initial sum */
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
+ sum += skb_frag_size(frag++);
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
stale = &skb_shinfo(skb)->frags[0];
for (;;) {
- sum += skb_frag_size(++frag);
+ sum += skb_frag_size(frag++);
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
@@ -1857,7 +1856,7 @@ bool __i40evf_chk_linearize(struct sk_buff *skb)
if (!--nr_frags)
break;
- sum -= skb_frag_size(++stale);
+ sum -= skb_frag_size(stale++);
}
return false;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.h b/drivers/net/ethernet/intel/i40evf/i40e_txrx.h
index c1dd8c5..0429553 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.h
@@ -395,10 +395,14 @@ static inline int i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size)
**/
static inline bool i40e_chk_linearize(struct sk_buff *skb, int count)
{
- /* we can only support up to 8 data buffers for a single send */
- if (likely(count <= I40E_MAX_BUFFER_TXD))
+ /* Both TSO and single send will work if count is less than 8 */
+ if (likely(count < I40E_MAX_BUFFER_TXD))
return false;
- return __i40evf_chk_linearize(skb);
+ if (skb_is_gso(skb))
+ return __i40evf_chk_linearize(skb);
+
+ /* we can support up to 8 data buffers for a single send */
+ return count != I40E_MAX_BUFFER_TXD;
}
#endif /* _I40E_TXRX_H_ */
--
2.5.5
^ permalink raw reply related
* [net 0/2][pull request] Intel Wired LAN Driver Updates 2016-04-13
From: Jeff Kirsher @ 2016-04-14 3:47 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene, john.ronciak
This series contains updates to i40e, i40evf and fm10k.
Alex fixes a bug introduced earlier based on his interpretation of the
XL710 datasheet. The actual limit for fragments with TSO and a skbuff
that has payload data in the header portion of the buffer is actually
only 7 fragments and the skb-data portion counts as 2 buffers, one for
the TSO header, and the one for a segment payload buffer.
Jacob fixes a bug where in a previous refactor of the code broke
multi-bit updates for VFs. The problem occurs because a multi-bit
request has a non-zero length, and the PF would simply drop any
request with the upper 16 bits set.
The following are changes since commit a6d37131c02f15463daa00e2f1da6824e8e00de2:
net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue master
Alexander Duyck (1):
i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per
packet
Jacob Keller (1):
fm10k: fix multi-bit VLAN update requests from VF
drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 30 +++++++++++-----
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 10 ++++--
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 49 +++++++++++++--------------
drivers/net/ethernet/intel/i40evf/i40e_txrx.h | 10 ++++--
5 files changed, 84 insertions(+), 64 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: [RESEND PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode
From: Weidong Wang @ 2016-04-14 3:42 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, netdev, linux-kernel, andrew
In-Reply-To: <570E92ED.9020603@gmail.com>
On 2016/4/14 2:41, Florian Fainelli wrote:
> On 13/04/16 04:59, Weidong Wang wrote:
>> When tested the PHY SGMII Loopback,:
>> 1.set the LOOPBACK bit,
>> 2.set the autoneg to AUTONEG_DISABLE, it calls the
>> genphy_setup_forced which will clear the bit.
>>
>> So just keep the LOOPBACK bit while setup forced mode.
>
> Humm, it makes sense why we want this one, but maybe we want other bits
> to be preserved too, like MII_ISOLATE for instance?
>
I will add the MII_ISOLATE as well.
> Or maybe we should have a separate way to put the PHY into loopback mode
> which is deterministic and takes care of forcing the link at the same time?
>
I test with the loopback mode, and the link status is undeterminable.
>>
>> Signed-off-by: Weidong Wang <wangweidong1@huawei.com>
>> ---
>> drivers/net/phy/phy_device.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index e551f3a..8da4b80 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1124,7 +1124,9 @@ static int genphy_config_advert(struct phy_device *phydev)
>> int genphy_setup_forced(struct phy_device *phydev)
>> {
>> int ctl = 0;
>> + int val = phy_read(phydev, MII_BMCR);
>>
>> + ctl |= val & BMCR_LOOPBACK;
>> phydev->pause = 0;
>> phydev->asym_pause = 0;
>>
>> -- 2.7.0
>>
>
>
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: use __napi_schedule_irqoff()
From: David Miller @ 2016-04-14 3:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: f.fainelli, netdev, pgynther, opendmb
In-Reply-To: <1460179856.6473.482.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 08 Apr 2016 22:30:56 -0700
> From: Florian Fainelli <f.fainelli@gmail.com>
>
> bcmgenet_isr1() and bcmgenet_isr0() run in hard irq context,
> we do not need to block irq again.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: use napi_complete_done()
From: David Miller @ 2016-04-14 3:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, pgynther, f.fainelli
In-Reply-To: <1460178400.6473.469.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 08 Apr 2016 22:06:40 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> By using napi_complete_done(), we allow fine tuning
> of /sys/class/net/ethX/gro_flush_timeout for higher GRO aggregation
> efficiency for a Gbit NIC.
>
> Check commit 24d2e4a50737 ("tg3: use napi_complete_done()") for details.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [net-next][PATCH 0/2] RDS: couple of fixes for 4.6
From: David Miller @ 2016-04-14 3:36 UTC (permalink / raw)
To: santosh.shilimkar; +Cc: netdev, linux-kernel
In-Reply-To: <1460154400-14546-1-git-send-email-santosh.shilimkar@oracle.com>
From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Date: Fri, 8 Apr 2016 15:26:38 -0700
> Patches are also available at below git tree.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_4.6/net-next/rds-fixes
"Bug fixes for 4.6" do not get targetted at the net-next tree, that's
for 4.7 development.
^ permalink raw reply
* Re: [PATCH v4] route: do not cache fib route info on local routes with oif
From: David Miller @ 2016-04-14 3:34 UTC (permalink / raw)
To: chris.friesen; +Cc: ja, netdev
In-Reply-To: <570820DA.2070007@windriver.com>
From: Chris Friesen <chris.friesen@windriver.com>
Date: Fri, 8 Apr 2016 15:21:30 -0600
> For local routes that require a particular output interface we do not want
> to cache the result. Caching the result causes incorrect behaviour when
> there are multiple source addresses on the interface. The end result
> being that if the intended recipient is waiting on that interface for the
> packet he won't receive it because it will be delivered on the loopback
> interface and the IP_PKTINFO ipi_ifindex will be set to the loopback
> interface as well.
>
> This can be tested by running a program such as "dhcp_release" which
> attempts to inject a packet on a particular interface so that it is
> received by another program on the same board. The receiving process
> should see an IP_PKTINFO ipi_ifndex value of the source interface
> (e.g., eth1) instead of the loopback interface (e.g., lo). The packet
> will still appear on the loopback interface in tcpdump but the important
> aspect is that the CMSG info is correct.
>
> Sample dhcp_release command line:
>
> dhcp_release eth1 192.168.204.222 02:11:33:22:44:66
>
> Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
> Signed off-by: Chris Friesen <chris.friesen@windriver.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] [v4] net: emac: emac gigabit ethernet controller driver
From: kbuild test robot @ 2016-04-14 3:27 UTC (permalink / raw)
To: Timur Tabi
Cc: kbuild-all-JC7UmRfGjtg, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
sdharia-sgV2jX0FEOL9JmXXK+q4OQ, Shanker Donthineni,
Greg Kroah-Hartman, vikrams-sgV2jX0FEOL9JmXXK+q4OQ,
cov-sgV2jX0FEOL9JmXXK+q4OQ, gavidov-sgV2jX0FEOL9JmXXK+q4OQ,
Rob Herring, andrew-g2DYL2Zd6BY,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Mark Langsdorf,
Jon Masters, Andy Gross, David S. Miller
In-Reply-To: <1460570393-19838-1-git-send-email-timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]
Hi Gilad,
[auto build test WARNING on net/master]
[also build test WARNING on v4.6-rc3 next-20160413]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Timur-Tabi/net-emac-emac-gigabit-ethernet-controller-driver/20160414-020345
config: ia64-allyesconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
In file included from arch/ia64/include/asm/smp.h:20:0,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from include/linux/textsearch.h:8,
from include/linux/skbuff.h:30,
from include/linux/tcp.h:21,
from drivers/net/ethernet/qualcomm/emac/emac-mac.c:16:
drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
arch/ia64/include/asm/io.h:395:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define writel(v,a) __writel((v), (a))
^
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c:1076:2: note: in expansion of macro 'writel'
writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
^
vim +/writel +1076 drivers/net/ethernet/qualcomm/emac/emac-mac.c
1060 return ret;
1061
1062 ret = request_irq(irq->irq, emac_isr, 0, EMAC_MAC_IRQ_RES, irq);
1063 if (ret) {
1064 netdev_err(adpt->netdev,
1065 "error:%d on request_irq(%d:%s flags:0)\n", ret,
1066 irq->irq, EMAC_MAC_IRQ_RES);
1067 emac_sgmii_down(adpt);
1068 return ret;
1069 }
1070
1071 emac_mac_rx_descs_refill(adpt, &adpt->rx_q);
1072
1073 napi_enable(&adpt->rx_q.napi);
1074
1075 /* enable mac irq */
> 1076 writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
1077 writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
1078
1079 netif_start_queue(netdev);
1080 clear_bit(EMAC_STATUS_DOWN, &adpt->status);
1081
1082 /* check link status */
1083 set_bit(EMAC_STATUS_TASK_LSC_REQ, &adpt->status);
1084 adpt->link_chk_timeout = jiffies + EMAC_TRY_LINK_TIMEOUT;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 45884 bytes --]
^ permalink raw reply
* Re: [PATCH] net: ipv6: Do not keep linklocal and loopback addresses
From: David Ahern @ 2016-04-14 3:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160413.230002.1718430497071707670.davem@davemloft.net>
On 4/13/16 9:00 PM, David Miller wrote:
>
> Applied, but two things:
>
> Please do not put an empty line between the Fixes: and other tags.
> All tags are equal and should be placed together as an unsegmented
> unit.
ack.
> Second, please be really sure this is the final set of semantics
> you want. If we flap again on this after 4.6-final goes out the
> door, I will be very unpleased to say the least.
(thunderbird underlined unpleased in that sentence as if you reached
through the screen and and put a red marker on it)
With this patch we only retain user configured addresses which is the
goal of the v1 patch posted back in January 2015. This is active in our
code base so getting a lot of testing and exposure to other users. It is
active on my server and VMs as well. With all of the VRF testing it is
getting a workout. i.e, not much more I can do to ensure this is solid
before 4.6 is final. I know this patch has been been ported and is in
use by others; I would encourage them to share if they see problems or
want adjustments as well.
^ permalink raw reply
* [PATCH V3 29/29] ethernet: use parity8 in broadcom/tg3.c
From: zengzhaoxiu @ 2016-04-14 3:12 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, Siva Reddy Kallam, Prashant Sreedharan,
Michael Chan, netdev
In-Reply-To: <1460601525-3822-1-git-send-email-zengzhaoxiu@163.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/broadcom/tg3.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 3010080..802a429 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
err = -EIO;
for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
- u8 hw8 = hweight8(data[i]);
-
- if ((hw8 & 0x1) && parity[i])
- goto out;
- else if (!(hw8 & 0x1) && !parity[i])
+ if (parity8(data[i]) == !!parity[i])
goto out;
}
err = 0;
--
2.5.0
^ permalink raw reply related
* [PATCH V3 23/29] ethernet: use parity8 in sun/niu.c
From: zengzhaoxiu @ 2016-04-14 3:11 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, Joonsoo Kim, Vlastimil Babka, David S. Miller,
Andrew Morton, Jiri Pirko, netdev
In-Reply-To: <1460601525-3822-1-git-send-email-zengzhaoxiu@163.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/sun/niu.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 9cc4564..8c344ef 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -2742,18 +2742,12 @@ static int niu_set_alt_mac_rdc_table(struct niu *np, int idx,
static u64 vlan_entry_set_parity(u64 reg_val)
{
- u64 port01_mask;
- u64 port23_mask;
-
- port01_mask = 0x00ff;
- port23_mask = 0xff00;
-
- if (hweight64(reg_val & port01_mask) & 1)
+ if (parity8(reg_val))
reg_val |= ENET_VLAN_TBL_PARITY0;
else
reg_val &= ~ENET_VLAN_TBL_PARITY0;
- if (hweight64(reg_val & port23_mask) & 1)
+ if (parity8((unsigned int)reg_val >> 8))
reg_val |= ENET_VLAN_TBL_PARITY1;
else
reg_val &= ~ENET_VLAN_TBL_PARITY1;
--
2.5.0
^ permalink raw reply related
* [PATCH V3 10/29] sunrpc: use parity8
From: zengzhaoxiu @ 2016-04-14 3:08 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, J. Bruce Fields, Jeff Layton, Trond Myklebust,
Anna Schumaker, David S. Miller, Herbert Xu, linux-nfs, netdev
In-Reply-To: <1460601525-3822-1-git-send-email-zengzhaoxiu@163.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
net/sunrpc/auth_gss/gss_krb5_keys.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 8701331..c41b389 100644
--- a/net/sunrpc/auth_gss/gss_krb5_keys.c
+++ b/net/sunrpc/auth_gss/gss_krb5_keys.c
@@ -243,16 +243,12 @@ err_return:
return ret;
}
-#define smask(step) ((1<<step)-1)
-#define pstep(x, step) (((x)&smask(step))^(((x)>>step)&smask(step)))
-#define parity_char(x) pstep(pstep(pstep((x), 4), 2), 1)
-
static void mit_des_fixup_key_parity(u8 key[8])
{
int i;
for (i = 0; i < 8; i++) {
key[i] &= 0xfe;
- key[i] |= 1^parity_char(key[i]);
+ key[i] |= !parity8(key[i]);
}
}
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v3 0/2] sctp: delay calls to sk_data_ready() as much as possible
From: David Miller @ 2016-04-14 3:05 UTC (permalink / raw)
To: marcelo.leitner
Cc: netdev, vyasevich, nhorman, linux-sctp, David.Laight, jkbs
In-Reply-To: <cover.1460144373.git.marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Fri, 8 Apr 2016 16:41:26 -0300
> 1st patch is a preparation for the 2nd. The idea is to not call
> ->sk_data_ready() for every data chunk processed while processing
> packets but only once before releasing the socket.
>
> v2: patchset re-checked, small changelog fixes
> v3: on patch 2, make use of local vars to make it more readable
Applied to net-next, but isn't this reduced overhead coming at the
expense of latency? What if that lower latency is important to the
application and/or consumer?
^ permalink raw reply
* Re: [PATCH] mISDN: Fixing missing validation in base_sock_bind()
From: David Miller @ 2016-04-14 3:01 UTC (permalink / raw)
To: ed; +Cc: linux-kernel, netdev, isdn
In-Reply-To: <1460142971-16459-1-git-send-email-ed@abdsec.com>
From: Emrah Demir <ed@abdsec.com>
Date: Fri, 8 Apr 2016 22:16:11 +0300
> From: Emrah Demir <ed@abdsec.com>
>
> Add validation code into mISDN/socket.c
>
> Signed-off-by: Emrah Demir <ed@abdsec.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ipv6: Do not keep linklocal and loopback addresses
From: David Miller @ 2016-04-14 3:00 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1460142081-16675-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Fri, 8 Apr 2016 12:01:21 -0700
> f1705ec197e7 added the option to retain user configured addresses on an
> admin down. A comment to one of the later revisions suggested using the
> IFA_F_PERMANENT flag rather than adding a user_managed boolean to the
> ifaddr struct. A side effect of this change is that link local and
> loopback addresses are also retained which is not part of the objective
> of f1705ec197e7. Add check to drop those addresses.
>
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied, but two things:
Please do not put an empty line between the Fixes: and other tags.
All tags are equal and should be placed together as an unsegmented
unit.
Second, please be really sure this is the final set of semantics
you want. If we flap again on this after 4.6-final goes out the
door, I will be very unpleased to say the least.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] fix two more udp pull header issues
From: Willem de Bruijn @ 2016-04-14 2:57 UTC (permalink / raw)
To: David Miller
Cc: Network Development, Tom Herbert, Sam Kumar, Willem de Bruijn
In-Reply-To: <20160413.222554.1942915187151383805.davem@davemloft.net>
On Wed, Apr 13, 2016 at 10:25 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Thu, 7 Apr 2016 18:12:57 -0400
>
>> Follow up patches to the fixes to RxRPC and SunRPC. A scan of the
>> code showed two other interfaces that expect UDP packets to have
>> a udphdr when queued: read packet length with ioctl SIOCINQ and
>> receive payload checksum with socket option IP_CHECKSUM.
>
> As we are seeing, lots of places depend upon the old way of queueing
> up UDP frames. :-/
Yes, I greatly underestimated that. I should have done a much more
thorough scan before submitting. Hopefully we've caught them all now.
> Applied, thanks for mopping all of this up.
Apologies for breaking it in the first place!
^ permalink raw reply
* Re: [PATCH] drivers/net/ethernet/jme.c: Deinline jme_reset_mac_processor, save 2816 bytes
From: David Miller @ 2016-04-14 2:57 UTC (permalink / raw)
To: dvlasenk; +Cc: linux-kernel, netdev
In-Reply-To: <1460140787-12610-1-git-send-email-dvlasenk@redhat.com>
From: Denys Vlasenko <dvlasenk@redhat.com>
Date: Fri, 8 Apr 2016 20:39:47 +0200
> This function compiles to 895 bytes of machine code.
>
> Clearly, this isn't a time-critical function.
> For one, it has a number of udelay(1) calls.
>
> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
No x.c file should be using inline anyways, applied to net-next,
thanks a lot!
^ permalink raw reply
* Re: [PATCH net-next v3] packet: uses kfree_skb() for errors.
From: David Miller @ 2016-04-14 2:56 UTC (permalink / raw)
To: weongyo.linux; +Cc: netdev, willemb
In-Reply-To: <1460132748-23561-1-git-send-email-weongyo.linux@gmail.com>
From: Weongyo Jeong <weongyo.linux@gmail.com>
Date: Fri, 8 Apr 2016 09:25:48 -0700
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 1ecfa71..4e054bb 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -2042,6 +2042,7 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
> u8 *skb_head = skb->data;
> int skb_len = skb->len;
> unsigned int snaplen, res;
> + bool err = false;
>
> if (skb->pkt_type == PACKET_LOOPBACK)
> goto drop;
It is non-canonical to use a variable named 'err' as a boolean.
Instead, all programmers expect a variable named 'err' to be an
integer type and to hold an error code.
Therefore please use a more appropriate name for this variable.
Name it in a way which describes the exact important condition
which is true or false.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: stmmac: GMAC4.xx: Fix TX descriptor preparation
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: alexandre.torgue; +Cc: netdev, peppe.cavallaro, dan.carpenter, kernel-janitors
In-Reply-To: <1460107083-25577-1-git-send-email-alexandre.torgue@st.com>
From: Alexandre TORGUE <alexandre.torgue@st.com>
Date: Fri, 8 Apr 2016 11:18:03 +0200
> On GMAC4.xx each descriptor contains 2 buffers of 16KB (each).
> Initially, those 2 buffers was filled in dwmac4_rd_prepare_tx_desc but
> it is actually not needed. Indeed, stmmac driver supports frame up to
> 9000 bytes (jumbo). So only one buffer is needed.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH RESEND] net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: wsa; +Cc: netdev, linux-renesas-soc, sergei.shtylyov
In-Reply-To: <1460114922-4148-1-git-send-email-wsa@the-dreams.de>
From: Wolfram Sang <wsa@the-dreams.de>
Date: Fri, 8 Apr 2016 13:28:42 +0200
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> The clk API may return 0 on clk_get_rate, so we should check the result before
> using it as a divisor.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sock: tigthen lockdep checks for sock_owned_by_user
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-cifs-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1460121087-2859-1-git-send-email-hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
From: Hannes Frederic Sowa <hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
Date: Fri, 8 Apr 2016 15:11:27 +0200
> sock_owned_by_user should not be used without socket lock held. It seems
> to be a common practice to check .owned before lock reclassification, so
> provide a little help to abstract this check away.
>
> Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Hannes Frederic Sowa <hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6, token: allow for clearing the current device token
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: daniel; +Cc: hannes, robbat2, netdev
In-Reply-To: <307b4d32099f606d0fbe0ce9fecd3a039b796361.1460123261.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 8 Apr 2016 15:55:00 +0200
> The original tokenized iid support implemented via f53adae4eae5 ("net: ipv6:
> add tokenized interface identifier support") didn't allow for clearing a
> device token as it was intended that this addressing mode was the only one
> active for globally scoped IPv6 addresses. Later we relaxed that restriction
> via 617fe29d45bd ("net: ipv6: only invalidate previously tokenized addresses"),
> and we should also allow for clearing tokens as there's no good reason why
> it shouldn't be allowed.
>
> Fixes: 617fe29d45bd ("net: ipv6: only invalidate previously tokenized addresses")
> Reported-by: Robin H. Johnson <robbat2@gentoo.org>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] [linux-next] Doc: networking: Fix typo in dsa
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: standby24x7; +Cc: linux-kernel, corbet, linux-doc, netdev
In-Reply-To: <1460127625-6956-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Sat, 9 Apr 2016 00:00:25 +0900
> This patch fix typos in Documentation/networking/dsa.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Applied.
^ 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