* [PATCH net 1/7] net: hns: fix a bug for cycle index
From: Yisen Zhuang @ 2016-03-24 11:08 UTC (permalink / raw)
To: davem
Cc: yankejian, huangdaode, salil.mehta, lisheng011, lipeng321,
liguozhu, xieqianqian, netdev, linux-kernel, linuxarm
In-Reply-To: <1458817686-159708-1-git-send-email-Yisen.Zhuang@huawei.com>
From: Qianqian Xie <xieqianqian@huawei.com>
The cycle index should be varied while the variable j is a fixed value.
The patch will fix this bug.
Signed-off-by: Qianqian Xie <xieqianqian@huawei.com>
Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 5c1ac9b..5978a5c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2219,17 +2219,17 @@ void hns_dsaf_get_regs(struct dsaf_device *ddev, u32 port, void *data)
/* dsaf onode registers */
for (i = 0; i < DSAF_XOD_NUM; i++) {
p[311 + i] = dsaf_read_dev(ddev,
- DSAF_XOD_ETS_TSA_TC0_TC3_CFG_0_REG + j * 0x90);
+ DSAF_XOD_ETS_TSA_TC0_TC3_CFG_0_REG + i * 0x90);
p[319 + i] = dsaf_read_dev(ddev,
- DSAF_XOD_ETS_TSA_TC4_TC7_CFG_0_REG + j * 0x90);
+ DSAF_XOD_ETS_TSA_TC4_TC7_CFG_0_REG + i * 0x90);
p[327 + i] = dsaf_read_dev(ddev,
- DSAF_XOD_ETS_BW_TC0_TC3_CFG_0_REG + j * 0x90);
+ DSAF_XOD_ETS_BW_TC0_TC3_CFG_0_REG + i * 0x90);
p[335 + i] = dsaf_read_dev(ddev,
- DSAF_XOD_ETS_BW_TC4_TC7_CFG_0_REG + j * 0x90);
+ DSAF_XOD_ETS_BW_TC4_TC7_CFG_0_REG + i * 0x90);
p[343 + i] = dsaf_read_dev(ddev,
- DSAF_XOD_ETS_BW_OFFSET_CFG_0_REG + j * 0x90);
+ DSAF_XOD_ETS_BW_OFFSET_CFG_0_REG + i * 0x90);
p[351 + i] = dsaf_read_dev(ddev,
- DSAF_XOD_ETS_TOKEN_CFG_0_REG + j * 0x90);
+ DSAF_XOD_ETS_TOKEN_CFG_0_REG + i * 0x90);
}
p[359] = dsaf_read_dev(ddev, DSAF_XOD_PFS_CFG_0_0_REG + port * 0x90);
--
1.9.1
^ permalink raw reply related
* [PATCH] stmmac: Fix phy without MDIO subnode
From: John Keeping @ 2016-03-24 10:56 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: Gabriel Fernandez, netdev, linux-kernel, John Keeping
Since commit 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found'
regression") we no longer allocate mdio_bus_data unless there is a MDIO
subnode. This breaks the ethernet on the Radxa Rock2 (using
rk3288-rock2-square.dts) which does not have an MDIO subnode.
That commit was correct that the phy_bus_name test is unhelpful since we
allocate "plat" in the same function and never set phy_bus_name so let's
just drop the test which restores the previous behaviour.
Fixes: 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression")
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index dcbd2a1..e0fa060 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -189,7 +189,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
- if ((plat->phy_node && !of_phy_is_fixed_link(np)) || !plat->mdio_node)
+ if ((plat->phy_node && !of_phy_is_fixed_link(np)))
plat->mdio_bus_data = NULL;
else
plat->mdio_bus_data =
--
2.7.0.226.gfe986fe
^ permalink raw reply related
* [PATCH net 3/7] net: hns: bug fix for return values
From: Yisen Zhuang @ 2016-03-24 11:08 UTC (permalink / raw)
To: davem
Cc: yankejian, huangdaode, salil.mehta, lisheng011, lipeng321,
liguozhu, xieqianqian, netdev, linux-kernel, linuxarm
In-Reply-To: <1458817686-159708-1-git-send-email-Yisen.Zhuang@huawei.com>
From: Qianqian Xie <xieqianqian@huawei.com>
The return values in the first two functions mdiobus_write()
are ignored. The patch will fix it.
Signed-off-by: Qianqian Xie <xieqianqian@huawei.com>
Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
index 9c3ba65..0e7da3f 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -1013,8 +1013,8 @@ int hns_phy_led_set(struct net_device *netdev, int value)
struct phy_device *phy_dev = priv->phy;
retval = phy_write(phy_dev, HNS_PHY_PAGE_REG, HNS_PHY_PAGE_LED);
- retval = phy_write(phy_dev, HNS_LED_FC_REG, value);
- retval = phy_write(phy_dev, HNS_PHY_PAGE_REG, HNS_PHY_PAGE_COPPER);
+ retval |= phy_write(phy_dev, HNS_LED_FC_REG, value);
+ retval |= phy_write(phy_dev, HNS_PHY_PAGE_REG, HNS_PHY_PAGE_COPPER);
if (retval) {
netdev_err(netdev, "mdiobus_write fail !\n");
return retval;
--
1.9.1
^ permalink raw reply related
* [PATCH net 2/7] net: hns: optimizate fmt of snprintf()
From: Yisen Zhuang @ 2016-03-24 11:08 UTC (permalink / raw)
To: davem
Cc: yankejian, huangdaode, salil.mehta, lisheng011, lipeng321,
liguozhu, xieqianqian, netdev, linux-kernel, linuxarm
In-Reply-To: <1458817686-159708-1-git-send-email-Yisen.Zhuang@huawei.com>
From: Qianqian Xie <xieqianqian@huawei.com>
It misses string format in function snprintf(), as below:
snprintf(buff, ETH_GSTRING_LEN, g_gmac_stats_string[i].desc);
It needs to add "%s" to fix it as below:
snprintf(buff, ETH_GSTRING_LEN, "%s", g_gmac_stats_string[i].desc);
Signed-off-by: Qianqian Xie <xieqianqian@huawei.com>
Signed-off-by: Kejian Yan <yankejian@huawei.com>
Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 6e2b76e..44abb08 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -664,7 +664,8 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data)
return;
for (i = 0; i < ARRAY_SIZE(g_gmac_stats_string); i++) {
- snprintf(buff, ETH_GSTRING_LEN, g_gmac_stats_string[i].desc);
+ snprintf(buff, ETH_GSTRING_LEN, "%s",
+ g_gmac_stats_string[i].desc);
buff = buff + ETH_GSTRING_LEN;
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH net 4/7] net: hns: remove useless variable assignment and comment
From: Yisen Zhuang @ 2016-03-24 11:08 UTC (permalink / raw)
To: davem
Cc: yankejian, huangdaode, salil.mehta, lisheng011, lipeng321,
liguozhu, xieqianqian, netdev, linux-kernel, linuxarm
In-Reply-To: <1458817686-159708-1-git-send-email-Yisen.Zhuang@huawei.com>
From: Qianqian Xie <xieqianqian@huawei.com>
The variable head in hns_nic_tx_fini_pro has read a value, but it is
obviously no use. The patch will fix it.
And the comment is nothing to do with the routine, so it has to be removed
Signed-off-by: Qianqian Xie <xieqianqian@huawei.com>
Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 71aa37b..f0c9a41 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -913,10 +913,7 @@ static int hns_nic_tx_poll_one(struct hns_nic_ring_data *ring_data,
static void hns_nic_tx_fini_pro(struct hns_nic_ring_data *ring_data)
{
struct hnae_ring *ring = ring_data->ring;
- int head = ring->next_to_clean;
-
- /* for hardware bug fixed */
- head = readl_relaxed(ring->io_base + RCB_REG_HEAD);
+ int head = readl_relaxed(ring->io_base + RCB_REG_HEAD);
if (head != ring->next_to_clean) {
ring_data->ring->q->handle->dev->ops->toggle_ring_irq(
--
1.9.1
^ permalink raw reply related
* [PATCH net 0/7] net: hns: fix some bugs in HNS driver
From: Yisen Zhuang @ 2016-03-24 11:07 UTC (permalink / raw)
To: davem
Cc: yankejian, huangdaode, salil.mehta, lisheng011, lipeng321,
liguozhu, xieqianqian, netdev, linux-kernel, linuxarm
Here are some bug fixed patches for HNS driver.
They are:
>from Kejian, fix for the warning of passing zero to 'PTR_ERR'
>from qianqian, four fixes for inappropriate operation in hns driver
>from Sheng, one fix for optimization of irq proccess in hns driver, and
one fix for hilink status for hns driver.
For more details, please see individual patches.
MBR.
Kejian Yan (1):
net: hns: fix warning of passing zero to 'PTR_ERR'
Qianqian Xie (4):
net: hns: fix a bug for cycle index
net: hns: optimizate fmt of snprintf()
net: hns: bug fix for return values
net: hns: remove useless variable assignment and comment
Sheng Li (2):
net: hns: optimizate irq proccess for HNS V2
net: hns: bug fix about getting hilink status for HNS v2
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 3 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 12 +++----
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 40 ++++++++++++----------
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 2 ++
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 16 ++++-----
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 4 +--
6 files changed, 41 insertions(+), 36 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: call attention to review
From: oulijun @ 2016-03-24 10:30 UTC (permalink / raw)
To: pandit.parav-Re5JQEeQqe8AvxtiuMwx3w, jiri-rHqAuBHg3fBzbRFIqnYvSA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
hch-wEGCiKHe2LqWVfeAwA7xHQ, dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <20160324061743.GB11949-2ukJVAZIZ/Y@public.gmane.org>
On 2016/3/24 14:17, Leon Romanovsky wrote:
> On Thu, Mar 24, 2016 at 01:50:30PM +0800, oulijun wrote:
>> Hi,
>> I am Lijun Ou. I have sent the PATCH v4 of HiSilicon RoCE driver at March 22, 2016.
>> if you are convenient, please help to review. Welcome to give your reviewing.
>
> Hi Lijun,
> Please read whole document which describes how to submit patches [1]
> and especially section 9, but please don't limit yourself to that
> section only. The whole document is relevant to your patches.
>
> [1] https://www.kernel.org/doc/Documentation/SubmittingPatches
>
>>
>> thanks
>> Lijun Ou
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
Sorry, please forgive my impatience. I will pay attention to the whole document afterwards.
I am sorry for my rashness again.
thanks
Lijun Ou
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: Request 'reset' GPIO only for AT8030 PHY
From: Sebastian Frias @ 2016-03-24 10:10 UTC (permalink / raw)
To: Sergei Shtylyov, Uwe Kleine-König
Cc: Daniel Mack, David S. Miller, netdev, lkml, mason,
Florian Fainelli, Mans Rullgard, Fabio Estevam,
Martin Blumenstingl, Linus Walleij
In-Reply-To: <56F3B9A2.9060801@laposte.net>
Hi Sergei,
>> What I don't understand is why the link_change_notify() method ptr is
>> populated for all 3 supported chips while only being needed on 8030...
>
> You are right.
I made the patch but I'm unsure about it because it could conflict with
yours.
I mean, I think you submitted a patch to change the GPIO handling on the
link_change_notify() function, right?
Well, if we only register the callback for the AT8030, then there is no
more need for the callback to check the PHY ID.
However, if I change that, the whole block moves as I remove one
indentation level (the one required by the PHY ID check).
Any suggestions on how to create a patch that won't conflict? I probably
need to use a tree that already has your patch applied.
Best regards,
Sebastian
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: Request 'reset' GPIO only for AT8030 PHY
From: Sebastian Frias @ 2016-03-24 9:55 UTC (permalink / raw)
To: Sergei Shtylyov, Uwe Kleine-König
Cc: Daniel Mack, David S. Miller, netdev, lkml, mason,
Florian Fainelli, Mans Rullgard, Fabio Estevam,
Martin Blumenstingl, Linus Walleij
In-Reply-To: <56F2F189.1030003@cogentembedded.com>
Hi Sergei,
On 03/23/2016 08:42 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 03/23/2016 01:49 PM, Sebastian Frias wrote:
>
>> This removes the dependency on GPIOLIB for non faulty PHYs.
>>
>> Indeed, without this patch, if GPIOLIB is not selected
>> devm_gpiod_get_optional() will return -ENOSYS and the driver probe
>> call will fail, regardless of the actual PHY hardware.
>>
>> Out of the 3 PHYs supported by this driver (AT8030, AT8031, AT8035),
>> only AT8030 presents the issues that commit 13a56b449325 ("net: phy:
>> at803x: Add support for hardware reset") attempts to work-around by
>> using a 'reset' GPIO line.
>>
>> Hence, only AT8030 should depend on GPIOLIB operating properly.
>>
>> Fixes: 13a56b449325 ("net: phy: at803x: Add support for hardware reset")
>>
>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
> [...]
>
> What I don't understand is why the link_change_notify() method ptr is
> populated for all 3 supported chips while only being needed on 8030...
You are right.
I had commented on that here
https://marc.info/?l=linux-netdev&m=145856582932498&w=2
<quote>
Furthermore, I think we should not even register the
"link_change_notify" callback when dealing with AT803x PHYs that do not
require the hack.
Another solution (considering the callback is statically registered in
the "phy_driver" structs for all AT803x PHYs) would be for the callback
to disable itself.
</quote>
I was waiting for comments from the original implementor.
However, I guess we can remove them as well.
I will make another patch.
Best regards,
Sebastian
^ permalink raw reply
* Re: [RFCv2 2/3] ath10k: report per-station tx/rate rates to mac80211
From: Michal Kazior @ 2016-03-24 7:49 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: Felix Fietkau, Emmanuel Grumbach, Network Development,
linux-wireless, ath10k@lists.infradead.org, codel, make-wifi-fast,
Johannes Berg, Tim Shepard
In-Reply-To: <20160324071923.GB23410@atheros-ThinkPad-T61>
On 24 March 2016 at 08:19, Mohammed Shafi Shajakhan
<mohammed@codeaurora.org> wrote:
> Hi Michal,
>
> On Wed, Mar 16, 2016 at 11:17:57AM +0100, Michal Kazior wrote:
>> The rate control is offloaded by firmware so it's
>> challanging to provide expected throughput value
>> for given station.
>>
>> This approach is naive as it reports last tx rate
>> used for given station as provided by firmware
>> stat event.
>>
>> This should be sufficient for airtime estimation
>> used for fq-codel-in-mac80211 tx scheduling
>> purposes now.
>>
>> This patch uses a very hacky way to get the stats.
>> This is sufficient for proof-of-concept but must
>> be cleaned up properly eventually.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>> ---
>> drivers/net/wireless/ath/ath10k/core.h | 5 +++
>> drivers/net/wireless/ath/ath10k/debug.c | 61 +++++++++++++++++++++++++++++----
>> drivers/net/wireless/ath/ath10k/mac.c | 26 ++++++++------
>> drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
>> 4 files changed, 76 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>> index 23ba03fb7a5f..3f76669d44cf 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -331,6 +331,9 @@ struct ath10k_sta {
>> /* protected by conf_mutex */
>> bool aggr_mode;
>> u64 rx_duration;
>> +
>> + u32 tx_rate_kbps;
>> + u32 rx_rate_kbps;
>> #endif
>> };
>>
>> @@ -372,6 +375,8 @@ struct ath10k_vif {
>> s8 def_wep_key_idx;
>>
>> u16 tx_seq_no;
>> + u32 tx_rate_kbps;
>> + u32 rx_rate_kbps;
>>
>> union {
>> struct {
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>> index 076d29b53ddf..cc7ebf04ae00 100644
>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> @@ -316,6 +316,58 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
>> spin_unlock_bh(&ar->data_lock);
>> }
>>
>> +static void ath10k_mac_update_txrx_rate_iter(void *data,
>> + u8 *mac,
>> + struct ieee80211_vif *vif)
>> +{
>> + struct ath10k_fw_stats_peer *peer = data;
>> + struct ath10k_vif *arvif;
>> +
>> + if (memcmp(vif->addr, peer->peer_macaddr, ETH_ALEN))
>> + return;
>> +
>> + arvif = (void *)vif->drv_priv;
>> + arvif->tx_rate_kbps = peer->peer_tx_rate;
>> + arvif->rx_rate_kbps = peer->peer_rx_rate;
>> +}
>> +
>> +static void ath10k_mac_update_txrx_rate(struct ath10k *ar,
>> + struct ath10k_fw_stats *stats)
>> +{
>> + struct ieee80211_hw *hw = ar->hw;
>> + struct ath10k_fw_stats_peer *peer;
>> + struct ath10k_sta *arsta;
>> + struct ieee80211_sta *sta;
>> + const u8 *localaddr = NULL;
>> +
>> + rcu_read_lock();
>> +
>> + list_for_each_entry(peer, &stats->peers, list) {
>> + /* This doesn't account for multiple STA connected on different
>> + * vifs. Unfortunately there's no way to derive that from the available
>> + * information.
>> + */
>> + sta = ieee80211_find_sta_by_ifaddr(hw,
>> + peer->peer_macaddr,
>> + localaddr);
>> + if (!sta) {
>> + /* This tries to update multicast rates */
>> + ieee80211_iterate_active_interfaces_atomic(
>> + hw,
>> + IEEE80211_IFACE_ITER_NORMAL,
>> + ath10k_mac_update_txrx_rate_iter,
>> + peer);
>> + continue;
>> + }
>> +
>> + arsta = (void *)sta->drv_priv;
>> + arsta->tx_rate_kbps = peer->peer_tx_rate;
>> + arsta->rx_rate_kbps = peer->peer_rx_rate;
>> + }
>> +
>> + rcu_read_unlock();
>> +}
>> +
>> void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>> {
>> struct ath10k_fw_stats stats = {};
>> @@ -335,6 +387,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>> goto free;
>> }
>>
>> + ath10k_mac_update_txrx_rate(ar, &stats);
>> +
>> /* Stat data may exceed htc-wmi buffer limit. In such case firmware
>> * splits the stats data and delivers it in a ping-pong fashion of
>> * request cmd-update event.
>> @@ -351,13 +405,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>> if (peer_stats_svc)
>> ath10k_sta_update_rx_duration(ar, &stats.peers);
>>
>> - if (ar->debug.fw_stats_done) {
>> - if (!peer_stats_svc)
>> - ath10k_warn(ar, "received unsolicited stats update event\n");
>> -
>> - goto free;
>> - }
>> -
>
> [shafi] As you had suggested previously, should we completely clean up this ping
> - pong response approach for f/w stats, (or) this should be retained to support
> backward compatibility and also for supporting ping - pong response when user
> cats for fw-stats (via debugfs) (i did see in the commit message this needs to
> be cleaned up)
I think it makes sense to remove the ping-pong logic and rely on
periodic updates alone, including fw_stats and ethstats handling.
>> - if (test_bit(WMI_SERVICE_PEER_STATS, ar->wmi.svc_map)) {
>> - param = ar->wmi.pdev_param->peer_stats_update_period;
>> - ret = ath10k_wmi_pdev_set_param(ar, param,
>> - PEER_DEFAULT_STATS_UPDATE_PERIOD);
>> - if (ret) {
>> - ath10k_warn(ar,
>> - "failed to set peer stats period : %d\n",
>> - ret);
>> - goto err_core_stop;
>> - }
>> + param = ar->wmi.pdev_param->peer_stats_update_period;
>> + ret = ath10k_wmi_pdev_set_param(ar, param,
>> + PEER_DEFAULT_STATS_UPDATE_PERIOD);
>> + if (ret) {
>> + ath10k_warn(ar,
>> + "failed to set peer stats period : %d\n",
>> + ret);
>> + goto err_core_stop;
>> }
>
> [shafi] If i am correct this change requires 'PEER_STATS' to be enabled by
> default.
No, it does not. Periodic stats have been available since forever.
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
>> index 4d3cbc44fcd2..2877a3a27b95 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>> @@ -3296,7 +3296,7 @@ struct wmi_csa_event {
>> /* the definition of different PDEV parameters */
>> #define PDEV_DEFAULT_STATS_UPDATE_PERIOD 500
>> #define VDEV_DEFAULT_STATS_UPDATE_PERIOD 500
>> -#define PEER_DEFAULT_STATS_UPDATE_PERIOD 500
>> +#define PEER_DEFAULT_STATS_UPDATE_PERIOD 100
>
> [shafi] Is this for more granularity since 500ms is not sufficient ?, I understand
> the firmware has default stats_update_period as 500ms and i hope it supports
> 100ms as well, Also if we are going to support period stats update we may need to
> accumulate the information in driver (like this change and rx_duration
The patch is used for rough rate estimation which is used to keep Tx
queues filled only with 1-2 txops worth of data. Signal conditions can
change vastly so I figured I need the peer stat update events come
more often. I didn't really verify if they come every 100ms. The patch
already served it's job as a proof-of-concept for smarter tx queuing.
> I will try to take this change, rebase it to TOT and see how it goes.
There's really no benefit it taking this patch as a basis for periodic
stat handling. Majority of this patch is just handling peer_tx_rate
for rate estimation purposes. Feel free to knock yourself out with
ripping out the ping-pong stat stuff though :)
Michał
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* Re: [RFCv2 2/3] ath10k: report per-station tx/rate rates to mac80211
From: Mohammed Shafi Shajakhan @ 2016-03-24 7:19 UTC (permalink / raw)
To: Michal Kazior
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, nbd-p3rKhJxN3npAfugRpC6u6w,
emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, dave.taht-Re5JQEeQqe8AvxtiuMwx3w,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
codel-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1,
make-wifi-fast-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1,
johannes-cdvu00un1VgdHxzADdlk8Q, Tim Shepard
In-Reply-To: <1458123478-1795-3-git-send-email-michal.kazior-++hxYGjEMp0AvxtiuMwx3w@public.gmane.org>
Hi Michal,
On Wed, Mar 16, 2016 at 11:17:57AM +0100, Michal Kazior wrote:
> The rate control is offloaded by firmware so it's
> challanging to provide expected throughput value
> for given station.
>
> This approach is naive as it reports last tx rate
> used for given station as provided by firmware
> stat event.
>
> This should be sufficient for airtime estimation
> used for fq-codel-in-mac80211 tx scheduling
> purposes now.
>
> This patch uses a very hacky way to get the stats.
> This is sufficient for proof-of-concept but must
> be cleaned up properly eventually.
>
> Signed-off-by: Michal Kazior <michal.kazior-++hxYGjEMp0AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/wireless/ath/ath10k/core.h | 5 +++
> drivers/net/wireless/ath/ath10k/debug.c | 61 +++++++++++++++++++++++++++++----
> drivers/net/wireless/ath/ath10k/mac.c | 26 ++++++++------
> drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
> 4 files changed, 76 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index 23ba03fb7a5f..3f76669d44cf 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -331,6 +331,9 @@ struct ath10k_sta {
> /* protected by conf_mutex */
> bool aggr_mode;
> u64 rx_duration;
> +
> + u32 tx_rate_kbps;
> + u32 rx_rate_kbps;
> #endif
> };
>
> @@ -372,6 +375,8 @@ struct ath10k_vif {
> s8 def_wep_key_idx;
>
> u16 tx_seq_no;
> + u32 tx_rate_kbps;
> + u32 rx_rate_kbps;
>
> union {
> struct {
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index 076d29b53ddf..cc7ebf04ae00 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -316,6 +316,58 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> spin_unlock_bh(&ar->data_lock);
> }
>
> +static void ath10k_mac_update_txrx_rate_iter(void *data,
> + u8 *mac,
> + struct ieee80211_vif *vif)
> +{
> + struct ath10k_fw_stats_peer *peer = data;
> + struct ath10k_vif *arvif;
> +
> + if (memcmp(vif->addr, peer->peer_macaddr, ETH_ALEN))
> + return;
> +
> + arvif = (void *)vif->drv_priv;
> + arvif->tx_rate_kbps = peer->peer_tx_rate;
> + arvif->rx_rate_kbps = peer->peer_rx_rate;
> +}
> +
> +static void ath10k_mac_update_txrx_rate(struct ath10k *ar,
> + struct ath10k_fw_stats *stats)
> +{
> + struct ieee80211_hw *hw = ar->hw;
> + struct ath10k_fw_stats_peer *peer;
> + struct ath10k_sta *arsta;
> + struct ieee80211_sta *sta;
> + const u8 *localaddr = NULL;
> +
> + rcu_read_lock();
> +
> + list_for_each_entry(peer, &stats->peers, list) {
> + /* This doesn't account for multiple STA connected on different
> + * vifs. Unfortunately there's no way to derive that from the available
> + * information.
> + */
> + sta = ieee80211_find_sta_by_ifaddr(hw,
> + peer->peer_macaddr,
> + localaddr);
> + if (!sta) {
> + /* This tries to update multicast rates */
> + ieee80211_iterate_active_interfaces_atomic(
> + hw,
> + IEEE80211_IFACE_ITER_NORMAL,
> + ath10k_mac_update_txrx_rate_iter,
> + peer);
> + continue;
> + }
> +
> + arsta = (void *)sta->drv_priv;
> + arsta->tx_rate_kbps = peer->peer_tx_rate;
> + arsta->rx_rate_kbps = peer->peer_rx_rate;
> + }
> +
> + rcu_read_unlock();
> +}
> +
> void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> {
> struct ath10k_fw_stats stats = {};
> @@ -335,6 +387,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> goto free;
> }
>
> + ath10k_mac_update_txrx_rate(ar, &stats);
> +
> /* Stat data may exceed htc-wmi buffer limit. In such case firmware
> * splits the stats data and delivers it in a ping-pong fashion of
> * request cmd-update event.
> @@ -351,13 +405,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> if (peer_stats_svc)
> ath10k_sta_update_rx_duration(ar, &stats.peers);
>
> - if (ar->debug.fw_stats_done) {
> - if (!peer_stats_svc)
> - ath10k_warn(ar, "received unsolicited stats update event\n");
> -
> - goto free;
> - }
> -
[shafi] As you had suggested previously, should we completely clean up this ping
- pong response approach for f/w stats, (or) this should be retained to support
backward compatibility and also for supporting ping - pong response when user
cats for fw-stats (via debugfs) (i did see in the commit message this needs to
be cleaned up)
> num_peers = ath10k_wmi_fw_stats_num_peers(&ar->debug.fw_stats.peers);
> num_vdevs = ath10k_wmi_fw_stats_num_vdevs(&ar->debug.fw_stats.vdevs);
> is_start = (list_empty(&ar->debug.fw_stats.pdevs) &&
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index ebff9c0a0784..addef9179dbe 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4427,16 +4427,14 @@ static int ath10k_start(struct ieee80211_hw *hw)
>
> ar->ani_enabled = true;
>
> - if (test_bit(WMI_SERVICE_PEER_STATS, ar->wmi.svc_map)) {
> - param = ar->wmi.pdev_param->peer_stats_update_period;
> - ret = ath10k_wmi_pdev_set_param(ar, param,
> - PEER_DEFAULT_STATS_UPDATE_PERIOD);
> - if (ret) {
> - ath10k_warn(ar,
> - "failed to set peer stats period : %d\n",
> - ret);
> - goto err_core_stop;
> - }
> + param = ar->wmi.pdev_param->peer_stats_update_period;
> + ret = ath10k_wmi_pdev_set_param(ar, param,
> + PEER_DEFAULT_STATS_UPDATE_PERIOD);
> + if (ret) {
> + ath10k_warn(ar,
> + "failed to set peer stats period : %d\n",
> + ret);
> + goto err_core_stop;
> }
[shafi] If i am correct this change requires 'PEER_STATS' to be enabled by
default.
>
> ar->num_started_vdevs = 0;
> @@ -7215,6 +7213,13 @@ ath10k_mac_op_switch_vif_chanctx(struct ieee80211_hw *hw,
> return 0;
> }
>
> +static u32
> +ath10k_mac_op_get_expected_throughput(struct ieee80211_sta *sta)
> +{
> + struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
> + return arsta->tx_rate_kbps;
> +}
> +
> static const struct ieee80211_ops ath10k_ops = {
> .tx = ath10k_mac_op_tx,
> .wake_tx_queue = ath10k_mac_op_wake_tx_queue,
> @@ -7254,6 +7259,7 @@ static const struct ieee80211_ops ath10k_ops = {
> .assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
> .unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
> .switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
> + .get_expected_throughput = ath10k_mac_op_get_expected_throughput,
>
> CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index 4d3cbc44fcd2..2877a3a27b95 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -3296,7 +3296,7 @@ struct wmi_csa_event {
> /* the definition of different PDEV parameters */
> #define PDEV_DEFAULT_STATS_UPDATE_PERIOD 500
> #define VDEV_DEFAULT_STATS_UPDATE_PERIOD 500
> -#define PEER_DEFAULT_STATS_UPDATE_PERIOD 500
> +#define PEER_DEFAULT_STATS_UPDATE_PERIOD 100
[shafi] Is this for more granularity since 500ms is not sufficient ?, I understand
the firmware has default stats_update_period as 500ms and i hope it supports
100ms as well, Also if we are going to support period stats update we may need to
accumulate the information in driver (like this change and rx_duration
I will try to take this change, rebase it to TOT and see how it goes.
thanks,
shafi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: call attention to review
From: Leon Romanovsky @ 2016-03-24 6:17 UTC (permalink / raw)
To: oulijun
Cc: pandit.parav, jiri, sergei.shtylyov, hch, dledford, sean.hefty,
hal.rosenstock, davem, jeffrey.t.kirsher, jiri, ogerlitz,
linux-rdma, linux-kernel, netdev, gongyangming, tangchaofei,
haifeng.wei, yisen.zhuang, yankejian, lisheng011, charles.chenxin,
linuxarm
In-Reply-To: <56F38026.6040209@huawei.com>
On Thu, Mar 24, 2016 at 01:50:30PM +0800, oulijun wrote:
> Hi,
> I am Lijun Ou. I have sent the PATCH v4 of HiSilicon RoCE driver at March 22, 2016.
> if you are convenient, please help to review. Welcome to give your reviewing.
Hi Lijun,
Please read whole document which describes how to submit patches [1]
and especially section 9, but please don't limit yourself to that
section only. The whole document is relevant to your patches.
[1] https://www.kernel.org/doc/Documentation/SubmittingPatches
>
> thanks
> Lijun Ou
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Willy Tarreau @ 2016-03-24 6:12 UTC (permalink / raw)
To: Tolga Ceylan
Cc: Tom Herbert, Eric Dumazet, cgallek, Josh Snyder, Aaron Conole,
David S. Miller, Linux Kernel Network Developers
In-Reply-To: <CALmu+SwjG0GVocGufTbgX-WJfcsP85SvHB=xtW7qQX3kZwJCxg@mail.gmail.com>
Hi,
On Wed, Mar 23, 2016 at 10:10:06PM -0700, Tolga Ceylan wrote:
> I apologize for not properly following up on this. I had the
> impression that we did not want to merge my original patch and then I
> also noticed that it fails to keep the hash consistent. Recently, I
> read the follow ups on it as well as Willy's patch/proposals.
>
> Is there any update on Willy's SO_REUSEPORT patch? IMHO, it solves the
> problem and it is simpler than adding new sock option.
no, Craig's changes were merged, and I haven't checked yet if my patch
needs to be rebased or still applies. Feel free to check it and resubmit
if you have time.
Best regards,
Willy
^ permalink raw reply
* call attention to review
From: oulijun @ 2016-03-24 5:50 UTC (permalink / raw)
To: Leon Romanovsky, pandit.parav-Re5JQEeQqe8AvxtiuMwx3w,
jiri-rHqAuBHg3fBzbRFIqnYvSA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
hch-wEGCiKHe2LqWVfeAwA7xHQ, dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
oulijun-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
Hi,
I am Lijun Ou. I have sent the PATCH v4 of HiSilicon RoCE driver at March 22, 2016.
if you are convenient, please help to review. Welcome to give your reviewing.
thanks
Lijun Ou
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Tolga Ceylan @ 2016-03-24 5:10 UTC (permalink / raw)
To: Willy Tarreau
Cc: Tom Herbert, Eric Dumazet, cgallek, Josh Snyder, Aaron Conole,
David S. Miller, Linux Kernel Network Developers
In-Reply-To: <20151221204127.GC8018@1wt.eu>
On Mon, Dec 21, 2015 at 12:41 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Mon, Dec 21, 2015 at 12:38:27PM -0800, Tom Herbert wrote:
>> On Fri, Dec 18, 2015 at 11:00 PM, Willy Tarreau <w@1wt.eu> wrote:
>> > On Fri, Dec 18, 2015 at 06:38:03PM -0800, Eric Dumazet wrote:
>> >> On Fri, 2015-12-18 at 19:58 +0100, Willy Tarreau wrote:
>> >> > Hi Josh,
>> >> >
>> >> > On Fri, Dec 18, 2015 at 08:33:45AM -0800, Josh Snyder wrote:
>> >> > > I was also puzzled that binding succeeded. Looking into the code paths
>> >> > > involved, in inet_csk_get_port, we quickly goto have_snum. From there, we end
>> >> > > up dropping into tb_found. Since !hlist_empty(&tb->owners), we end up checking
>> >> > > that (tb->fastreuseport > 0 && sk->sk_reuseport && uid_eq(tb->fastuid, uid)).
>> >> > > This test passes, so we goto success and bind.
>> >> > >
>> >> > > Crucially, we are checking the fastreuseport field on the inet_bind_bucket, and
>> >> > > not the sk_reuseport variable on the other sockets in the bucket. Since this
>> >> > > bit is set based on sk_reuseport at the time the first socket binds (see
>> >> > > tb_not_found), I can see no reason why sockets need to keep SO_REUSEPORT set
>> >> > > beyond initial binding.
>> >> > >
>> >> > > Given this, I believe Willy's patch elegantly solves the problem at hand.
>> >> >
>> >> > Great, thanks for your in-depth explanation.
>> >> >
>> >> > Eric, do you think that this patch may be acceptable material for next
>> >> > merge window (given that it's not a fix per-se) ? If so I'll resubmit
>> >> > later.
>> >>
>> >> I need to check with Craig Gallek, because he was about to upstream a
>> >> change to make SO_REUSEPORT more scalable & sexy (like having an [e]BPF
>> >> filter to perform the selection in an array of sockets)
>> >
Hi All,
I apologize for not properly following up on this. I had the
impression that we did not want to merge my original patch and then I
also noticed that it fails to keep the hash consistent. Recently, I
read the follow ups on it as well as Willy's patch/proposals.
Is there any update on Willy's SO_REUSEPORT patch? IMHO, it solves the
problem and it is simpler than adding new sock option.
Best Regards,
Tolga Ceylan
^ permalink raw reply
* Re: net/sctp: stack-out-of-bounds in sctp_getsockopt
From: Baozeng @ 2016-03-24 5:01 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Eric Dumazet, kaber, kadlec, netfilter-devel, marcelo.leitner,
Vladislav Yasevich, nhorman, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <20160323173818.GA11724@salvia>
2016-03-24 1:38 GMT+08:00, Pablo Neira Ayuso <pablo@netfilter.org>:
> On Thu, Mar 24, 2016 at 12:42:43AM +0800, Baozeng wrote:
>> 2016-03-22 23:27 GMT+08:00 Eric Dumazet <eric.dumazet@gmail.com>:
>> > Untested patch would be :
>> >
>> > diff --git a/net/bridge/netfilter/ebtables.c
>> > b/net/bridge/netfilter/ebtables.c
>> > index 67b2e27999aa..fceb7354d169 100644
>> > --- a/net/bridge/netfilter/ebtables.c
>> > +++ b/net/bridge/netfilter/ebtables.c
>> > @@ -346,7 +346,7 @@ find_inlist_lock(struct list_head *head, const char
>> > *name, const char *prefix,
>> > {
>> > return try_then_request_module(
>> > find_inlist_lock_noload(head, name, error,
>> > mutex),
>> > - "%s%s", prefix, name);
>> > + "%.*s%s", EBT_TABLE_MAXNAMELEN, prefix, name);
>> > }
>> >
>> > static inline struct ebt_table *
>> >
>> >
>>
>> Thanks for your quick patch. I tested it but it still reproduce the
>> bug. We should limit the length of the name,
>> not the prefix. The following patch fixs it.
>
> Could you give a try to this patch? Thanks.
>
I tested with your patch. It fixs the bug. Thanks.
--
Best Regards,
Baozeng Ding
^ permalink raw reply
* [PATCH net v2 RESEND] xfrm: Fix crash observed during device unregistration and decryption
From: Subash Abhinov Kasiviswanathan @ 2016-03-24 4:39 UTC (permalink / raw)
To: netdev, steffen.klassert, eric.dumazet, davem
Cc: Subash Abhinov Kasiviswanathan, Jerome Stanislaus
A crash is observed when a decrypted packet is processed in receive
path. get_rps_cpus() tries to dereference the skb->dev fields but it
appears that the device is freed from the poison pattern.
[<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
[<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
[<ffffffc000af6094>] netif_rx+0x74/0x94
[<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
[<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
[<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
[<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
[<ffffffc0000b7324>] worker_thread+0x2f8/0x418
[<ffffffc0000bb40c>] kthread+0xe0/0xec
-013|get_rps_cpu(
| dev = 0xFFFFFFC08B688000,
| skb = 0xFFFFFFC0C76AAC00 -> (
| dev = 0xFFFFFFC08B688000 -> (
| name =
"......................................................
| name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
0xAAAAAAAAAAA
Following are the sequence of events observed -
- Encrypted packet in receive path from netdevice is queued
- Encrypted packet queued for decryption (asynchronous)
- Netdevice brought down and freed
- Packet is decrypted and returned through callback in esp_input_done
- Packet is queued again for process in network stack using netif_rx
Since the device appears to have been freed, the dereference of
skb->dev in get_rps_cpus() leads to an unhandled page fault
exception.
Fix this by holding on to device reference when queueing packets
asynchronously and releasing the reference on call back return.
v2: Make the change generic to xfrm as mentioned by Steffen and
update the title to xfrm
Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jerome Stanislaus <jeromes@codeaurora.org>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
net/xfrm/xfrm_input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index ad7f5b3..1c4ad47 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -292,12 +292,15 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
XFRM_SKB_CB(skb)->seq.input.hi = seq_hi;
skb_dst_force(skb);
+ dev_hold(skb->dev);
nexthdr = x->type->input(x, skb);
if (nexthdr == -EINPROGRESS)
return 0;
resume:
+ dev_put(skb->dev);
+
spin_lock(&x->lock);
if (nexthdr <= 0) {
if (nexthdr == -EBADMSG) {
--
1.8.2.1
^ permalink raw reply related
* Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload
From: Alexander Duyck @ 2016-03-24 2:53 UTC (permalink / raw)
To: Jesse Gross
Cc: Tom Herbert, Alexander Duyck, Edward Cree,
Linux Kernel Network Developers, David S. Miller
In-Reply-To: <CAEh+42jKm0_89n_-vZwMRZHUpNgNVJLJ5Qo4YrhRZx7UZD0Swg@mail.gmail.com>
On Wed, Mar 23, 2016 at 6:37 PM, Jesse Gross <jesse@kernel.org> wrote:
> On Wed, Mar 23, 2016 at 11:19 AM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Wed, Mar 23, 2016 at 10:09 AM, Tom Herbert <tom@herbertland.com> wrote:
>>> Can you add some description about strategy for dealing with ip_id?
>>
>> Yeah. I still need to add more documentation. I just didn't want to
>> get into details on it until we have finalized things a bit more. I'm
>> still wondering if we should follow the pattern of ipip tunnels in
>> terms of setting the DF bit if the inner header has the DF bit set.
>> If we end up needing to add code to do that then it makes it so that
>> the ip_id value can be fixed for both inner and outer which makes the
>> segmentation much simpler since the only header that would ever really
>> need to be updated would be the transport header in order to get the
>> checksum correct.
>
> I tried to do this years ago but in practice it broke things.
>
> There's enough middleboxes/firewalls/etc. out there that filter ICMP
> messages that path MTU discovery isn't necessarily reliable. And while
> you might argue that if the box is breaking things then the same would
> be true for the original, unencapsulated TCP stream but a lot of times
> there are some other hacks built in (like MSS clamping) that make
> assumptions that the traffic is TCP. So at the minimum it is generally
> good to have an option to force the DF bit off.
Agreed, I think if we tried anything we would have to have some sort
of bit remaining to shut it off.
> That being said, I actually think that it is good to have the DF bit
> on by default for encapsulation headers being added. Unintentional
> (and perhaps multiple layers of) fragmentation usually results in
> unuseably bad performance and so it best to try to correct it,
> hopefully automatically in most cases. And, of course, this is the
> direction that IPv6 has already gone. If we can assume that this is
> the most common case then in practice we can keep the outer headers
> constant for the high performance path.
I'm still weighting my options on how to address the DF issue. I'm
not really sure having DF always on for outer headers is the best way
to go either. I kind of like the idea that if DF is set for the inner
headers then we set it for the outer headers. I just have to see how
hard something like that would be to implement.
> To me, incrementing the inner IP really seems the best choice. The
> inner header is most likely someone else's traffic so it best to not
> mess with that whereas the outer headers are likely ours and we know
> the parameters for them (and can set the DF bit as we believe is
> correct). Also, if you are looking forward to the future as far as
> stacking multiple layers of tunnels, I think the only consistent thing
> to do is have the inner ID increment and all of the tunnel headers
> stay fixed - it is hard to justify why the first tunnel header should
> increment but not the second one. And finally, as a nice bonus, this
> is what the GRO code has been expecting already so you won't cause any
> performance regressions with existing systems.
Agreed. However in the case of the igb and ixgbe incrementing the
inner isn't really going to work well as it introduces a number of
issues. I've considered not enabling GSO partial by default on those
parts, but leaving it as an available feature. In the case of i40e we
will not have any of those issues as both the inner and outer IP IDs
will increment.
The regressions issue shouldn't be all that big. In most cases
tunnels are point to point links. Odds are if someone is running a
network they should have similar devices on both ends. So in the case
of the Intel drivers I have patched here updating i40e isn't that big
of a deal since it retains the original GSO behavior. In the case of
ixgbe it didn't support any tunnel offloads so there is no GRO support
without checksums being enabled in the tunnel, and Tx checksum support
vi HW_CSUM has yet to be pushed upstream from Jeff's tree so things
are currently throttled by the Tx side.
GSO partial is going to end up being very driver specific in terms of
what increments and what doesn't as we are having to really hack our
way around to make it do things the spec sheets say it cannot do.
Some implementations are going to end up working out better than
others in terms of interoperability and what can make use of other
advanced features such as GRO on legacy systems.
- Alex
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2016-03-24 2:23 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Several bug fixes rolling in, some for changes introduced in this
merge window, and some for problems that have existed for some time:
1) Fix prepare_to_wait() handling in AF_VSOCK, from Claudio Imbrenda.
2) The new DST_CACHE should be a silent config option, from Dave
Jones.
3) inet_current_timestamp() unintentionally truncates timestamps
to 16-bit, from Deepa Dinamani.
4) Missing reference to netns in ppp, from Guillaume Nault.
5) Free memory reference in hv_netvsc driver, from Haiyang Zhang.
6) Missing kernel doc documentation for function arguments in various
spots around the networking, from Luis de Bethencourt.
7) UDP stopped receiving broadcast packets properly, due to overzealous
multicast checks, fix from Paolo Abeni.
Please pull, thanks a lot!
The following changes since commit de06dbfa7861c9019eedefc0c356ba86e5098f1b:
Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm (2016-03-19 16:31:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 6579a023a881e0592ce9a98fdfcbcc0a2a096aa7:
net: ping: make ping_v6_sendmsg static (2016-03-23 22:09:58 -0400)
----------------------------------------------------------------
Alexander Duyck (1):
net: Reset encap_level to avoid resetting features on inner IP headers
Arnd Bergmann (1):
net: smc911x: avoid unused variable warnings
Benjamin Poirier (3):
net: Fix indentation of the conf/ documentation block
igmp: Document sysctl_igmp_max_msf
net: Add missing kernel-doc for netdev ptype lists
Bjorn Helgaas (1):
net: Fix typos and whitespace.
Claudio Imbrenda (2):
Revert "vsock: Fix blocking ops call in prepare_to_wait"
AF_VSOCK: Shrink the area influenced by prepare_to_wait
Colin Ian King (1):
net/mlx4: remove unused array zero_gid[]
Dan Carpenter (1):
mdio-sun4i: oops in error handling in probe
Daniel Borkmann (3):
vxlan: fix populating tclass in vxlan6_get_route
geneve: fix populating tclass in geneve_get_v6_dst
ipv6, trace: fix tos reporting on fib6_table_lookup
Daode Huang (1):
net: hns: bug fix about the overflow of mss
Dave Jones (1):
Make DST_CACHE a silent config option
David Decotigny (2):
ethtool: minor doc update
netlink: add support for NIC driver ioctls
David S. Miller (7):
Merge git://git.kernel.org/.../torvalds/linux
Merge branch 'flowi6_tos'
Merge branch 'tunnel-fixes'
Revert "lan78xx: add ndo_get_stats64"
Merge branch 'bridge-gso-segs-and-size'
Merge branch 'hns-fixes'
Merge branch 'AF_VSOCK-missed-wakeups'
Deepa Dinamani (1):
net: ipv4: Fix truncated timestamp returned by inet_current_timestamp()
Eric Dumazet (3):
net: remove a dubious unlikely() clause
net/rtnetlink: add IFLA_GSO_MAX_SEGS and IFLA_GSO_MAX_SIZE attributes
bridge: update max_gso_segs and max_gso_size
Guillaume Nault (1):
ppp: take reference on channels netns
Haishuang Yan (1):
net: ping: make ping_v6_sendmsg static
Haiyang Zhang (3):
hv_netvsc: Fix accessing freed memory in netvsc_change_mtu()
hv_netvsc: Fix the array sizes to be max supported channels
hv_netvsc: Fix the order of num_sc_offered decrement
Igal Liberman (1):
fsl/fman: Workaround for Errata A-007273
Jesse Gross (3):
ipip: Properly mark ipip GRO packets as encapsulated.
tunnels: Don't apply GRO to multiple layers of encapsulation.
tunnels: Remove encapsulation offloads on decap.
Jiri Benc (2):
vxlan: fix sparse warnings
vxlan: fix too large pskb_may_pull with remote checksum
Kejian Yan (6):
net: hns: bug fix about ping6
net: hns: add uc match for debug ports
net: hns: fix return value of the function about rss
net: hns: fixes a bug of RSS
net: hns: fix the bug about mtu setting
net: hns: adds limitation for debug port mtu
Lance Richardson (1):
ipv4: initialize flowi4_flags before calling fib_lookup()
Luis de Bethencourt (5):
gen_stats.c: Add description for cpu argument
net: sched: Add description for cpu_bstats argument
net: add description for len argument of dev_get_phys_port_name
net: add missing descriptions in net_device_priv_flags
ipv6: remove unused in6_addr struct
Marcelo Ricardo Leitner (5):
sctp: fix copying more bytes than expected in sctp_add_bind_addr
sctp: do not update a_rwnd if we are not issuing a sack
sctp: do not leak chunks that are sent to unconfirmed paths
sctp: align MTU to a word
sctp: keep fragmentation point aligned to word size
Paolo Abeni (1):
ipv4: fix broadcast packets reception
Qianqian Xie (1):
net: hns: set xge statistic reg as read only
Sebastian Frias (1):
net: phy: at803x: Request 'reset' GPIO only for AT8030 PHY
Sergei Shtylyov (2):
macb: fix PHY reset
at803x: fix reset handling
Sheng Li (2):
net: hns: fixed portid bug in sending manage pkt
net: hns: fixed the bug about GMACs mac setting
Tina Ruchandani (1):
isdn: Use ktime_t instead of 'struct timeval'
Vladimir Zapolskiy (1):
net: mediatek: fix checking for NULL instead of IS_ERR() in .probe
Documentation/networking/ip-sysctl.txt | 19 +++--
drivers/isdn/mISDN/clock.c | 69 +++++++----------
drivers/net/ethernet/cadence/macb.c | 4 +-
drivers/net/ethernet/freescale/fman/fman.c | 104 +++++++++++++++++++++----
drivers/net/ethernet/hisilicon/hns/hnae.h | 3 +
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 12 ++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 38 +++++++--
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 15 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h | 6 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 5 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 5 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h | 2 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 2 +
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 32 +++++---
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 38 +++++----
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/mcg.c | 2 -
drivers/net/ethernet/smsc/smc911x.c | 2 +
drivers/net/geneve.c | 11 +--
drivers/net/hyperv/hyperv_net.h | 7 +-
drivers/net/hyperv/netvsc_drv.c | 5 +-
drivers/net/hyperv/rndis_filter.c | 16 ++--
drivers/net/phy/at803x.c | 10 ++-
drivers/net/phy/mdio-sun4i.c | 4 +-
drivers/net/ppp/ppp_generic.c | 4 +-
drivers/net/usb/lan78xx.c | 49 ------------
drivers/net/vxlan.c | 9 +--
include/linux/mISDNif.h | 2 +-
include/linux/netdevice.h | 225 +++++++++++++++++++++++++++---------------------------
include/net/flow.h | 2 +-
include/net/inet6_connection_sock.h | 1 -
include/net/ip_tunnels.h | 16 ++++
include/net/ipv6.h | 6 ++
include/net/ping.h | 1 -
include/net/sctp/sctp.h | 10 ++-
include/net/sctp/structs.h | 2 +-
include/net/vxlan.h | 16 ++--
include/trace/events/fib6.h | 2 +-
include/uapi/linux/ethtool.h | 6 +-
include/uapi/linux/if_link.h | 2 +
net/Kconfig | 2 +-
net/bridge/br_if.c | 16 ++++
net/core/dev.c | 3 +-
net/core/gen_estimator.c | 2 +
net/core/gen_stats.c | 1 +
net/core/rtnetlink.c | 4 +
net/core/skbuff.c | 2 +-
net/ipv4/af_inet.c | 26 ++++++-
net/ipv4/fib_frontend.c | 16 ++--
net/ipv4/fou.c | 13 +++-
net/ipv4/gre_offload.c | 6 ++
net/ipv4/ip_tunnel_core.c | 3 +-
net/ipv4/udp.c | 12 ++-
net/ipv4/udp_offload.c | 7 +-
net/ipv6/ip6_offload.c | 15 +++-
net/ipv6/ping.c | 59 +++++++-------
net/ipv6/sit.c | 6 +-
net/netlink/af_netlink.c | 10 ++-
net/sctp/associola.c | 3 +-
net/sctp/bind_addr.c | 14 ++--
net/sctp/input.c | 3 +-
net/sctp/outqueue.c | 6 +-
net/sctp/protocol.c | 1 +
net/sctp/sm_make_chunk.c | 3 +-
net/sctp/sm_sideeffect.c | 6 +-
net/sctp/socket.c | 4 +-
net/sctp/transport.c | 4 +-
net/vmw_vsock/af_vsock.c | 155 ++++++++++++++++++++-----------------
68 files changed, 710 insertions(+), 460 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 1/9] ipv4/GRO: Allow multiple frames to use the same IP ID
From: Alexander Duyck @ 2016-03-24 2:21 UTC (permalink / raw)
To: Jesse Gross
Cc: Alexander Duyck, Edward Cree, Linux Kernel Network Developers,
David Miller, Tom Herbert
In-Reply-To: <CAEh+42ir0ich=MyEtr7NkKiUBhE7Md_AF8YzQ2bCv=cy=5ziFg@mail.gmail.com>
On Wed, Mar 23, 2016 at 6:43 PM, Jesse Gross <jesse@kernel.org> wrote:
> On Fri, Mar 18, 2016 at 4:24 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
>> In RFC 6864 it is stated that we can essentially ignore the IPv4 ID field
>> if we have not and will not use fragmentation. Such a frame is defined
>> as having the DF flag set to 1, and the MF and frag_offset as 0. Currently
>> for GRO we were requiring that the inner header always have an increasing
>> IPv4 ID, but we are ignoring the outer value.
>>
>> This patch is a first step in trying to reverse some of that. Specifically
>> what this patch does is allow us to coalesce frames that have a static IPv4
>> ID value. So for example if we had a series of frames where the DF flag
>> was set we would allow the same IPv4 ID value to be used for all the frames
>> belonging to that flow. This would become the standard behavior for TCP so
>> it would support either a fixed IPv4 ID value, or one in which the value
>> increments.
>>
>> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
>
> One thing that is a bit odd is that the TSO output procedure stays the
> same. So that means that if we get a stream of packets with the DF bit
> set and a constant IP ID, aggregate them with GRO, and the retransmit
> with GSO/TSO then we'll get packets with IDs that increment for each
> burst and then start back again to the original value. I guess it
> doesn't matter in practice since the IDs are supposed to be ignored
> but it does seem a little strange - especially because the new packets
> will now be violating the rules of the same GRO implementation that
> produced them.
Yes and no. The rule for GRO with this patch is that the IP ID has to
be either incrementing or if DF is set it has the option to be a fixed
value for a given grouping of packets. In that regard either GSO
partial or standard GSO are still both reversible via GRO so that you
can aggregate to get back to the original frame (ignoring the IP ID)
that GSO segmented. The bit I am still trying to work out is what to
do about the case where we GRO 2 frames out of one GSO segment. I
wonder if I should just totally ignore the IP ID value since it ends
up creating an artificial boundary between the two frames if they are
segmented using the incrementing GSO versus the fixed IP ID GSO.
- Alex
^ permalink raw reply
* Re: [PATCH] net: ping: make ping_v6_sendmsg static
From: David Miller @ 2016-03-24 2:10 UTC (permalink / raw)
To: yanhaishuang
Cc: sergei.shtylyov, jmorris, kaber, kuznet, yoshfuji, netdev,
linux-kernel
In-Reply-To: <etPan.56f3489d.47f24d7.66d@yanhaishuangs-MacBook-Pro.local>
From: 严海双 <yanhaishuang@cmss.chinamobile.com>
Date: Thu, 24 Mar 2016 09:53:33 +0800
> The two changes is dependent, because "pingv6_prot" and
> “pingv6_protosw” must be moved to the behind also, to avoid having
> to declare static “ping_v6_sendmsg” prototypes first.
Agreed, and applied, thank you.
^ permalink raw reply
* Re: [PATCH net v2] xfrm: Fix crash observed during device unregistration and decryption
From: David Miller @ 2016-03-24 2:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, subashab, steffen.klassert, netdev, jeromes
In-Reply-To: <1458783597.10868.60.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 23 Mar 2016 18:39:57 -0700
> On Thu, 2016-03-24 at 08:45 +0800, Herbert Xu wrote:
>> On Wed, Mar 23, 2016 at 10:29:25AM -0700, Eric Dumazet wrote:
>> >
>> > OK, but before calling netif_rx() are we properly testing dev->flags
>> > IFF_UP status ?
>> >
>> > Otherwise, we still allow packets being queued after flush_backlog() had
>> > been called.
>>
>> That's the first thing enqueue_to_backlog tests.
>>
>> Cheers,
>
> Seems to be very recent stuff ( commit
> e9e4dd3267d0c5234c5c0f47440456b10875dec9 in linux-4.2)
>
> In the old days the test was done in callers, since in most cases NIC
> drivers do not need it.
>
> Lets make sure this was backported to all stable trees.
>
> And then we probably can cleanup some callers as well.
Anyways this patch needs to be redone because it is corrupted by the
submitter's email client.
I'll queue it up and make sure e9e4dd3267d0c5234c5c0f47440456b10875dec9
ends up in -stable where needed.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] hv_netvsc: Fix the order of num_sc_offered decrement
From: David Miller @ 2016-03-24 1:53 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, driverdev-devel, linux-kernel
In-Reply-To: <1458770088-923-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Wed, 23 Mar 2016 14:54:48 -0700
> Reorder the code in netvsc_sc_open(), so num_sc_offered is only decremented
> after vmbus_open() is called. This avoid pontential race of removing device
> before all channels are setup.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 1/9] ipv4/GRO: Allow multiple frames to use the same IP ID
From: Jesse Gross @ 2016-03-24 1:43 UTC (permalink / raw)
To: Alexander Duyck
Cc: Edward Cree, Linux Kernel Network Developers, David Miller,
Alexander Duyck, Tom Herbert
In-Reply-To: <20160318232444.14955.38133.stgit@localhost.localdomain>
On Fri, Mar 18, 2016 at 4:24 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
> In RFC 6864 it is stated that we can essentially ignore the IPv4 ID field
> if we have not and will not use fragmentation. Such a frame is defined
> as having the DF flag set to 1, and the MF and frag_offset as 0. Currently
> for GRO we were requiring that the inner header always have an increasing
> IPv4 ID, but we are ignoring the outer value.
>
> This patch is a first step in trying to reverse some of that. Specifically
> what this patch does is allow us to coalesce frames that have a static IPv4
> ID value. So for example if we had a series of frames where the DF flag
> was set we would allow the same IPv4 ID value to be used for all the frames
> belonging to that flow. This would become the standard behavior for TCP so
> it would support either a fixed IPv4 ID value, or one in which the value
> increments.
>
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
One thing that is a bit odd is that the TSO output procedure stays the
same. So that means that if we get a stream of packets with the DF bit
set and a constant IP ID, aggregate them with GRO, and the retransmit
with GSO/TSO then we'll get packets with IDs that increment for each
burst and then start back again to the original value. I guess it
doesn't matter in practice since the IDs are supposed to be ignored
but it does seem a little strange - especially because the new packets
will now be violating the rules of the same GRO implementation that
produced them.
^ permalink raw reply
* Re: [PATCH net v2] xfrm: Fix crash observed during device unregistration and decryption
From: Eric Dumazet @ 2016-03-24 1:39 UTC (permalink / raw)
To: Herbert Xu
Cc: Subash Abhinov Kasiviswanathan, 'Steffen Klassert',
netdev, jeromes
In-Reply-To: <20160324004514.GA3110@gondor.apana.org.au>
On Thu, 2016-03-24 at 08:45 +0800, Herbert Xu wrote:
> On Wed, Mar 23, 2016 at 10:29:25AM -0700, Eric Dumazet wrote:
> >
> > OK, but before calling netif_rx() are we properly testing dev->flags
> > IFF_UP status ?
> >
> > Otherwise, we still allow packets being queued after flush_backlog() had
> > been called.
>
> That's the first thing enqueue_to_backlog tests.
>
> Cheers,
Seems to be very recent stuff ( commit
e9e4dd3267d0c5234c5c0f47440456b10875dec9 in linux-4.2)
In the old days the test was done in callers, since in most cases NIC
drivers do not need it.
Lets make sure this was backported to all stable trees.
And then we probably can cleanup some callers as well.
^ 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