* [PATCH net-next 09/14] i40e: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++-------
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++--------
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index de664631c807..a0bee83ab2de 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7002,20 +7002,16 @@ static int i40e_setup_misc_vector(struct i40e_pf *pf)
**/
static int i40e_config_rss(struct i40e_pf *pf)
{
- /* Set of random keys generated using kernel random number generator */
- static const u32 seed[I40E_PFQF_HKEY_MAX_INDEX + 1] = {0x41b01687,
- 0x183cfd8c, 0xce880440, 0x580cbc3c, 0x35897377,
- 0x328b25e1, 0x4fa98922, 0xb7d90c14, 0xd5bad70d,
- 0xcd15a2c1, 0xe8580225, 0x4a1e9d11, 0xfe5731be};
+ u32 rss_key[I40E_PFQF_HKEY_MAX_INDEX + 1];
struct i40e_hw *hw = &pf->hw;
u32 lut = 0;
int i, j;
u64 hena;
u32 reg_val;
- /* Fill out hash function seed */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
- wr32(hw, I40E_PFQF_HKEY(i), seed[i]);
+ wr32(hw, I40E_PFQF_HKEY(i), rss_key[i]);
/* By default we enable TCP/UDP with IPv4/IPv6 ptypes */
hena = (u64)rd32(hw, I40E_PFQF_HENA(0)) |
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index f0d07ad54198..489227891ffb 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1434,18 +1434,12 @@ static int next_queue(struct i40evf_adapter *adapter, int j)
**/
static void i40evf_configure_rss(struct i40evf_adapter *adapter)
{
+ u32 rss_key[I40E_VFQF_HKEY_MAX_INDEX + 1];
struct i40e_hw *hw = &adapter->hw;
u32 lut = 0;
int i, j;
u64 hena;
- /* Set of random keys generated using kernel random number generator */
- static const u32 seed[I40E_VFQF_HKEY_MAX_INDEX + 1] = {
- 0x794221b4, 0xbca0c5ab, 0x6cd5ebd9, 0x1ada6127,
- 0x983b3aa1, 0x1c4e71eb, 0x7f6328b2, 0xfcdc0da0,
- 0xc135cafa, 0x7a6f7e2d, 0xe7102d28, 0x163cd12e,
- 0x4954b126 };
-
/* No RSS for single queue. */
if (adapter->num_active_queues == 1) {
wr32(hw, I40E_VFQF_HENA(0), 0);
@@ -1454,8 +1448,9 @@ static void i40evf_configure_rss(struct i40evf_adapter *adapter)
}
/* Hash type is configured by the PF - we just supply the key */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
- wr32(hw, I40E_VFQF_HKEY(i), seed[i]);
+ wr32(hw, I40E_VFQF_HKEY(i), rss_key[i]);
/* Enable PCTYPES for RSS, TCP/UDP with IPv4/IPv6 */
hena = I40E_DEFAULT_RSS_HENA;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 10/14] igb: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 1e35fae7a62b..b0e12e7c4a3d 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3372,14 +3372,11 @@ static void igb_setup_mrqc(struct igb_adapter *adapter)
struct e1000_hw *hw = &adapter->hw;
u32 mrqc, rxcsum;
u32 j, num_rx_queues;
- static const u32 rsskey[10] = { 0xDA565A6D, 0xC20E5B25, 0x3D256741,
- 0xB08FA343, 0xCB2BCAD0, 0xB4307BAE,
- 0xA32DCB77, 0x0CF23080, 0x3BB7426A,
- 0xFA01ACBE };
+ u32 rss_key[10];
- /* Fill out hash function seeds */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (j = 0; j < 10; j++)
- wr32(E1000_RSSRK(j), rsskey[j]);
+ wr32(E1000_RSSRK(j), rss_key[j]);
num_rx_queues = adapter->rss_queues;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 11/14] ixgbe: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index f5fcba4f9d21..932f77961d66 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -3243,10 +3243,8 @@ static void ixgbe_setup_reta(struct ixgbe_adapter *adapter, const u32 *seed)
static void ixgbe_setup_mrqc(struct ixgbe_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- static const u32 seed[10] = { 0xE291D73D, 0x1805EC6C, 0x2A94B30D,
- 0xA54F2BEC, 0xEA49AF7C, 0xE214AD3D, 0xB855AABE,
- 0x6A3E67EA, 0x14364D17, 0x3BED200D};
u32 mrqc = 0, rss_field = 0;
+ u32 rss_key[10];
u32 rxcsum;
/* Disable indicating checksum in descriptor, enables RSS hash */
@@ -3290,7 +3288,8 @@ static void ixgbe_setup_mrqc(struct ixgbe_adapter *adapter)
if (adapter->flags2 & IXGBE_FLAG2_RSS_FIELD_IPV6_UDP)
rss_field |= IXGBE_MRQC_RSS_FIELD_IPV6_UDP;
- ixgbe_setup_reta(adapter, seed);
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
+ ixgbe_setup_reta(adapter, rss_key);
mrqc |= rss_field;
IXGBE_WRITE_REG(hw, IXGBE_MRQC, mrqc);
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 12/14] mlx4: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Also provide ethtool -x support to fetch RSS key
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 9 ++++++++-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +-----
include/linux/mlx4/qp.h | 4 +++-
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 6c643230a5ed..710cf309962a 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -973,6 +973,11 @@ static u32 mlx4_en_get_rxfh_indir_size(struct net_device *dev)
return priv->rx_ring_num;
}
+static u32 mlx4_en_get_rxfh_key_size(struct net_device *netdev)
+{
+ return MLX4_EN_RSS_KEY_SIZE;
+}
+
static int mlx4_en_get_rxfh(struct net_device *dev, u32 *ring_index, u8 *key)
{
struct mlx4_en_priv *priv = netdev_priv(dev);
@@ -988,7 +993,8 @@ static int mlx4_en_get_rxfh(struct net_device *dev, u32 *ring_index, u8 *key)
ring_index[n] = rss_map->qps[n % rss_rings].qpn -
rss_map->base_qpn;
}
-
+ if (key)
+ netdev_rss_key_fill(key, MLX4_EN_RSS_KEY_SIZE);
return err;
}
@@ -1799,6 +1805,7 @@ const struct ethtool_ops mlx4_en_ethtool_ops = {
.get_rxnfc = mlx4_en_get_rxnfc,
.set_rxnfc = mlx4_en_set_rxnfc,
.get_rxfh_indir_size = mlx4_en_get_rxfh_indir_size,
+ .get_rxfh_key_size = mlx4_en_get_rxfh_key_size,
.get_rxfh = mlx4_en_get_rxfh,
.set_rxfh = mlx4_en_set_rxfh,
.get_channels = mlx4_en_get_channels,
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index ccd95177ea7c..b7bda8956011 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1169,9 +1169,6 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
int i, qpn;
int err = 0;
int good_qps = 0;
- static const u32 rsskey[10] = { 0xD181C62C, 0xF7F4DB5B, 0x1983A2FC,
- 0x943E1ADB, 0xD9389E6B, 0xD1039C2C, 0xA74499AD,
- 0x593D56D9, 0xF3253C06, 0x2ADC1FFC};
en_dbg(DRV, priv, "Configuring rss steering\n");
err = mlx4_qp_reserve_range(mdev->dev, priv->rx_ring_num,
@@ -1226,8 +1223,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
rss_context->flags = rss_mask;
rss_context->hash_fn = MLX4_RSS_HASH_TOP;
- for (i = 0; i < 10; i++)
- rss_context->rss_key[i] = cpu_to_be32(rsskey[i]);
+ netdev_rss_key_fill(rss_context->rss_key, MLX4_EN_RSS_KEY_SIZE);
err = mlx4_qp_to_ready(mdev->dev, &priv->res.mtt, &context,
&rss_map->indir_qp, &rss_map->indir_state);
diff --git a/include/linux/mlx4/qp.h b/include/linux/mlx4/qp.h
index 5f4e36cf0091..467ccdf94c98 100644
--- a/include/linux/mlx4/qp.h
+++ b/include/linux/mlx4/qp.h
@@ -120,13 +120,15 @@ enum {
MLX4_RSS_QPC_FLAG_OFFSET = 13,
};
+#define MLX4_EN_RSS_KEY_SIZE 40
+
struct mlx4_rss_context {
__be32 base_qpn;
__be32 default_qpn;
u16 reserved;
u8 hash_fn;
u8 flags;
- __be32 rss_key[10];
+ __be32 rss_key[MLX4_EN_RSS_KEY_SIZE / sizeof(__be32)];
__be32 base_qpn_udp;
};
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 13/14] sfc: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Shradha Shah <sshah@solarflare.com>
---
drivers/net/ethernet/sfc/efx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index b49d04886d4f..238482495e81 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -1616,7 +1616,7 @@ static int efx_probe_nic(struct efx_nic *efx)
goto fail2;
if (efx->n_channels > 1)
- get_random_bytes(&efx->rx_hash_key, sizeof(efx->rx_hash_key));
+ netdev_rss_key_fill(&efx->rx_hash_key, sizeof(efx->rx_hash_key));
for (i = 0; i < ARRAY_SIZE(efx->rx_indir_table); i++)
efx->rx_indir_table[i] =
ethtool_rxfh_indir_default(i, efx->rss_spread);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 14/14] vmxnet3: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 6dfcbf523936..afd295348ddb 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2199,13 +2199,6 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
if (adapter->rss) {
struct UPT1_RSSConf *rssConf = adapter->rss_conf;
- static const uint8_t rss_key[UPT1_RSS_MAX_KEY_SIZE] = {
- 0x3b, 0x56, 0xd1, 0x56, 0x13, 0x4a, 0xe7, 0xac,
- 0xe8, 0x79, 0x09, 0x75, 0xe8, 0x65, 0x79, 0x28,
- 0x35, 0x12, 0xb9, 0x56, 0x7c, 0x76, 0x4b, 0x70,
- 0xd8, 0x56, 0xa3, 0x18, 0x9b, 0x0a, 0xee, 0xf3,
- 0x96, 0xa6, 0x9f, 0x8f, 0x9e, 0x8c, 0x90, 0xc9,
- };
devRead->misc.uptFeatures |= UPT1_F_RSS;
devRead->misc.numRxQueues = adapter->num_rx_queues;
@@ -2216,7 +2209,7 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
rssConf->hashFunc = UPT1_RSS_HASH_FUNC_TOEPLITZ;
rssConf->hashKeySize = UPT1_RSS_MAX_KEY_SIZE;
rssConf->indTableSize = VMXNET3_RSS_IND_TABLE_SIZE;
- memcpy(rssConf->hashKey, rss_key, sizeof(rss_key));
+ netdev_rss_key_fill(rssConf->hashKey, sizeof(rssConf->hashKey));
for (i = 0; i < rssConf->indTableSize; i++)
rssConf->indTable[i] = ethtool_rxfh_indir_default(
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 01/14] net: provide a per host RSS key generic infrastructure
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
RSS (Receive Side Scaling) typically uses Toeplitz hash and a 40 or 52 bytes
RSS key.
Some drivers use a constant (and well known key), some drivers use a random
key per port, making bonding setups hard to tune. Well known keys increase
attack surface, considering that number of queues is usually a power of two.
This patch provides infrastructure to help drivers doing the right thing.
netdev_rss_key_fill() should be used by drivers to initialize their RSS key,
even if they provide ethtool -X support to let user redefine the key later.
A new /proc/sys/net/core/netdev_rss_key file can be used to get the host
RSS key even for drivers not providing ethtool -x support, in case some
applications want to precisely setup flows to match some RX queues.
Tested:
myhost:~# cat /proc/sys/net/core/netdev_rss_key
11:63:99:bb:79:fb:a5:a7:07:45:b2:20:bf:02:42:2d:08:1a:dd:19:2b:6b:23:ac:56:28:9d:70:c3:ac:e8:16:4b:b7:c1:10:53:a4:78:41:36:40:74:b6:15:ca:27:44:aa:b3:4d:72
myhost:~# ethtool -x eth0
RX flow hash indirection table for eth0 with 8 RX ring(s):
0: 0 1 2 3 4 5 6 7
RSS hash key:
11:63:99:bb:79:fb:a5:a7:07:45:b2:20:bf:02:42:2d:08:1a:dd:19:2b:6b:23:ac:56:28:9d:70:c3:ac:e8:16:4b:b7:c1:10:53:a4:78:41
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
Documentation/sysctl/net.txt | 22 ++++++++++++++++++++++
include/linux/netdevice.h | 6 ++++++
net/core/ethtool.c | 11 +++++++++++
net/core/sysctl_net_core.c | 19 +++++++++++++++++++
4 files changed, 58 insertions(+)
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
index e26c607468a6..666594b43cff 100644
--- a/Documentation/sysctl/net.txt
+++ b/Documentation/sysctl/net.txt
@@ -142,6 +142,28 @@ netdev_max_backlog
Maximum number of packets, queued on the INPUT side, when the interface
receives packets faster than kernel can process them.
+netdev_rss_key
+--------------
+
+RSS (Receive Side Scaling) enabled drivers use a 40 bytes host key that is
+randomly generated.
+Some user space might need to gather its content even if drivers do not
+provide ethtool -x support yet.
+
+myhost:~# cat /proc/sys/net/core/netdev_rss_key
+84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8: ... (52 bytes total)
+
+File contains nul bytes if no driver ever called netdev_rss_key_fill() function.
+Note:
+/proc/sys/net/core/netdev_rss_key contains 52 bytes of key,
+but most drivers only use 40 bytes of it.
+
+myhost:~# ethtool -x eth0
+RX flow hash indirection table for eth0 with 8 RX ring(s):
+ 0: 0 1 2 3 4 5 6 7
+RSS hash key:
+84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8:43:e3:c9:0c:fd:17:55:c2:3a:4d:69:ed:f1:42:89
+
netdev_tstamp_prequeue
----------------------
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4a6f770377d3..db63cf459ba1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3422,6 +3422,12 @@ void netdev_upper_dev_unlink(struct net_device *dev,
void netdev_adjacent_rename_links(struct net_device *dev, char *oldname);
void *netdev_lower_dev_get_private(struct net_device *dev,
struct net_device *lower_dev);
+
+/* RSS keys are 40 or 52 bytes long */
+#define NETDEV_RSS_KEY_LEN 52
+extern u8 netdev_rss_key[NETDEV_RSS_KEY_LEN];
+void netdev_rss_key_fill(void *buffer, size_t len);
+
int dev_get_nest_level(struct net_device *dev,
bool (*type_check)(struct net_device *dev));
int skb_checksum_help(struct sk_buff *skb);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index b0f84f5ddda8..715f51f321e9 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -25,6 +25,7 @@
#include <linux/slab.h>
#include <linux/rtnetlink.h>
#include <linux/sched.h>
+#include <linux/net.h>
/*
* Some useful ethtool_ops methods that're device independent.
@@ -573,6 +574,16 @@ static int ethtool_copy_validate_indir(u32 *indir, void __user *useraddr,
return 0;
}
+u8 netdev_rss_key[NETDEV_RSS_KEY_LEN];
+
+void netdev_rss_key_fill(void *buffer, size_t len)
+{
+ BUG_ON(len > sizeof(netdev_rss_key));
+ net_get_random_once(netdev_rss_key, sizeof(netdev_rss_key));
+ memcpy(buffer, netdev_rss_key, len);
+}
+EXPORT_SYMBOL(netdev_rss_key_fill);
+
static noinline_for_stack int ethtool_get_rxfh_indir(struct net_device *dev,
void __user *useraddr)
{
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index f93f092fe226..31baba2a71ce 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -217,6 +217,18 @@ static int set_default_qdisc(struct ctl_table *table, int write,
}
#endif
+static int proc_do_rss_key(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct ctl_table fake_table;
+ char buf[NETDEV_RSS_KEY_LEN * 3];
+
+ snprintf(buf, sizeof(buf), "%*phC", NETDEV_RSS_KEY_LEN, netdev_rss_key);
+ fake_table.data = buf;
+ fake_table.maxlen = sizeof(buf);
+ return proc_dostring(&fake_table, write, buffer, lenp, ppos);
+}
+
static struct ctl_table net_core_table[] = {
#ifdef CONFIG_NET
{
@@ -265,6 +277,13 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "netdev_rss_key",
+ .data = &netdev_rss_key,
+ .maxlen = sizeof(int),
+ .mode = 0444,
+ .proc_handler = proc_do_rss_key,
+ },
#ifdef CONFIG_BPF_JIT
{
.procname = "bpf_jit_enable",
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Payment
From: Finance Department @ 2014-11-16 16:26 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* (unknown),
From: Gloria C. Mackenzie @ 2014-11-16 16:45 UTC (permalink / raw)
--
Contact Mrs. Gloria C. Mackenzie for your
Donation US$ 2 Million Dollars Donation
--
^ permalink raw reply
* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Eric Dumazet @ 2014-11-16 18:11 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <64ef227cf22945d373cb06271fe6e051@visp.net.lb>
On Sun, 2014-11-16 at 10:54 +0200, Denys Fedoryshchenko wrote:
> As latest findings, when servers are going crazy because of tcp memory
> invalid accounting.
> First of all i upgraded kernel to latest version 3.17.3 and added also
> patch from upcoming kernel,
> "12) Don't call sock_kfree_s() with NULL pointers, this function also
> has the side effect of adjusting
> the socket memory usage. From Cong Wang.", but it didnt helped.
>
> I added printk_ratelimited to places where suspicious values might
> appear, and got some more information.
> First, is not very suspicious, no idea if it is a problem:
> [ 1413.031622] sk ffff8817184d8680 sk_mem_charge negative -10752 by 4352
> [ 1413.032027] sk ffff8817184d8680 sk_mem_charge negative -15104 by 4352
> [ 1415.768465] sk ffff881666842d80 sk_mem_charge negative -9984 by 4352
> [ 1415.768868] sk ffff881666842d80 sk_mem_charge negative -14336 by 4352
> [ 1415.769268] sk ffff881666842d80 sk_mem_charge negative -18688 by 4352
> [ 1415.769681] sk ffff881666842d80 sk_mem_charge negative -9088 by 4352
> [ 1418.933799] sk ffff8816dd640000 sk_mem_charge negative -9984 by 4352
> [ 1418.934205] sk ffff8816dd640000 sk_mem_charge negative -14336 by 4352
> [ 1418.934604] sk ffff8816dd640000 sk_mem_charge negative -18688 by 4352
> [ 1427.131310] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
> [ 1428.564640] sk ffff881731801a00 sk_mem_charge negative -11008 by 4352
> [ 1429.134279] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
> [ 1429.134691] sk ffff881731801a00 sk_mem_charge negative -16128 by 4352
> [ 1430.666541] sk ffff881731801a00 sk_mem_charge negative -10496 by 4352
> [ 1431.395099] sk ffff881731801a00 sk_mem_charge negative -12032 by 4352
> [ 1431.395506] sk ffff881731801a00 sk_mem_charge negative -16384 by 4352
> [ 1431.877862] sk ffff881731801a00 sk_mem_charge negative -11648 by 4352
> Second is always linked with crashes, it is sk_mem_uncharge and
> sk_forward_alloc goes negative. Patch to show message
> for sk_mem_uncharge in sock.h is very simple:
>
> static inline void sk_mem_uncharge(struct sock *sk, int size)
> @@ -1480,6 +1485,8 @@
> if (!sk_has_account(sk))
> return;
> sk->sk_forward_alloc += size;
> + if (sk->sk_forward_alloc < -8192)
> + printk_ratelimited(KERN_WARNING"sk %p sk_mem_uncharge
> negative %d by %d\n", sk, sk->sk_forward_alloc, size);
> }
>
Could you describe your hardware setup and networking setup ?
^ permalink raw reply
* Re: pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
From: Eric Dumazet @ 2014-11-16 18:15 UTC (permalink / raw)
To: Michal Soltys; +Cc: Jarek Poplawski, Linux Netdev List
In-Reply-To: <5468A0C5.9010409@ziu.info>
On Sun, 2014-11-16 at 14:04 +0100, Michal Soltys wrote:
> Hi,
>
> I was wondering (probably missing some subtleties) about that particular
> patch, namely:
>
> 61c9eaf90081cbe6dc4f389e0056bff76eca19ec
>
> Why would that qlen++ change be necessary ? As far as peeked qdisc sees
> things, the packet is already deqeued and gone - so not really part of
> the queue anymore in this context (not ever requeued either). More
> advanced qdiscs such as say fq_codel - if for example they decide to
> drop head during further enqueue operation - obviously won't even
> consider the peeked packet.
peeked packet has not to be considered by qdisc : Their dequeue()
methods is called only when there is no more peeked packet.
>
> Increasing qlen from what I can see artificially shortens queue by 1.
> For some classful schedulers (say like hfsc that instantly peeks next
> packet length after dequeuing), child qdiscs will be almost all the time
> formally operating at queue size decreased by 1.
Well, the peeked packet is part of the queue, as it is not yet
transmitted.
^ permalink raw reply
* [PATCH] net/at91_ether: fix loading when macb is compiled as a module
From: Gilles Chanteperdrix @ 2014-11-16 18:05 UTC (permalink / raw)
To: Nicolas Ferre, netdev; +Cc: Gilles Chanteperdrix
The at91_ether driver depends on symbols defined in the macb driver.
Currently, when compiling both at91_ether and macb as module, starting
the at91_ether module fails, because the macb module can not be loaded
with a macb interface.
Avoid this issue by getting the macb module initialization routine to
always return 0, even when no macb device is detected.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
---
drivers/net/ethernet/cadence/macb.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 4d9fc05..f70228c 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2327,7 +2327,20 @@ static struct platform_driver macb_driver = {
},
};
-module_platform_driver_probe(macb_driver, macb_probe);
+static bool found;
+static int __init macb_driver_init(void)
+{
+ found = platform_driver_probe(&macb_driver, macb_probe) == 0;
+ return 0;
+}
+module_init(macb_driver_init);
+
+static void __exit macb_driver_exit(void)
+{
+ if (found)
+ platform_driver_unregister(&macb_driver);
+}
+module_exit(macb_driver_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: Bjørn Mork @ 2014-11-16 18:31 UTC (permalink / raw)
To: Martin Hauke; +Cc: netdev
In-Reply-To: <20141116000322.GA22833@gmx.de>
Martin Hauke <mardnh@gmx.de> writes:
> Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
Thanks. But you forgot the Signed-off-by line on both patches. Please
resubmit with it. See
https://www.kernel.org/doc/Documentation/SubmittingPatches
Bjørn
^ permalink raw reply
* Re: [PATCH] net/at91_ether: fix loading when macb is compiled as a module
From: David Miller @ 2014-11-16 18:53 UTC (permalink / raw)
To: gilles.chanteperdrix; +Cc: nicolas.ferre, netdev
In-Reply-To: <1416161106-27498-1-git-send-email-gilles.chanteperdrix@xenomai.org>
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Date: Sun, 16 Nov 2014 19:05:06 +0100
> The at91_ether driver depends on symbols defined in the macb driver.
>
> Currently, when compiling both at91_ether and macb as module, starting
> the at91_ether module fails, because the macb module can not be loaded
> with a macb interface.
>
> Avoid this issue by getting the macb module initialization routine to
> always return 0, even when no macb device is detected.
>
> Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
This is not acceptable, sorry.
This means the module stays in memory even if nobody has a real use
for it.
You'll need to find another solution, and I'll say in passing that this
was very poorly designed and that's why the problem exists.
^ permalink raw reply
* [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: Martin Hauke @ 2014-11-16 18:55 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev
In-Reply-To: <871tp3gfpr.fsf@nemi.mork.no>
Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
Signed-off-by: Martin Hauke <mardnh@gmx.de>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 22756db..b8a82b8 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -780,6 +780,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a8, 8)}, /* Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)}, /* Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card */
+ {QMI_FIXED_INTF(0x03f0, 0x581d, 4)}, /* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
--
2.1.2
^ permalink raw reply related
* Re: [PATCH v2 net-next 6/7] bpf: allow eBPF programs to use maps
From: David Miller @ 2014-11-16 19:04 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415929010-9361-7-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Thu, 13 Nov 2014 17:36:49 -0800
> +static u64 bpf_map_lookup_elem(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +{
> + /* verifier checked that R1 contains a valid pointer to bpf_map
> + * and R2 points to a program stack and map->key_size bytes were
> + * initialized
> + */
> + struct bpf_map *map = (struct bpf_map *) (unsigned long) r1;
> + void *key = (void *) (unsigned long) r2;
> + void *value;
> +
> + WARN_ON_ONCE(!rcu_read_lock_held());
> +
> + value = map->ops->map_lookup_elem(map, key);
> +
> + /* lookup() returns either pointer to element value or NULL
> + * which is the meaning of PTR_TO_MAP_VALUE_OR_NULL type
> + */
> + return (unsigned long) value;
> +}
You should translate this into a true boolean '1' or '0' value so that
kernel pointers don't propagate to the user or his eBPF programs.
^ permalink raw reply
* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Denys Fedoryshchenko @ 2014-11-16 19:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1416161495.17262.90.camel@edumazet-glaptop2.roam.corp.google.com>
On 2014-11-16 20:11, Eric Dumazet wrote:
> On Sun, 2014-11-16 at 10:54 +0200, Denys Fedoryshchenko wrote:
>> As latest findings, when servers are going crazy because of tcp memory
>> invalid accounting.
>> First of all i upgraded kernel to latest version 3.17.3 and added also
>> patch from upcoming kernel,
>> "12) Don't call sock_kfree_s() with NULL pointers, this function also
>> has the side effect of adjusting
>> the socket memory usage. From Cong Wang.", but it didnt helped.
>>
>> I added printk_ratelimited to places where suspicious values might
>> appear, and got some more information.
>> First, is not very suspicious, no idea if it is a problem:
>> [ 1413.031622] sk ffff8817184d8680 sk_mem_charge negative -10752 by
>> 4352
>> [ 1413.032027] sk ffff8817184d8680 sk_mem_charge negative -15104 by
>> 4352
>> [ 1415.768465] sk ffff881666842d80 sk_mem_charge negative -9984 by
>> 4352
>> [ 1415.768868] sk ffff881666842d80 sk_mem_charge negative -14336 by
>> 4352
>> [ 1415.769268] sk ffff881666842d80 sk_mem_charge negative -18688 by
>> 4352
>> [ 1415.769681] sk ffff881666842d80 sk_mem_charge negative -9088 by
>> 4352
>> [ 1418.933799] sk ffff8816dd640000 sk_mem_charge negative -9984 by
>> 4352
>> [ 1418.934205] sk ffff8816dd640000 sk_mem_charge negative -14336 by
>> 4352
>> [ 1418.934604] sk ffff8816dd640000 sk_mem_charge negative -18688 by
>> 4352
>> [ 1427.131310] sk ffff881731801a00 sk_mem_charge negative -11776 by
>> 4352
>> [ 1428.564640] sk ffff881731801a00 sk_mem_charge negative -11008 by
>> 4352
>> [ 1429.134279] sk ffff881731801a00 sk_mem_charge negative -11776 by
>> 4352
>> [ 1429.134691] sk ffff881731801a00 sk_mem_charge negative -16128 by
>> 4352
>> [ 1430.666541] sk ffff881731801a00 sk_mem_charge negative -10496 by
>> 4352
>> [ 1431.395099] sk ffff881731801a00 sk_mem_charge negative -12032 by
>> 4352
>> [ 1431.395506] sk ffff881731801a00 sk_mem_charge negative -16384 by
>> 4352
>> [ 1431.877862] sk ffff881731801a00 sk_mem_charge negative -11648 by
>> 4352
>> Second is always linked with crashes, it is sk_mem_uncharge and
>> sk_forward_alloc goes negative. Patch to show message
>> for sk_mem_uncharge in sock.h is very simple:
>>
>> static inline void sk_mem_uncharge(struct sock *sk, int size)
>> @@ -1480,6 +1485,8 @@
>> if (!sk_has_account(sk))
>> return;
>> sk->sk_forward_alloc += size;
>> + if (sk->sk_forward_alloc < -8192)
>> + printk_ratelimited(KERN_WARNING"sk %p sk_mem_uncharge
>> negative %d by %d\n", sk, sk->sk_forward_alloc, size);
>> }
>>
>
>
> Could you describe your hardware setup and networking setup ?
This problem are happening on multiple different units that i am using
as https balancers, and all of them very different (except it is all
Intel CPU's, but even in that - different generations and models). Such
problem seems happens on all of them, and seems doesn't depend on
hardware (networking - igb, e1000e, broadcom stuff - all affected). But
if it is important:
S2600GZ motherboard, one E5-2620 Xeon
networking - onboard igb, 2 ports used
100GB RAM
This particular one has bonding (but it seems crashes with or without
it).
System are custom, running on USB flash, busybox+glibc based setup,
similar OS working for other purposes for NAT, PPPoE termination without
any issues.
What is common between failing units:
I am using haproxy-based HTTPS balancer(Also as i remember haproxy doing
a lot of setsockopt stuff), that is handling right now:
454444 connections established
Bandwidth passing thru is around 1Gbps.
I'm disabling tso/gso/gro on all interfaces.
The way i am forwarding transparent traffic to haproxy:
iptables -t mangle -A PREROUTING -p tcp --sport 443 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark
0x1
ip rule add fwmark 0x1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
"Typical" setup is
backend ssl_passthru
mode tcp
option transparent
source 0.0.0.0 usesrc clientip
frontend ssl-in
mode tcp
bind :443 transparent
default_backend ssl_passthru
option tcp-smart-accept
I hope i didnt missed something important. I can provide remote ssh
access to it.
I will keep sending info, just with hope that some of info maybe will
give idea, what i should patch or test.
P.S. Just got an idea now, that -2147483648 hinting that somewhere is
happening integer overflow from very large positive value, to negative.
I will try to set triggers also to that now.
If required i can provide image with such system. I am not sure you are
interested in this problem and if it can be reproduced on synthetic
setup, but as i remember this memory leak happened with me once also on
normal server with torrents (i left some image unattended for 2 weeks,
with a lot of requests, and it crashed at the end), so it might affect
also other use cases.
I am trying to limit now socket buffers, to see if it will decrease
frequency of crashes.
Also i tried to put "canary" values inside structure, near
sk_forward_alloc , to see if there is any sort of memory corruption
occuring on sk_forward_alloc, but seems there is no corruption.
I will try also going back to stable kernels 3.2.64, to see if it will
fix this problem, but testing takes sometimes almost 1 day, depends on
luck.
^ permalink raw reply
* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Eric Dumazet @ 2014-11-16 19:10 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1416161495.17262.90.camel@edumazet-glaptop2.roam.corp.google.com>
On Sun, 2014-11-16 at 10:11 -0800, Eric Dumazet wrote:
> Could you describe your hardware setup and networking setup ?
Hmmm, this looks like a bug in TCP fast open.
I am cooking a patch.
^ permalink raw reply
* Re: [PATCH net] ipv4: Fix incorrect error code when adding an unreachable route
From: David Miller @ 2014-11-16 19:16 UTC (permalink / raw)
To: pmatilai; +Cc: netdev
In-Reply-To: <beb6c57fb3e1591346d64ac2fcdb354cd87987d4.1415963644.git.pmatilai@redhat.com>
From: Panu Matilainen <pmatilai@redhat.com>
Date: Fri, 14 Nov 2014 13:14:32 +0200
> Trying to add an unreachable route incorrectly returns -ESRCH if
> if custom FIB rules are present:
>
> [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
> RTNETLINK answers: Network is unreachable
> [root@localhost ~]# ip rule add to 55.66.77.88 table 200
> [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
> RTNETLINK answers: No such process
> [root@localhost ~]#
>
> Commit 83886b6b636173b206f475929e58fac75c6f2446 ("[NET]: Change "not found"
> return value for rule lookup") changed fib_rules_lookup()
> to use -ESRCH as a "not found" code internally, but for user space it
> should be translated into -ENETUNREACH. Handle the translation centrally in
> ipv4-specific fib_lookup(), leaving the DECnet case alone.
>
> On a related note, commit b7a71b51ee37d919e4098cd961d59a883fd272d8
> ("ipv4: removed redundant conditional") removed a similar translation from
> ip_route_input_slow() prematurely AIUI.
>
> Fixes: b7a71b51ee37 ("ipv4: removed redundant conditional")
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: Bjørn Mork @ 2014-11-16 19:18 UTC (permalink / raw)
To: Martin Hauke; +Cc: netdev
In-Reply-To: <20141116185525.GA19989@gmx.de>
Martin Hauke <mardnh@gmx.de> writes:
> Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
>
> Signed-off-by: Martin Hauke <mardnh@gmx.de>
Acked-by: Bjørn Mork <bjorn@mork.no>
Dave, please add this to the netdev stable queue as well.
Thanks,
Bjørn
^ permalink raw reply
* Re: [PATCH net] reciprocal_div: objects with exported symbols should be obj-y rather than lib-y
From: David Miller @ 2014-11-16 19:19 UTC (permalink / raw)
To: hannes; +Cc: netdev, jim.epost
In-Reply-To: <85de478df37362b703cb5db64cbfc48d4d4439f5.1415974584.git.hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 14 Nov 2014 15:16:47 +0100
> Otherwise the exported symbols might be discarded because of no users
> in vmlinux.
>
> Reported-by: Jim Davis <jim.epost@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] drivers: net: cpsw: Fix TX_IN_SEL offset
From: David Miller @ 2014-11-16 19:20 UTC (permalink / raw)
To: john.ogness
Cc: linux-kernel, mugunthanvnm, balbi, george.cherian, jhovold, mpa,
bhutchings, zonque, tklauser, netdev
In-Reply-To: <87sihlj11v.fsf@linutronix.de>
From: John Ogness <john.ogness@linutronix.de>
Date: Fri, 14 Nov 2014 15:42:52 +0100
> The TX_IN_SEL offset for the CPSW_PORT/TX_IN_CTL register was
> incorrect. This caused the Dual MAC mode to never get set when
> it should. It also caused possible unintentional setting of a
> bit in the CPSW_PORT/TX_BLKS_REM register.
>
> The purpose of setting the Dual MAC mode for this register is to:
>
> "... allow packets from both ethernet ports to be written into
> the FIFO without one port starving the other port."
> - AM335x ARM TRM
>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/8] Netfilter/IPVS fixes for net
From: David Miller @ 2014-11-16 19:24 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1415984329-5569-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 14 Nov 2014 17:58:40 +0100
> The following patchset contains Netfilter updates for your net tree,
> they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks a lot Pablo!
^ permalink raw reply
* Re: [PATCH net-next] tipc: allow one link per bearer to neighboring nodes
From: David Miller @ 2014-11-16 19:27 UTC (permalink / raw)
To: holger.brunck; +Cc: jon.maloy, ying.xue, erik.hugne, netdev
In-Reply-To: <1415986399-23874-1-git-send-email-holger.brunck@keymile.com>
From: Holger Brunck <holger.brunck@keymile.com>
Date: Fri, 14 Nov 2014 18:33:19 +0100
> There is no reason to limit the amount of possible links to a
> neighboring node to 2. If we have more then two bearers we can also
> establish more links.
>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> Reviewed-By: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] openvswitch: use PTR_ERR_OR_ZERO
From: David Miller @ 2014-11-16 19:43 UTC (permalink / raw)
To: fabf-AgBVmzD5pcezQB+pC5nmwQ
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415989978-28559-1-git-send-email-fabf-AgBVmzD5pcezQB+pC5nmwQ@public.gmane.org>
From: Fabian Frederick <fabf@skynet.be>
Date: Fri, 14 Nov 2014 19:32:58 +0100
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ 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