* Re: [PATCH] xen-netback: count number required slots for an skb more carefully
From: Wei Liu @ 2013-09-04 13:14 UTC (permalink / raw)
To: David Vrabel
Cc: Wei Liu, xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky,
Ian Campbell, netdev, msw, annie.li
In-Reply-To: <52271DFF.3070008@citrix.com>
On Wed, Sep 04, 2013 at 12:48:15PM +0100, David Vrabel wrote:
> On 03/09/13 22:53, Wei Liu wrote:
> > On Tue, Sep 03, 2013 at 06:29:50PM +0100, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> When a VM is providing an iSCSI target and the LUN is used by the
> >> backend domain, the generated skbs for direct I/O writes to the disk
> >> have large, multi-page skb->data but no frags.
> >>
> >> With some lengths and starting offsets, xen_netbk_count_skb_slots()
> >> would be one short because the simple calculation of
> >> DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the
> >> decisions made by start_new_rx_buffer() which does not guarantee
> >> responses are fully packed.
> >>
> >> For example, a skb with length < 2 pages but which spans 3 pages would
> >> be counted as requiring 2 slots but would actually use 3 slots.
> >>
> >> skb->data:
> >>
> >> | 1111|222222222222|3333 |
> >>
> >> Fully packed, this would need 2 slots:
> >>
> >> |111122222222|22223333 |
> >>
> >> But because the 2nd page wholy fits into a slot it is not split across
> >> slots and goes into a slot of its own:
> >>
> >> |1111 |222222222222|3333 |
> >>
> >> Miscounting the number of slots means netback may push more responses
> >> than the number of available requests. This will cause the frontend
> >> to get very confused and report "Too many frags/slots". The frontend
> >> never recovers and will eventually BUG.
> >>
> >> Fix this by counting the number of required slots more carefully. In
> >> xen_netbk_count_skb_slots(), more closely follow the algorithm used by
> >> xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which
> >> is the dry-run equivalent of netbk_gop_frag_copy().
> >>
> >
> > Phew! So this is backend miscounting bug. I thought it was a frontend
> > bug so it didn't ring a bell when we had our face-to-face discussion,
> > sorry. :-(
> >
> > This bug was discussed back in July among Annie, Matt, Ian and I. We
> > finally agreed to take Matt's solution. Matt agreed to post final
> > version within a week but obviously he's too busy to do so. I was away
> > so I didn't follow closely. Eventually it fell through the crack. :-(
>
> I think I prefer fixing the counting for backporting to stable kernels.
The original patch has coding style change. Sans that contextual change
it's not a very long patch.
> Xi's approach of packing the ring differently is a change in frontend
> visible behaviour and seems more risky. e.g., possible performance
> impact so I would like to see some performance analysis of that approach.
>
With Xi's approach it is more efficient for backend to process. As we
now use one less grant copy operation which means we copy the same
amount of data with less grant ops.
>From frontend's PoV I think the impact is minimal. Frontend is involved
in assembling the packets. It only takes what's in the ring and chain
them together. The operation involves copying so far is the
__pskb_pull_tail which happens a) in rare case when there's more frags
than frontend's MAX_SKB_FRAGS, b) when pull_to > skb_headlen which
happens. With Xi's change the rare case a) will even be rarer than
before as we use less slots. b) happens the same as it happens before
Xi's change, because the pull is guarded by "if (pull_to >
skb_headlen(skb))" and Xi's change doesn't affect skb_headlen.
So overall I don't see obvious downside.
Wei.
> David
^ permalink raw reply
* [net-next 9/9] igb: Update version number
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
This patch updates igb driver version to 5.0.5
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index b209ca5..8cf44f2 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -62,7 +62,7 @@
#define MAJ 5
#define MIN 0
-#define BUILD 3
+#define BUILD 5
#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) "." \
__stringify(BUILD) "-k"
char igb_driver_name[] = "igb";
--
1.8.3.1
^ permalink raw reply related
* [net-next 8/9] igb: Implementation to report advertised/supported link on i354 devices
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
This patch changes the way we report supported/advertised link for i354
devices, especially for 2.5 GB. Instead of reporting 2.5 GB for all i354
devices erroneously, check first, if it is 2.5 GB capable.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index ce9b5a9..48cbc83 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -172,10 +172,7 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
SUPPORTED_Autoneg |
SUPPORTED_Pause);
ecmd->advertising = ADVERTISED_FIBRE;
- if (hw->mac.type == e1000_i354) {
- ecmd->supported |= SUPPORTED_2500baseX_Full;
- ecmd->advertising |= ADVERTISED_2500baseX_Full;
- }
+
if ((eth_flags->e1000_base_lx) || (eth_flags->e1000_base_sx)) {
ecmd->supported |= SUPPORTED_1000baseT_Full;
ecmd->advertising |= ADVERTISED_1000baseT_Full;
@@ -209,16 +206,23 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
status = rd32(E1000_STATUS);
if (status & E1000_STATUS_LU) {
- if ((hw->mac.type == e1000_i354) &&
- (status & E1000_STATUS_2P5_SKU) &&
- !(status & E1000_STATUS_2P5_SKU_OVER))
- ecmd->speed = SPEED_2500;
- else if (status & E1000_STATUS_SPEED_1000)
+ if (hw->mac.type == e1000_i354) {
+ if ((status & E1000_STATUS_2P5_SKU) &&
+ !(status & E1000_STATUS_2P5_SKU_OVER)) {
+ ecmd->supported = SUPPORTED_2500baseX_Full;
+ ecmd->advertising = ADVERTISED_2500baseX_Full;
+ ecmd->speed = SPEED_2500;
+ } else {
+ ecmd->supported = SUPPORTED_1000baseT_Full;
+ ecmd->advertising = ADVERTISED_1000baseT_Full;
+ }
+ } else if (status & E1000_STATUS_SPEED_1000) {
ecmd->speed = SPEED_1000;
- else if (status & E1000_STATUS_SPEED_100)
+ } else if (status & E1000_STATUS_SPEED_100) {
ecmd->speed = SPEED_100;
- else
+ } else {
ecmd->speed = SPEED_10;
+ }
if ((status & E1000_STATUS_FD) ||
hw->phy.media_type != e1000_media_type_copper)
ecmd->duplex = DUPLEX_FULL;
--
1.8.3.1
^ permalink raw reply related
* [net-next 7/9] igb: Get speed and duplex for 1G non_copper devices
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
This patch changes how we get speed/duplex for non_copper devices; it
now uses pcs register to get current speed and duplex instead of using
generic status register that we use to detect speed/duplex for copper
devices.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index 68dd7c8..79b5835 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -1141,6 +1141,31 @@ static s32 igb_get_cfg_done_82575(struct e1000_hw *hw)
}
/**
+ * igb_get_link_up_info_82575 - Get link speed/duplex info
+ * @hw: pointer to the HW structure
+ * @speed: stores the current speed
+ * @duplex: stores the current duplex
+ *
+ * This is a wrapper function, if using the serial gigabit media independent
+ * interface, use PCS to retrieve the link speed and duplex information.
+ * Otherwise, use the generic function to get the link speed and duplex info.
+ **/
+static s32 igb_get_link_up_info_82575(struct e1000_hw *hw, u16 *speed,
+ u16 *duplex)
+{
+ s32 ret_val;
+
+ if (hw->phy.media_type != e1000_media_type_copper)
+ ret_val = igb_get_pcs_speed_and_duplex_82575(hw, speed,
+ duplex);
+ else
+ ret_val = igb_get_speed_and_duplex_copper(hw, speed,
+ duplex);
+
+ return ret_val;
+}
+
+/**
* igb_check_for_link_82575 - Check for link
* @hw: pointer to the HW structure
*
@@ -2723,7 +2748,7 @@ static struct e1000_mac_operations e1000_mac_ops_82575 = {
.check_for_link = igb_check_for_link_82575,
.rar_set = igb_rar_set,
.read_mac_addr = igb_read_mac_addr_82575,
- .get_speed_and_duplex = igb_get_speed_and_duplex_copper,
+ .get_speed_and_duplex = igb_get_link_up_info_82575,
#ifdef CONFIG_IGB_HWMON
.get_thermal_sensor_data = igb_get_thermal_sensor_data_generic,
.init_thermal_sensor_thresh = igb_init_thermal_sensor_thresh_generic,
--
1.8.3.1
^ permalink raw reply related
* [net-next 6/9] igb: Support to get 2_5G link status for appropriate media type
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Since i354 2.5Gb devices are not Copper media type but SerDes, so this
patch changes the way we detect speed/duplex link info for this device.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 25 ++++++++++++++++++-------
drivers/net/ethernet/intel/igb/e1000_mac.c | 11 -----------
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index d796e29..68dd7c8 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -1217,7 +1217,7 @@ static s32 igb_get_pcs_speed_and_duplex_82575(struct e1000_hw *hw, u16 *speed,
u16 *duplex)
{
struct e1000_mac_info *mac = &hw->mac;
- u32 pcs;
+ u32 pcs, status;
/* Set up defaults for the return values of this function */
mac->serdes_has_link = false;
@@ -1238,20 +1238,31 @@ static s32 igb_get_pcs_speed_and_duplex_82575(struct e1000_hw *hw, u16 *speed,
mac->serdes_has_link = true;
/* Detect and store PCS speed */
- if (pcs & E1000_PCS_LSTS_SPEED_1000) {
+ if (pcs & E1000_PCS_LSTS_SPEED_1000)
*speed = SPEED_1000;
- } else if (pcs & E1000_PCS_LSTS_SPEED_100) {
+ else if (pcs & E1000_PCS_LSTS_SPEED_100)
*speed = SPEED_100;
- } else {
+ else
*speed = SPEED_10;
- }
/* Detect and store PCS duplex */
- if (pcs & E1000_PCS_LSTS_DUPLEX_FULL) {
+ if (pcs & E1000_PCS_LSTS_DUPLEX_FULL)
*duplex = FULL_DUPLEX;
- } else {
+ else
*duplex = HALF_DUPLEX;
+
+ /* Check if it is an I354 2.5Gb backplane connection. */
+ if (mac->type == e1000_i354) {
+ status = rd32(E1000_STATUS);
+ if ((status & E1000_STATUS_2P5_SKU) &&
+ !(status & E1000_STATUS_2P5_SKU_OVER)) {
+ *speed = SPEED_2500;
+ *duplex = FULL_DUPLEX;
+ hw_dbg("2500 Mbs, ");
+ hw_dbg("Full Duplex\n");
+ }
}
+
}
return 0;
diff --git a/drivers/net/ethernet/intel/igb/e1000_mac.c b/drivers/net/ethernet/intel/igb/e1000_mac.c
index bab556a..f0dfd41 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mac.c
+++ b/drivers/net/ethernet/intel/igb/e1000_mac.c
@@ -1171,17 +1171,6 @@ s32 igb_get_speed_and_duplex_copper(struct e1000_hw *hw, u16 *speed,
hw_dbg("Half Duplex\n");
}
- /* Check if it is an I354 2.5Gb backplane connection. */
- if (hw->mac.type == e1000_i354) {
- if ((status & E1000_STATUS_2P5_SKU) &&
- !(status & E1000_STATUS_2P5_SKU_OVER)) {
- *speed = SPEED_2500;
- *duplex = FULL_DUPLEX;
- hw_dbg("2500 Mbs, ");
- hw_dbg("Full Duplex\n");
- }
- }
-
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [net-next 5/9] igb: No PHPM support in i354 devices
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
PHY Power Management does not exist for i354 device. So, there is no
need to read and write this register or clear go link Disconnect bit,
which could cause a lot of issues.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index b0b33a1..d796e29 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -1421,11 +1421,18 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw)
ctrl &= ~(E1000_CTRL_FRCSPD | E1000_CTRL_FRCDPX);
wr32(E1000_CTRL, ctrl);
- /* Clear Go Link Disconnect bit */
- if (hw->mac.type >= e1000_82580) {
+ /* Clear Go Link Disconnect bit on supported devices */
+ switch (hw->mac.type) {
+ case e1000_82580:
+ case e1000_i350:
+ case e1000_i210:
+ case e1000_i211:
phpm_reg = rd32(E1000_82580_PHY_POWER_MGMT);
phpm_reg &= ~E1000_82580_PM_GO_LINKD;
wr32(E1000_82580_PHY_POWER_MGMT, phpm_reg);
+ break;
+ default:
+ break;
}
ret_val = igb_setup_serdes_link_82575(hw);
--
1.8.3.1
^ permalink raw reply related
* [net-next 4/9] igb: M88E1543 PHY downshift implementation
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
This patch implements downshift mechanism for M88E1543 PHY, so that
downshift is disabled first during link setup process, and later enabled
if we are master and downshift link is negotiated. Also cleaned up
return code implementation.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_phy.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 5adccbc..e726675 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -731,15 +731,13 @@ s32 igb_copper_link_setup_m88_gen2(struct e1000_hw *hw)
s32 ret_val;
u16 phy_data;
- if (phy->reset_disable) {
- ret_val = 0;
- goto out;
- }
+ if (phy->reset_disable)
+ return 0;
/* Enable CRS on Tx. This must be set for half-duplex operation. */
ret_val = phy->ops.read_reg(hw, M88E1000_PHY_SPEC_CTRL, &phy_data);
if (ret_val)
- goto out;
+ return ret_val;
/* Options:
* MDI/MDI-X = 0 (default)
@@ -780,23 +778,36 @@ s32 igb_copper_link_setup_m88_gen2(struct e1000_hw *hw)
phy_data |= M88E1000_PSCR_POLARITY_REVERSAL;
/* Enable downshift and setting it to X6 */
+ if (phy->id == M88E1543_E_PHY_ID) {
+ phy_data &= ~I347AT4_PSCR_DOWNSHIFT_ENABLE;
+ ret_val =
+ phy->ops.write_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data);
+ if (ret_val)
+ return ret_val;
+
+ ret_val = igb_phy_sw_reset(hw);
+ if (ret_val) {
+ hw_dbg("Error committing the PHY changes\n");
+ return ret_val;
+ }
+ }
+
phy_data &= ~I347AT4_PSCR_DOWNSHIFT_MASK;
phy_data |= I347AT4_PSCR_DOWNSHIFT_6X;
phy_data |= I347AT4_PSCR_DOWNSHIFT_ENABLE;
ret_val = phy->ops.write_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data);
if (ret_val)
- goto out;
+ return ret_val;
/* Commit the changes. */
ret_val = igb_phy_sw_reset(hw);
if (ret_val) {
hw_dbg("Error committing the PHY changes\n");
- goto out;
+ return ret_val;
}
-out:
- return ret_val;
+ return 0;
}
/**
--
1.8.3.1
^ permalink raw reply related
* [net-next 3/9] igb: New PHY_ID for i354 device
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
This patch changes PHY_ID for i354 device, now using M88E1543
instead of M88E1545.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 18 +++++++++---------
drivers/net/ethernet/intel/igb/e1000_defines.h | 8 ++++----
drivers/net/ethernet/intel/igb/e1000_phy.c | 2 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index d398fad..b0b33a1 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -176,7 +176,7 @@ static s32 igb_init_phy_params_82575(struct e1000_hw *hw)
/* Verify phy id and set remaining function pointers */
switch (phy->id) {
- case M88E1545_E_PHY_ID:
+ case M88E1543_E_PHY_ID:
case I347AT4_E_PHY_ID:
case M88E1112_E_PHY_ID:
case M88E1111_I_PHY_ID:
@@ -1448,7 +1448,7 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw)
switch (hw->phy.id) {
case I347AT4_E_PHY_ID:
case M88E1112_E_PHY_ID:
- case M88E1545_E_PHY_ID:
+ case M88E1543_E_PHY_ID:
case I210_I_PHY_ID:
ret_val = igb_copper_link_setup_m88_gen2(hw);
break;
@@ -2477,28 +2477,28 @@ s32 igb_set_eee_i354(struct e1000_hw *hw)
u16 phy_data;
if ((hw->phy.media_type != e1000_media_type_copper) ||
- (phy->id != M88E1545_E_PHY_ID))
+ (phy->id != M88E1543_E_PHY_ID))
goto out;
if (!hw->dev_spec._82575.eee_disable) {
/* Switch to PHY page 18. */
- ret_val = phy->ops.write_reg(hw, E1000_M88E1545_PAGE_ADDR, 18);
+ ret_val = phy->ops.write_reg(hw, E1000_M88E1543_PAGE_ADDR, 18);
if (ret_val)
goto out;
- ret_val = phy->ops.read_reg(hw, E1000_M88E1545_EEE_CTRL_1,
+ ret_val = phy->ops.read_reg(hw, E1000_M88E1543_EEE_CTRL_1,
&phy_data);
if (ret_val)
goto out;
- phy_data |= E1000_M88E1545_EEE_CTRL_1_MS;
- ret_val = phy->ops.write_reg(hw, E1000_M88E1545_EEE_CTRL_1,
+ phy_data |= E1000_M88E1543_EEE_CTRL_1_MS;
+ ret_val = phy->ops.write_reg(hw, E1000_M88E1543_EEE_CTRL_1,
phy_data);
if (ret_val)
goto out;
/* Return the PHY to page 0. */
- ret_val = phy->ops.write_reg(hw, E1000_M88E1545_PAGE_ADDR, 0);
+ ret_val = phy->ops.write_reg(hw, E1000_M88E1543_PAGE_ADDR, 0);
if (ret_val)
goto out;
@@ -2549,7 +2549,7 @@ s32 igb_get_eee_status_i354(struct e1000_hw *hw, bool *status)
/* Check if EEE is supported on this device. */
if ((hw->phy.media_type != e1000_media_type_copper) ||
- (phy->id != M88E1545_E_PHY_ID))
+ (phy->id != M88E1543_E_PHY_ID))
goto out;
ret_val = igb_read_xmdio_reg(hw, E1000_PCS_STATUS_ADDR_I354,
diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h
index 60559af..978eca3 100644
--- a/drivers/net/ethernet/intel/igb/e1000_defines.h
+++ b/drivers/net/ethernet/intel/igb/e1000_defines.h
@@ -787,7 +787,7 @@
#define I350_I_PHY_ID 0x015403B0
#define M88_VENDOR 0x0141
#define I210_I_PHY_ID 0x01410C00
-#define M88E1545_E_PHY_ID 0x01410EA0
+#define M88E1543_E_PHY_ID 0x01410EA0
/* M88E1000 Specific Registers */
#define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */
@@ -909,9 +909,9 @@
#define E1000_EEE_LP_ADV_DEV_I210 7 /* EEE LP Adv Device */
#define E1000_EEE_LP_ADV_ADDR_I210 61 /* EEE LP Adv Register */
#define E1000_MMDAC_FUNC_DATA 0x4000 /* Data, no post increment */
-#define E1000_M88E1545_PAGE_ADDR 0x16 /* Page Offset Register */
-#define E1000_M88E1545_EEE_CTRL_1 0x0
-#define E1000_M88E1545_EEE_CTRL_1_MS 0x0001 /* EEE Master/Slave */
+#define E1000_M88E1543_PAGE_ADDR 0x16 /* Page Offset Register */
+#define E1000_M88E1543_EEE_CTRL_1 0x0
+#define E1000_M88E1543_EEE_CTRL_1_MS 0x0001 /* EEE Master/Slave */
#define E1000_EEE_ADV_DEV_I354 7
#define E1000_EEE_ADV_ADDR_I354 60
#define E1000_EEE_ADV_100_SUPPORTED (1 << 1) /* 100BaseTx EEE Supported */
diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 6046194..5adccbc 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -1806,7 +1806,7 @@ s32 igb_get_cable_length_m88_gen2(struct e1000_hw *hw)
phy->max_cable_length = phy_data / (is_cm ? 100 : 1);
phy->cable_length = phy_data / (is_cm ? 100 : 1);
break;
- case M88E1545_E_PHY_ID:
+ case M88E1543_E_PHY_ID:
case I347AT4_E_PHY_ID:
/* Remember the original page select and set it to 7 */
ret_val = phy->ops.read_reg(hw, I347AT4_PAGE_SELECT,
--
1.8.3.1
^ permalink raw reply related
* [net-next 2/9] igb: Implementation of 1-sec delay for i210 devices
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Akeem G Abodunrin, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
This patch adds 1 sec delay mechanism to i210 device family, in order
to avoid erroneous link issue with the link partner.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb.h | 3 +++
drivers/net/ethernet/intel/igb/igb_main.c | 32 ++++++++++++++++++++++++++++---
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index c1fae7a..6807b09 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -448,6 +448,8 @@ struct igb_adapter {
struct i2c_client *i2c_client;
u32 rss_indir_tbl_init;
u8 rss_indir_tbl[IGB_RETA_SIZE];
+
+ unsigned long link_check_timeout;
};
#define IGB_FLAG_HAS_MSI (1 << 0)
@@ -459,6 +461,7 @@ struct igb_adapter {
#define IGB_FLAG_RSS_FIELD_IPV4_UDP (1 << 6)
#define IGB_FLAG_RSS_FIELD_IPV6_UDP (1 << 7)
#define IGB_FLAG_WOL_SUPPORTED (1 << 8)
+#define IGB_FLAG_NEED_LINK_UPDATE (1 << 9)
/* DMA Coalescing defines */
#define IGB_MIN_TXPBSIZE 20408
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 78f49cf..b209ca5 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1671,6 +1671,8 @@ void igb_down(struct igb_adapter *adapter)
igb_irq_disable(adapter);
+ adapter->flags &= ~IGB_FLAG_NEED_LINK_UPDATE;
+
for (i = 0; i < adapter->num_q_vectors; i++) {
napi_synchronize(&(adapter->q_vector[i]->napi));
napi_disable(&(adapter->q_vector[i]->napi));
@@ -3886,6 +3888,17 @@ bool igb_has_link(struct igb_adapter *adapter)
break;
}
+ if (((hw->mac.type == e1000_i210) ||
+ (hw->mac.type == e1000_i211)) &&
+ (hw->phy.id == I210_I_PHY_ID)) {
+ if (!netif_carrier_ok(adapter->netdev)) {
+ adapter->flags &= ~IGB_FLAG_NEED_LINK_UPDATE;
+ } else if (!(adapter->flags & IGB_FLAG_NEED_LINK_UPDATE)) {
+ adapter->flags |= IGB_FLAG_NEED_LINK_UPDATE;
+ adapter->link_check_timeout = jiffies;
+ }
+ }
+
return link_active;
}
@@ -3930,6 +3943,14 @@ static void igb_watchdog_task(struct work_struct *work)
int i;
link = igb_has_link(adapter);
+
+ if (adapter->flags & IGB_FLAG_NEED_LINK_UPDATE) {
+ if (time_after(jiffies, (adapter->link_check_timeout + HZ)))
+ adapter->flags &= ~IGB_FLAG_NEED_LINK_UPDATE;
+ else
+ link = false;
+ }
+
if (link) {
/* Cancel scheduled suspend requests. */
pm_runtime_resume(netdev->dev.parent);
@@ -4054,9 +4075,14 @@ static void igb_watchdog_task(struct work_struct *work)
igb_ptp_rx_hang(adapter);
/* Reset the timer */
- if (!test_bit(__IGB_DOWN, &adapter->state))
- mod_timer(&adapter->watchdog_timer,
- round_jiffies(jiffies + 2 * HZ));
+ if (!test_bit(__IGB_DOWN, &adapter->state)) {
+ if (adapter->flags & IGB_FLAG_NEED_LINK_UPDATE)
+ mod_timer(&adapter->watchdog_timer,
+ round_jiffies(jiffies + HZ));
+ else
+ mod_timer(&adapter->watchdog_timer,
+ round_jiffies(jiffies + 2 * HZ));
+ }
}
enum latency_range {
--
1.8.3.1
^ permalink raw reply related
* [net-next 1/9] igb: Don't look for a PBA in the iNVM when flashless
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Todd Fujinaka, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1378300136-26003-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Todd Fujinaka <todd.fujinaka@intel.com>
When a part is flashless, do not look for a PBA in the iNVM.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index df33c4b..78f49cf 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2367,7 +2367,14 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
"Width x1" : "unknown"), netdev->dev_addr);
}
- ret_val = igb_read_part_string(hw, part_str, E1000_PBANUM_LENGTH);
+ if ((hw->mac.type >= e1000_i210 ||
+ igb_get_flash_presence_i210(hw))) {
+ ret_val = igb_read_part_string(hw, part_str,
+ E1000_PBANUM_LENGTH);
+ } else {
+ ret_val = -E1000_ERR_INVM_VALUE_NOT_FOUND;
+ }
+
if (ret_val)
strcpy(part_str, "Unknown");
dev_info(&pdev->dev, "%s: PBA No: %s\n", netdev->name, part_str);
--
1.8.3.1
^ permalink raw reply related
* [net-next 0/9][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2013-09-04 13:08 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to igb only.
Todd provides a fix for igb to not look for a PBA in the iNVM on
devices that are flashless.
Akeem provides igb patches to add a new PHY id for i354, as well as
a couple of patches to implement the new PHY id. He also provides
several patches to correctly report the appropriate media type as
well as correctly report advertised/supported link for i354 devices.
Lastly Akeem implements a 1 second delay mechanism for i210 devices
to avoid erroneous link issue with the link partner.
The following are changes since commit c995ae2259ee36caf48bbfacf40111998dacd4af:
tcp: Change return value of tcp_rcv_established()
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Akeem G Abodunrin (8):
igb: Implementation of 1-sec delay for i210 devices
igb: New PHY_ID for i354 device
igb: M88E1543 PHY downshift implementation
igb: No PHPM support in i354 devices
igb: Support to get 2_5G link status for appropriate media type
igb: Get speed and duplex for 1G non_copper devices
igb: Implementation to report advertised/supported link on i354
devices
igb: Update version number
Todd Fujinaka (1):
igb: Don't look for a PBA in the iNVM when flashless
drivers/net/ethernet/intel/igb/e1000_82575.c | 81 ++++++++++++++++++++------
drivers/net/ethernet/intel/igb/e1000_defines.h | 8 +--
drivers/net/ethernet/intel/igb/e1000_mac.c | 11 ----
drivers/net/ethernet/intel/igb/e1000_phy.c | 31 ++++++----
drivers/net/ethernet/intel/igb/igb.h | 3 +
drivers/net/ethernet/intel/igb/igb_ethtool.c | 26 +++++----
drivers/net/ethernet/intel/igb/igb_main.c | 43 ++++++++++++--
7 files changed, 143 insertions(+), 60 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH] ethernet/arc/arc_emac: optimize the Tx/Tx-reclaim paths a bit
From: Vineet Gupta @ 2013-09-04 13:03 UTC (permalink / raw)
To: netdev
Cc: Vineet Gupta, Alexey Brodkin, David S. Miller, Francois Romieu,
linux-kernel, arc-linux-dev
This came out of staring at code due to recent performance fix.
* TX BD reclaim can call netif_wake_queue() once, outside the loop if
one/more BDs were freed, NO need to do this each iteration.
* TX need not look at next BD to stop the netif queue. It rather be done
in the next tx call, when it actually fails as the queue seldom gets
full but the check nevertheless needs to be done for each packet Tx.
Profiled this under heavy traffic (big tar file cp, LMBench betworking
tests) and saw not a single hit to that code.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Francois Romieu <romieu@fr.zoreil.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: arc-linux-dev@synopsys.com
---
drivers/net/ethernet/arc/emac_main.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 9e16014..a3dd048 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -179,10 +179,10 @@ static void arc_emac_tx_clean(struct net_device *ndev)
txbd->info = 0;
*txbd_dirty = (*txbd_dirty + 1) % TX_BD_NUM;
-
- if (netif_queue_stopped(ndev))
- netif_wake_queue(ndev);
}
+
+ if (i && netif_queue_stopped(ndev))
+ netif_wake_queue(ndev);
}
/**
@@ -570,13 +570,6 @@ static int arc_emac_tx(struct sk_buff *skb, struct net_device *ndev)
/* Increment index to point to the next BD */
*txbd_curr = (*txbd_curr + 1) % TX_BD_NUM;
- /* Get "info" of the next BD */
- info = &priv->txbd[*txbd_curr].info;
-
- /* Check if if Tx BD ring is full - next BD is still owned by EMAC */
- if (unlikely((le32_to_cpu(*info) & OWN_MASK) == FOR_EMAC))
- netif_stop_queue(ndev);
-
arc_reg_set(priv, R_STATUS, TXPL_MASK);
skb_tx_timestamp(skb);
--
1.8.1.2
^ permalink raw reply related
* [PATCH net-next v2] qlcnic: use standard NAPI weights
From: Michal Schmidt @ 2013-09-04 13:03 UTC (permalink / raw)
To: David Miller
Cc: Himanshu Madhani, netdev, Eric Dumazet, Rajesh Borundia,
Shahed Shaikh, Jitendra Kalsaria, Sony Chacko,
Sucheta Chakraborty, Dept-Eng Linux Driver
In-Reply-To: <ADFE82A996F10145934E45547759F763311D183F@avmb3.qlogic.org>
Since commit 82dc3c63 ("net: introduce NAPI_POLL_WEIGHT")
netif_napi_add() produces an error message if a NAPI poll weight
greater than 64 is requested.
qlcnic requests the weight as large as 256 for some of its rings, and
smaller values for other rings. For instance in qlcnic_82xx_napi_add()
I think the intention was to give the tx+rx ring a bigger weight than
to rx-only rings, but it's actually doing the opposite. So I'm assuming
the weights do not really matter much.
Just use the standard NAPI weights for all rings.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Acked-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
---
v2: Rebased on top of the current qlcnic in net-next.
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 1 -
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 30 +++++++++++---------------
2 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 4615960..88349b8 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -946,7 +946,6 @@ struct qlcnic_ipaddr {
#define QLCNIC_PCI_REG_MSIX_TBL 0x44
#define QLCNIC_MSIX_TBL_PGSIZE 4096
-#define QLCNIC_NETDEV_WEIGHT 128
#define QLCNIC_ADAPTER_UP_MAGIC 777
#define __QLCNIC_FW_ATTACHED 0
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index 8d06f88..b7b245b 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -1458,7 +1458,7 @@ void qlcnic_82xx_process_rcv_ring_diag(struct qlcnic_host_sds_ring *sds_ring)
int qlcnic_82xx_napi_add(struct qlcnic_adapter *adapter,
struct net_device *netdev)
{
- int ring, max_sds_rings;
+ int ring;
struct qlcnic_host_sds_ring *sds_ring;
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
struct qlcnic_host_tx_ring *tx_ring;
@@ -1466,25 +1466,22 @@ int qlcnic_82xx_napi_add(struct qlcnic_adapter *adapter,
if (qlcnic_alloc_sds_rings(recv_ctx, adapter->max_sds_rings))
return -ENOMEM;
- max_sds_rings = adapter->max_sds_rings;
-
for (ring = 0; ring < adapter->max_sds_rings; ring++) {
sds_ring = &recv_ctx->sds_rings[ring];
if (qlcnic_check_multi_tx(adapter) &&
!adapter->ahw->diag_test &&
(adapter->max_drv_tx_rings > 1)) {
netif_napi_add(netdev, &sds_ring->napi, qlcnic_rx_poll,
- QLCNIC_NETDEV_WEIGHT * 2);
+ NAPI_POLL_WEIGHT);
} else {
if (ring == (adapter->max_sds_rings - 1))
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_poll,
- QLCNIC_NETDEV_WEIGHT /
- max_sds_rings);
+ NAPI_POLL_WEIGHT);
else
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_rx_poll,
- QLCNIC_NETDEV_WEIGHT * 2);
+ NAPI_POLL_WEIGHT);
}
}
@@ -1497,7 +1494,7 @@ int qlcnic_82xx_napi_add(struct qlcnic_adapter *adapter,
for (ring = 0; ring < adapter->max_drv_tx_rings; ring++) {
tx_ring = &adapter->tx_ring[ring];
netif_napi_add(netdev, &tx_ring->napi, qlcnic_tx_poll,
- QLCNIC_NETDEV_WEIGHT);
+ NAPI_POLL_WEIGHT);
}
}
@@ -1963,7 +1960,7 @@ void qlcnic_83xx_napi_disable(struct qlcnic_adapter *adapter)
int qlcnic_83xx_napi_add(struct qlcnic_adapter *adapter,
struct net_device *netdev)
{
- int ring, max_sds_rings, temp;
+ int ring;
struct qlcnic_host_sds_ring *sds_ring;
struct qlcnic_host_tx_ring *tx_ring;
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
@@ -1971,25 +1968,22 @@ int qlcnic_83xx_napi_add(struct qlcnic_adapter *adapter,
if (qlcnic_alloc_sds_rings(recv_ctx, adapter->max_sds_rings))
return -ENOMEM;
- max_sds_rings = adapter->max_sds_rings;
for (ring = 0; ring < adapter->max_sds_rings; ring++) {
sds_ring = &recv_ctx->sds_rings[ring];
if (adapter->flags & QLCNIC_MSIX_ENABLED) {
- if (!(adapter->flags & QLCNIC_TX_INTR_SHARED)) {
+ if (!(adapter->flags & QLCNIC_TX_INTR_SHARED))
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_83xx_rx_poll,
- QLCNIC_NETDEV_WEIGHT * 2);
- } else {
- temp = QLCNIC_NETDEV_WEIGHT / max_sds_rings;
+ NAPI_POLL_WEIGHT);
+ else
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_83xx_msix_sriov_vf_poll,
- temp);
- }
+ NAPI_POLL_WEIGHT);
} else {
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_83xx_poll,
- QLCNIC_NETDEV_WEIGHT / max_sds_rings);
+ NAPI_POLL_WEIGHT);
}
}
@@ -2004,7 +1998,7 @@ int qlcnic_83xx_napi_add(struct qlcnic_adapter *adapter,
tx_ring = &adapter->tx_ring[ring];
netif_napi_add(netdev, &tx_ring->napi,
qlcnic_83xx_msix_tx_poll,
- QLCNIC_NETDEV_WEIGHT);
+ NAPI_POLL_WEIGHT);
}
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/4] netfilter: SYNPROXY: let unrelated packets continue
From: Pablo Neira Ayuso @ 2013-09-04 13:00 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1378299625-4638-1-git-send-email-pablo@netfilter.org>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Packets reaching SYNPROXY were default dropped, as they were most
likely invalid (given the recommended state matching). This
patch, changes SYNPROXY target to let packets, not consumed,
continue being processed by the stack.
This will be more in line other target modules. As it will allow
more flexible configurations of handling, logging or matching on
packets in INVALID states.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/ipt_SYNPROXY.c | 8 ++++++--
net/ipv6/netfilter/ip6t_SYNPROXY.c | 8 ++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_SYNPROXY.c b/net/ipv4/netfilter/ipt_SYNPROXY.c
index 90e489e..67e17dc 100644
--- a/net/ipv4/netfilter/ipt_SYNPROXY.c
+++ b/net/ipv4/netfilter/ipt_SYNPROXY.c
@@ -285,11 +285,15 @@ synproxy_tg4(struct sk_buff *skb, const struct xt_action_param *par)
XT_SYNPROXY_OPT_ECN);
synproxy_send_client_synack(skb, th, &opts);
- } else if (th->ack && !(th->fin || th->rst || th->syn))
+ return NF_DROP;
+
+ } else if (th->ack && !(th->fin || th->rst || th->syn)) {
/* ACK from client */
synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
+ return NF_DROP;
+ }
- return NF_DROP;
+ return XT_CONTINUE;
}
static unsigned int ipv4_synproxy_hook(unsigned int hooknum,
diff --git a/net/ipv6/netfilter/ip6t_SYNPROXY.c b/net/ipv6/netfilter/ip6t_SYNPROXY.c
index a5af0bf..19cfea8 100644
--- a/net/ipv6/netfilter/ip6t_SYNPROXY.c
+++ b/net/ipv6/netfilter/ip6t_SYNPROXY.c
@@ -300,11 +300,15 @@ synproxy_tg6(struct sk_buff *skb, const struct xt_action_param *par)
XT_SYNPROXY_OPT_ECN);
synproxy_send_client_synack(skb, th, &opts);
- } else if (th->ack && !(th->fin || th->rst || th->syn))
+ return NF_DROP;
+
+ } else if (th->ack && !(th->fin || th->rst || th->syn)) {
/* ACK from client */
synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
+ return NF_DROP;
+ }
- return NF_DROP;
+ return XT_CONTINUE;
}
static unsigned int ipv6_synproxy_hook(unsigned int hooknum,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/4] netfilter: synproxy_core: fix warning in __nf_ct_ext_add_length()
From: Pablo Neira Ayuso @ 2013-09-04 13:00 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1378299625-4638-1-git-send-email-pablo@netfilter.org>
From: Patrick McHardy <kaber@trash.net>
With CONFIG_NETFILTER_DEBUG we get the following warning during SYNPROXY init:
[ 80.558906] WARNING: CPU: 1 PID: 4833 at net/netfilter/nf_conntrack_extend.c:80 __nf_ct_ext_add_length+0x217/0x220 [nf_conntrack]()
The reason is that the conntrack template is set to confirmed before adding
the extension and it is invalid to add extensions to already confirmed
conntracks. Fix by adding the extensions before setting the conntrack to
confirmed.
Reported-by: Jesper Dangaard Brouer <jesper.brouer@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_synproxy_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
index d23dc79..6fd967c 100644
--- a/net/netfilter/nf_synproxy_core.c
+++ b/net/netfilter/nf_synproxy_core.c
@@ -356,12 +356,12 @@ static int __net_init synproxy_net_init(struct net *net)
goto err1;
}
- __set_bit(IPS_TEMPLATE_BIT, &ct->status);
- __set_bit(IPS_CONFIRMED_BIT, &ct->status);
if (!nfct_seqadj_ext_add(ct))
goto err2;
if (!nfct_synproxy_ext_add(ct))
goto err2;
+ __set_bit(IPS_TEMPLATE_BIT, &ct->status);
+ __set_bit(IPS_CONFIRMED_BIT, &ct->status);
snet->tmpl = ct;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/4] netfilter: xt_TCPMSS: correct return value in tcpmss_mangle_packet
From: Pablo Neira Ayuso @ 2013-09-04 13:00 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1378299625-4638-1-git-send-email-pablo@netfilter.org>
From: Phil Oester <kernel@linuxace.com>
In commit b396966c4 (netfilter: xt_TCPMSS: Fix missing fragmentation handling),
I attempted to add safe fragment handling to xt_TCPMSS. However, Andy Padavan
of Project N56U correctly points out that returning XT_CONTINUE in this
function does not work. The callers (tcpmss_tg[46]) expect to receive a value
of 0 in order to return XT_CONTINUE.
Signed-off-by: Phil Oester <kernel@linuxace.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_TCPMSS.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/xt_TCPMSS.c b/net/netfilter/xt_TCPMSS.c
index 6113cc7..cd24290 100644
--- a/net/netfilter/xt_TCPMSS.c
+++ b/net/netfilter/xt_TCPMSS.c
@@ -60,7 +60,7 @@ tcpmss_mangle_packet(struct sk_buff *skb,
/* This is a fragment, no TCP header is available */
if (par->fragoff != 0)
- return XT_CONTINUE;
+ return 0;
if (!skb_make_writable(skb, skb->len))
return -1;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/4] netfilter: more strict TCP flag matching in SYNPROXY
From: Pablo Neira Ayuso @ 2013-09-04 13:00 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1378299625-4638-1-git-send-email-pablo@netfilter.org>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Its seems Patrick missed to incoorporate some of my requested changes
during review v2 of SYNPROXY netfilter module.
Which were, to avoid SYN+ACK packets to enter the path, meant for the
ACK packet from the client (from the 3WHS).
Further there were a bug in ip6t_SYNPROXY.c, for matching SYN packets
that didn't exclude the ACK flag.
Go a step further with SYN packet/flag matching by excluding flags
ACK+FIN+RST, in both IPv4 and IPv6 modules.
The intented usage of SYNPROXY is as follows:
(gracefully describing usage in commit)
iptables -t raw -A PREROUTING -i eth0 -p tcp --dport 80 --syn -j NOTRACK
iptables -A INPUT -i eth0 -p tcp --dport 80 -m state UNTRACKED,INVALID \
-j SYNPROXY --sack-perm --timestamp --mss 1480 --wscale 7 --ecn
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
This does filter SYN flags early, for packets in the UNTRACKED state,
but packets in the INVALID state with other TCP flags could still
reach the module, thus this stricter flag matching is still needed.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/ipt_SYNPROXY.c | 4 ++--
net/ipv6/netfilter/ip6t_SYNPROXY.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_SYNPROXY.c b/net/ipv4/netfilter/ipt_SYNPROXY.c
index 94371db..90e489e 100644
--- a/net/ipv4/netfilter/ipt_SYNPROXY.c
+++ b/net/ipv4/netfilter/ipt_SYNPROXY.c
@@ -269,7 +269,7 @@ synproxy_tg4(struct sk_buff *skb, const struct xt_action_param *par)
synproxy_parse_options(skb, par->thoff, th, &opts);
- if (th->syn && !th->ack) {
+ if (th->syn && !(th->ack || th->fin || th->rst)) {
/* Initial SYN from client */
this_cpu_inc(snet->stats->syn_received);
@@ -285,7 +285,7 @@ synproxy_tg4(struct sk_buff *skb, const struct xt_action_param *par)
XT_SYNPROXY_OPT_ECN);
synproxy_send_client_synack(skb, th, &opts);
- } else if (th->ack && !(th->fin || th->rst))
+ } else if (th->ack && !(th->fin || th->rst || th->syn))
/* ACK from client */
synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
diff --git a/net/ipv6/netfilter/ip6t_SYNPROXY.c b/net/ipv6/netfilter/ip6t_SYNPROXY.c
index 4270a9b..a5af0bf 100644
--- a/net/ipv6/netfilter/ip6t_SYNPROXY.c
+++ b/net/ipv6/netfilter/ip6t_SYNPROXY.c
@@ -284,7 +284,7 @@ synproxy_tg6(struct sk_buff *skb, const struct xt_action_param *par)
synproxy_parse_options(skb, par->thoff, th, &opts);
- if (th->syn) {
+ if (th->syn && !(th->ack || th->fin || th->rst)) {
/* Initial SYN from client */
this_cpu_inc(snet->stats->syn_received);
@@ -300,7 +300,7 @@ synproxy_tg6(struct sk_buff *skb, const struct xt_action_param *par)
XT_SYNPROXY_OPT_ECN);
synproxy_send_client_synack(skb, th, &opts);
- } else if (th->ack && !(th->fin || th->rst))
+ } else if (th->ack && !(th->fin || th->rst || th->syn))
/* ACK from client */
synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/4] netfilter updates for net-next
From: Pablo Neira Ayuso @ 2013-09-04 13:00 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following batch contains:
* Three fixes for the new synproxy target available in your
net-next tree, from Jesper D. Brouer and Patrick McHardy.
* One fix for TCPMSS to correctly handling the fragmentation
case, from Phil Oester. I'll pass this one to -stable.
You can pull this changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
Thanks!
----------------------------------------------------------------
The following changes since commit 5a17a390de7bdbcfff9b8f344273a886ca4cf8bf:
net: make snmp_mib_free static inline (2013-09-02 21:00:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
for you to fetch changes up to 1205e1fa615805c9efa97303b552cf445965752a:
netfilter: xt_TCPMSS: correct return value in tcpmss_mangle_packet (2013-09-04 14:20:03 +0200)
----------------------------------------------------------------
Jesper Dangaard Brouer (2):
netfilter: more strict TCP flag matching in SYNPROXY
netfilter: SYNPROXY: let unrelated packets continue
Patrick McHardy (1):
netfilter: synproxy_core: fix warning in __nf_ct_ext_add_length()
Phil Oester (1):
netfilter: xt_TCPMSS: correct return value in tcpmss_mangle_packet
net/ipv4/netfilter/ipt_SYNPROXY.c | 10 +++++++---
net/ipv6/netfilter/ip6t_SYNPROXY.c | 10 +++++++---
net/netfilter/nf_synproxy_core.c | 4 ++--
net/netfilter/xt_TCPMSS.c | 2 +-
4 files changed, 17 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: migrate direct users to prandom_u32_max
From: Daniel Borkmann @ 2013-09-04 12:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1378299135.7360.109.camel@edumazet-glaptop>
On 09/04/2013 02:52 PM, Eric Dumazet wrote:
> On Wed, 2013-09-04 at 14:37 +0200, Daniel Borkmann wrote:
>> Users that directly use or reimplement what we have in prandom_u32_max()
>> can be migrated for now to use it directly, so that we can reduce code size
>> and avoid reimplementations. That's obvious, follow-up patches could inspect
>> modulo use cases for possible migration as well.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> ---
>> drivers/net/team/team_mode_random.c | 8 +-------
>> include/net/red.h | 2 +-
>> net/802/garp.c | 3 ++-
>> net/802/mrp.c | 3 ++-
>> net/packet/af_packet.c | 2 +-
>> net/sched/sch_choke.c | 8 +-------
>> 6 files changed, 8 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/net/team/team_mode_random.c b/drivers/net/team/team_mode_random.c
>> index 7f032e2..0dbd1eb 100644
>> --- a/drivers/net/team/team_mode_random.c
>> +++ b/drivers/net/team/team_mode_random.c
>> @@ -13,20 +13,14 @@
>> #include <linux/module.h>
>> #include <linux/init.h>
>> #include <linux/skbuff.h>
>> -#include <linux/reciprocal_div.h>
>> #include <linux/if_team.h>
>>
>> -static u32 random_N(unsigned int N)
>> -{
>> - return reciprocal_divide(prandom_u32(), N);
>> -}
>> -
>> static bool rnd_transmit(struct team *team, struct sk_buff *skb)
>> {
>> struct team_port *port;
>> int port_index;
>>
>> - port_index = random_N(team->en_port_count);
>> + port_index = prandom_u32_max(team->en_port_count - 1);
>
>
> Note the random_N(0) gave 0, while prandom_u32_max(0 - 1) can return any
> number in [0 ... ~0U]
Very true, that was stupid. Thanks for catching!
^ permalink raw reply
* Re: [nf-next PATCH] netfilter: SYNPROXY let unrelated packets continue
From: Pablo Neira Ayuso @ 2013-09-04 12:56 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Patrick McHardy, netfilter-devel, netdev, mph, as
In-Reply-To: <20130829101625.14346.41071.stgit@dragon>
On Thu, Aug 29, 2013 at 12:18:46PM +0200, Jesper Dangaard Brouer wrote:
> Packets reaching SYNPROXY were default dropped, as they were most
> likely invalid (given the recommended state matching). This
> patch, changes SYNPROXY target to let packets, not consumed,
> continue being processed by the stack.
>
> This will be more in line other target modules. As it will allow
> more flexible configurations of handling, logging or matching on
> packets in INVALID states.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: migrate direct users to prandom_u32_max
From: Eric Dumazet @ 2013-09-04 12:52 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1378298247-29364-3-git-send-email-dborkman@redhat.com>
On Wed, 2013-09-04 at 14:37 +0200, Daniel Borkmann wrote:
> Users that directly use or reimplement what we have in prandom_u32_max()
> can be migrated for now to use it directly, so that we can reduce code size
> and avoid reimplementations. That's obvious, follow-up patches could inspect
> modulo use cases for possible migration as well.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> drivers/net/team/team_mode_random.c | 8 +-------
> include/net/red.h | 2 +-
> net/802/garp.c | 3 ++-
> net/802/mrp.c | 3 ++-
> net/packet/af_packet.c | 2 +-
> net/sched/sch_choke.c | 8 +-------
> 6 files changed, 8 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/team/team_mode_random.c b/drivers/net/team/team_mode_random.c
> index 7f032e2..0dbd1eb 100644
> --- a/drivers/net/team/team_mode_random.c
> +++ b/drivers/net/team/team_mode_random.c
> @@ -13,20 +13,14 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/skbuff.h>
> -#include <linux/reciprocal_div.h>
> #include <linux/if_team.h>
>
> -static u32 random_N(unsigned int N)
> -{
> - return reciprocal_divide(prandom_u32(), N);
> -}
> -
> static bool rnd_transmit(struct team *team, struct sk_buff *skb)
> {
> struct team_port *port;
> int port_index;
>
> - port_index = random_N(team->en_port_count);
> + port_index = prandom_u32_max(team->en_port_count - 1);
Note the random_N(0) gave 0, while prandom_u32_max(0 - 1) can return any
number in [0 ... ~0U]
^ permalink raw reply
* Re: [PATCH] xen-netback: count number required slots for an skb more carefully
From: Ian Campbell @ 2013-09-04 12:41 UTC (permalink / raw)
To: David Vrabel
Cc: Wei Liu, xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky,
netdev, msw, annie.li
In-Reply-To: <52271DFF.3070008@citrix.com>
On Wed, 2013-09-04 at 12:48 +0100, David Vrabel wrote:
> On 03/09/13 22:53, Wei Liu wrote:
> > On Tue, Sep 03, 2013 at 06:29:50PM +0100, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> When a VM is providing an iSCSI target and the LUN is used by the
> >> backend domain, the generated skbs for direct I/O writes to the disk
> >> have large, multi-page skb->data but no frags.
> >>
> >> With some lengths and starting offsets, xen_netbk_count_skb_slots()
> >> would be one short because the simple calculation of
> >> DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the
> >> decisions made by start_new_rx_buffer() which does not guarantee
> >> responses are fully packed.
> >>
> >> For example, a skb with length < 2 pages but which spans 3 pages would
> >> be counted as requiring 2 slots but would actually use 3 slots.
> >>
> >> skb->data:
> >>
> >> | 1111|222222222222|3333 |
> >>
> >> Fully packed, this would need 2 slots:
> >>
> >> |111122222222|22223333 |
> >>
> >> But because the 2nd page wholy fits into a slot it is not split across
> >> slots and goes into a slot of its own:
> >>
> >> |1111 |222222222222|3333 |
> >>
> >> Miscounting the number of slots means netback may push more responses
> >> than the number of available requests. This will cause the frontend
> >> to get very confused and report "Too many frags/slots". The frontend
> >> never recovers and will eventually BUG.
> >>
> >> Fix this by counting the number of required slots more carefully. In
> >> xen_netbk_count_skb_slots(), more closely follow the algorithm used by
> >> xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which
> >> is the dry-run equivalent of netbk_gop_frag_copy().
> >>
> >
> > Phew! So this is backend miscounting bug. I thought it was a frontend
> > bug so it didn't ring a bell when we had our face-to-face discussion,
> > sorry. :-(
> >
> > This bug was discussed back in July among Annie, Matt, Ian and I. We
> > finally agreed to take Matt's solution. Matt agreed to post final
> > version within a week but obviously he's too busy to do so. I was away
> > so I didn't follow closely. Eventually it fell through the crack. :-(
>
> I think I prefer fixing the counting for backporting to stable kernels.
That's a good argument. I think we should take this patch, or something
very like it, now and then rebase the more complex thing on top.
> Xi's approach of packing the ring differently is a change in frontend
> visible behaviour and seems more risky. e.g., possible performance
> impact so I would like to see some performance analysis of that approach.
Yes.
^ permalink raw reply
* [PATCH net-next v2 1/2] random: add prandom_u32_range and prandom_u32_max helpers
From: Daniel Borkmann @ 2013-09-04 12:37 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Theodore Ts'o, Joe Perches
In-Reply-To: <1378298247-29364-1-git-send-email-dborkman@redhat.com>
We have implemented the same function over and over, so introduce
generic helpers that unify these implementations in order to migrate
such code to use them. Make the API similarly to randomize_range()
for consistency. prandom_u32_range() generates numbers in [start, end]
interval and prandom_u32_max() generates numbers in [0, end] interval.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Joe Perches <joe@perches.com>
Cc: linux-kernel@vger.kernel.org
---
include/linux/random.h | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/linux/random.h b/include/linux/random.h
index 3b9377d..17c91c2 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -8,7 +8,6 @@
#include <uapi/linux/random.h>
-
extern void add_device_randomness(const void *, unsigned int);
extern void add_input_randomness(unsigned int type, unsigned int code,
unsigned int value);
@@ -32,6 +31,36 @@ void prandom_seed(u32 seed);
u32 prandom_u32_state(struct rnd_state *);
void prandom_bytes_state(struct rnd_state *state, void *buf, int nbytes);
+/**
+ * prandom_u32_range - return a random number in interval [start, end]
+ * @start: lower interval endpoint
+ * @end: higher interval endpoint
+ *
+ * Returns a number that is in the given interval:
+ *
+ * [...... <range> .....]
+ * start end
+ *
+ * Callers need to make sure that start <= end. Note that the result
+ * depends on PRNG being well distributed in [0, ~0U] space. Here we
+ * use maximally equidistributed combined Tausworthe generator.
+ */
+static inline u32 prandom_u32_range(u32 start, u32 end)
+{
+ return (u32)(((u64) prandom_u32() * (end + 1 - start)) >> 32) + start;
+}
+
+/**
+ * prandom_u32_max - return a random number in interval [0, max]
+ * @max: higher interval endpoint
+ *
+ * Returns a number that is in interval [0, end].
+ */
+static inline u32 prandom_u32_max(u32 end)
+{
+ return prandom_u32_range(0, end);
+}
+
/*
* Handle minimum values for seeds
*/
--
1.7.11.7
^ permalink raw reply related
* [PATCH net-next v2 2/2] net: migrate direct users to prandom_u32_max
From: Daniel Borkmann @ 2013-09-04 12:37 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
In-Reply-To: <1378298247-29364-1-git-send-email-dborkman@redhat.com>
Users that directly use or reimplement what we have in prandom_u32_max()
can be migrated for now to use it directly, so that we can reduce code size
and avoid reimplementations. That's obvious, follow-up patches could inspect
modulo use cases for possible migration as well.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
drivers/net/team/team_mode_random.c | 8 +-------
include/net/red.h | 2 +-
net/802/garp.c | 3 ++-
net/802/mrp.c | 3 ++-
net/packet/af_packet.c | 2 +-
net/sched/sch_choke.c | 8 +-------
6 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/net/team/team_mode_random.c b/drivers/net/team/team_mode_random.c
index 7f032e2..0dbd1eb 100644
--- a/drivers/net/team/team_mode_random.c
+++ b/drivers/net/team/team_mode_random.c
@@ -13,20 +13,14 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/skbuff.h>
-#include <linux/reciprocal_div.h>
#include <linux/if_team.h>
-static u32 random_N(unsigned int N)
-{
- return reciprocal_divide(prandom_u32(), N);
-}
-
static bool rnd_transmit(struct team *team, struct sk_buff *skb)
{
struct team_port *port;
int port_index;
- port_index = random_N(team->en_port_count);
+ port_index = prandom_u32_max(team->en_port_count - 1);
port = team_get_port_by_index_rcu(team, port_index);
if (unlikely(!port))
goto drop;
diff --git a/include/net/red.h b/include/net/red.h
index ef46058..56f3c0c 100644
--- a/include/net/red.h
+++ b/include/net/red.h
@@ -303,7 +303,7 @@ static inline unsigned long red_calc_qavg(const struct red_parms *p,
static inline u32 red_random(const struct red_parms *p)
{
- return reciprocal_divide(net_random(), p->max_P_reciprocal);
+ return prandom_u32_max(p->max_P_reciprocal - 1);
}
static inline int red_mark_probability(const struct red_parms *p,
diff --git a/net/802/garp.c b/net/802/garp.c
index 5d9630a..b4be421 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -397,7 +397,8 @@ static void garp_join_timer_arm(struct garp_applicant *app)
{
unsigned long delay;
- delay = (u64)msecs_to_jiffies(garp_join_time) * net_random() >> 32;
+ delay = prandom_u32_max(msecs_to_jiffies(garp_join_time) - 1);
+
mod_timer(&app->join_timer, jiffies + delay);
}
diff --git a/net/802/mrp.c b/net/802/mrp.c
index 1eb05d8..1a08ae7 100644
--- a/net/802/mrp.c
+++ b/net/802/mrp.c
@@ -578,7 +578,8 @@ static void mrp_join_timer_arm(struct mrp_applicant *app)
{
unsigned long delay;
- delay = (u64)msecs_to_jiffies(mrp_join_time) * net_random() >> 32;
+ delay = prandom_u32_max(msecs_to_jiffies(mrp_join_time) - 1);
+
mod_timer(&app->join_timer, jiffies + delay);
}
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2e8286b..1c1ccf9 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1162,7 +1162,7 @@ static unsigned int fanout_demux_rnd(struct packet_fanout *f,
struct sk_buff *skb,
unsigned int num)
{
- return reciprocal_divide(prandom_u32(), num);
+ return prandom_u32_max(num - 1);
}
static unsigned int fanout_demux_rollover(struct packet_fanout *f,
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index ef53ab8..7a73fbf 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -77,12 +77,6 @@ struct choke_sched_data {
struct sk_buff **tab;
};
-/* deliver a random number between 0 and N - 1 */
-static u32 random_N(unsigned int N)
-{
- return reciprocal_divide(prandom_u32(), N);
-}
-
/* number of elements in queue including holes */
static unsigned int choke_len(const struct choke_sched_data *q)
{
@@ -233,7 +227,7 @@ static struct sk_buff *choke_peek_random(const struct choke_sched_data *q,
int retrys = 3;
do {
- *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
+ *pidx = (q->head + prandom_u32_max(choke_len(q) - 1)) & q->tab_mask;
skb = q->tab[*pidx];
if (skb)
return skb;
--
1.7.11.7
^ permalink raw reply related
* [PATCH net-next v2 0/2] prandom_u32_range, prandom_u32_max helpers
From: Daniel Borkmann @ 2013-09-04 12:37 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
v1->v2:
- migrated api to random.h, ccing lkml
- dropped second patch for now
Daniel Borkmann (2):
random: add prandom_u32_range and prandom_u32_max helpers
net: migrate direct users to prandom_u32_max
drivers/net/team/team_mode_random.c | 8 +-------
include/linux/random.h | 31 ++++++++++++++++++++++++++++++-
include/net/red.h | 2 +-
net/802/garp.c | 3 ++-
net/802/mrp.c | 3 ++-
net/packet/af_packet.c | 2 +-
net/sched/sch_choke.c | 8 +-------
7 files changed, 38 insertions(+), 19 deletions(-)
--
1.7.11.7
^ 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