* [net-next v3 02/17] i40e: drop unused macros
From: Jeff Kirsher @ 2014-01-11 0:47 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1389401250-11509-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
A previous commit removed any need for these macros, so remove
them too.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_type.h | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h b/drivers/net/ethernet/intel/i40e/i40e_type.h
index 12473ad..072c850 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_type.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
@@ -60,15 +60,6 @@
/* Max default timeout in ms, */
#define I40E_MAX_NVM_TIMEOUT 18000
-/* Check whether address is multicast. This is little-endian specific check.*/
-#define I40E_IS_MULTICAST(address) \
- (bool)(((u8 *)(address))[0] & ((u8)0x01))
-
-/* Check whether an address is broadcast. */
-#define I40E_IS_BROADCAST(address) \
- ((((u8 *)(address))[0] == ((u8)0xff)) && \
- (((u8 *)(address))[1] == ((u8)0xff)))
-
/* Switch from mc to the 2usec global time (this is the GTIME resolution) */
#define I40E_MS_TO_GTIME(time) (((time) * 1000) / 2)
--
1.8.3.1
^ permalink raw reply related
* [net-next v3 01/17] i40e: use assignment instead of memcpy
From: Jeff Kirsher @ 2014-01-11 0:47 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Jeff Kirsher
In-Reply-To: <1389401250-11509-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
These instances were found by coccinelle/spatch, and can
use struct assignment instead of memcpy.
Change-ID: Idc23c3599241bf8a658bda18c80417af3fbfee66
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_common.c | 3 +--
drivers/net/ethernet/intel/i40e/i40e_hmc.c | 8 +++-----
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.c b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
index c75aa2d..4e5a02c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
@@ -922,7 +922,7 @@ i40e_status i40e_clean_arq_element(struct i40e_hw *hw,
"AQRX: Event received with error 0x%X.\n",
hw->aq.arq_last_status);
} else {
- memcpy(&e->desc, desc, sizeof(struct i40e_aq_desc));
+ e->desc = *desc;
datalen = le16_to_cpu(desc->datalen);
e->msg_size = min(datalen, e->msg_size);
if (e->msg_buf != NULL && (e->msg_size != 0))
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 807312b..6bfbeec 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -599,8 +599,7 @@ i40e_status i40e_aq_get_link_info(struct i40e_hw *hw,
goto aq_get_link_info_exit;
/* save off old link status information */
- memcpy(&hw->phy.link_info_old, hw_link_info,
- sizeof(struct i40e_link_status));
+ hw->phy.link_info_old = *hw_link_info;
/* update link status */
hw_link_info->phy_type = (enum i40e_aq_phy_type)resp->phy_type;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_hmc.c b/drivers/net/ethernet/intel/i40e/i40e_hmc.c
index 76dfef3..bf2d4cc 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_hmc.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_hmc.c
@@ -89,11 +89,9 @@ i40e_status i40e_add_sd_table_entry(struct i40e_hw *hw,
sd_entry->u.pd_table.pd_entry =
(struct i40e_hmc_pd_entry *)
sd_entry->u.pd_table.pd_entry_virt_mem.va;
- memcpy(&sd_entry->u.pd_table.pd_page_addr, &mem,
- sizeof(struct i40e_dma_mem));
+ sd_entry->u.pd_table.pd_page_addr = mem;
} else {
- memcpy(&sd_entry->u.bp.addr, &mem,
- sizeof(struct i40e_dma_mem));
+ sd_entry->u.bp.addr = mem;
sd_entry->u.bp.sd_pd_index = sd_index;
}
/* initialize the sd entry */
@@ -164,7 +162,7 @@ i40e_status i40e_add_pd_table_entry(struct i40e_hw *hw,
if (ret_code)
goto exit;
- memcpy(&pd_entry->bp.addr, &mem, sizeof(struct i40e_dma_mem));
+ pd_entry->bp.addr = mem;
pd_entry->bp.sd_pd_index = pd_index;
pd_entry->bp.entry_type = I40E_SD_TYPE_PAGED;
/* Set page address and valid bit */
--
1.8.3.1
^ permalink raw reply related
* [net-next v3 00/17][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2014-01-11 0:47 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to i40e and now i40evf.
Most notable is Jacob's patch to add PTP support to i40e.
Mitch cleans up additional memcpy's and use struct assignment instead.
Then fixes long lines to appease checkpatch.pl. Mitch then provides
a fix to keep us from spamming the log with confusing errors. If you
use ip to change the MAC address of a VF while the VF driver is loaded,
closing the VF interface or unloading the VF driver will cause the VF
driver to remove the MAC filter for its original (now invalid) MAC
address.
Jesse cleans up macros which are no longer needed or used.
I (Jeff) cleanup function header comments to ensure Doxygen/kdoc works
correctly to generate documentation without warnings.
Anjali fixes a bug where ethtool set-channels would return failure when
configuring only one Rx queue. Then fixes a bug where the driver was
erroneously exiting the driver unload path if one part of the unload
failed.
Shannon fixes if the IPV6EXADD but is set in the Rx descriptor status,
there was an optional extension header with an alternate IP address
detected and the hardware checksum was not handling the alternate IP
address correctly. Then adjusts the ITR max and min values to match
the hardware max value and recommended min value. Shannon makes sure
to clear the PXE mode after the adminq is initialized.
v2:
- fix patch 14 "i40e: enable PTP" to address Richard Cochran's spelling
catch and Ben Hutchings Kconfig, SIOCGHWTSTAMP and sizeof() suggestions
- added Paul Gortmaker's i40evf fix patch
v3:
- fix patch 14 "i40e: enable PTP" to address Ben Hutchings concerns about
a race with PTP init and cleanup and i40e_get_ts_info().
The following are changes since commit 11b57f90257c1d6a91cee720151b69e0c2020cf6:
xen-netback: stop vif thread spinning if frontend is unresponsive
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Anjali Singhai Jain (3):
i40e: Update the Current NVM version Low value
i40e: Setting queue count to 1 using ethtool is valid
i40e: do not bail when disabling if Tx queue disable fails
Catherine Sullivan (2):
i40e: Bump version
i40e: Bump version
Jacob Keller (1):
i40e: enable PTP
Jeff Kirsher (1):
i40e: Cleanup Doxygen warnings
Jesse Brandeburg (1):
i40e: drop unused macros
Mitch Williams (3):
i40e: use assignment instead of memcpy
i40e: fix long lines
i40e: allow VF to remove any MAC filter
Paul Gortmaker (1):
i40evf: fix s390 build failure due to implicit prefetch.h
Shannon Nelson (5):
i40e: check for possible incorrect ipv6 checksum
i40e: adjust ITR max and min values
i40e: clear qtx_head before enabling Tx queue
i40e: call clear_pxe after adminq is initialized
i40e: fix log message wording
drivers/net/ethernet/intel/Kconfig | 1 +
drivers/net/ethernet/intel/i40e/Makefile | 1 +
drivers/net/ethernet/intel/i40e/i40e.h | 28 +-
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 28 +-
drivers/net/ethernet/intel/i40e/i40e_common.c | 23 +-
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 35 +-
drivers/net/ethernet/intel/i40e/i40e_hmc.c | 8 +-
drivers/net/ethernet/intel/i40e/i40e_hmc.h | 3 -
drivers/net/ethernet/intel/i40e/i40e_main.c | 65 +-
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_prototype.h | 4 +-
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 662 +++++++++++++++++++++
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 57 ++
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 8 +-
drivers/net/ethernet/intel/i40e/i40e_type.h | 13 +-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 8 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +
18 files changed, 887 insertions(+), 62 deletions(-)
create mode 100644 drivers/net/ethernet/intel/i40e/i40e_ptp.c
--
1.8.3.1
^ permalink raw reply
* suspicious RCU usage in net/ipv4/ip_tunnel.c:80
From: Cong Wang @ 2014-01-11 0:37 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
Hi, Tom
I saw:
[ 65.609535] [ INFO: suspicious RCU usage. ]
[ 65.609537] 3.13.0-rc6+ #139 Not tainted
[ 65.609538] -------------------------------
[ 65.609539] net/ipv4/ip_tunnel.c:80 suspicious rcu_dereference_check() usage!
[ 65.609540]
[ 65.609540] other info that might help us debug this:
[ 65.609540]
[ 65.609541]
[ 65.609541] rcu_scheduler_active = 1, debug_locks = 0
[ 65.609542] 5 locks held by kworker/u8:0/6:
[ 65.609553] #0: (%s#4){.+.+.+}, at: [<ffffffff8106d56b>]
process_one_work+0x173/0x41e
[ 65.609557] #1: (net_cleanup_work){+.+.+.}, at:
[<ffffffff8106d56b>] process_one_work+0x173/0x41e
[ 65.609563] #2: (net_mutex){+.+.+.}, at: [<ffffffff817816c9>]
cleanup_net+0x85/0x18a
[ 65.609569] #3: (rtnl_mutex){+.+.+.}, at: [<ffffffff81796058>]
rtnl_lock+0x17/0x19
[ 65.609575] #4: (&(&idst->lock)->rlock){+.....}, at:
[<ffffffff818820fe>] __tunnel_dst_set+0x30/0x8b
[ 65.609575]
[ 65.609575] stack backtrace:
[ 65.609577] CPU: 1 PID: 6 Comm: kworker/u8:0 Not tainted 3.13.0-rc6+ #139
[ 65.609579] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 65.609582] Workqueue: netns cleanup_net
[ 65.609585] 0000000000000000 ffff880118205bb0 ffffffff819894b6
ffff8801181ea550
[ 65.609587] ffff880118205be0 ffffffff81095f34 0000000000000000
ffffe8ffff606df0
[ 65.609589] ffffe8ffff606df8 0000000000000000 ffff880118205c10
ffffffff8188213c
[ 65.609590] Call Trace:
[ 65.609595] [<ffffffff819894b6>] dump_stack+0x4d/0x66
[ 65.609598] [<ffffffff81095f34>] lockdep_rcu_suspicious+0x107/0x110
[ 65.609600] [<ffffffff8188213c>] __tunnel_dst_set+0x6e/0x8b
[ 65.609602] [<ffffffff81882203>] tunnel_dst_reset_all.isra.25+0x40/0x47
[ 65.609605] [<ffffffff81883e28>] ip_tunnel_uninit+0x61/0x64
[ 65.609608] [<ffffffff8178aeb2>] rollback_registered_many+0x188/0x21f
[ 65.609610] [<ffffffff8178b02f>] unregister_netdevice_many+0x19/0x63
[ 65.609612] [<ffffffff81883a17>] ip_tunnel_delete_net+0xd1/0xe5
[ 65.609615] [<ffffffff8188bc68>] vti_exit_net+0x2a/0x2c
[ 65.609617] [<ffffffff81780f21>] ops_exit_list+0x44/0x55
[ 65.609619] [<ffffffff8178173a>] cleanup_net+0xf6/0x18a
[ 65.609621] [<ffffffff8106d612>] process_one_work+0x21a/0x41e
[ 65.609623] [<ffffffff8106d56b>] ? process_one_work+0x173/0x41e
[ 65.609625] [<ffffffff8106dc1b>] worker_thread+0x149/0x1f5
[ 65.609628] [<ffffffff8106dad2>] ? rescuer_thread+0x28d/0x28d
[ 65.609630] [<ffffffff81073f6f>] kthread+0xd2/0xda
[ 65.609634] [<ffffffff8107d0ed>] ? finish_task_switch+0x3a/0xbe
[ 65.609636] [<ffffffff81073e9d>] ? __kthread_parkme+0x61/0x61
[ 65.609640] [<ffffffff819961ac>] ret_from_fork+0x7c/0xb0
[ 65.609642] [<ffffffff81073e9d>] ? __kthread_parkme+0x61/0x61
I think the patch below could fix it but not sure if we really need
synchronize_rcu() here...
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index d3929a6..eb50b9a 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -77,10 +77,11 @@ static inline void __tunnel_dst_set(struct
ip_tunnel_dst *idst,
dst = NULL;
spin_lock_bh(&idst->lock);
- old_dst = rcu_dereference(idst->dst);
+ old_dst = idst->dst;
rcu_assign_pointer(idst->dst, dst);
- dst_release(old_dst);
spin_unlock_bh(&idst->lock);
+ synchronize_rcu();
+ dst_release(old_dst);
}
static inline void tunnel_dst_set(struct ip_tunnel *t, struct dst_entry *dst)
^ permalink raw reply related
* Re: [PATCH net-next 1/2] dts: Add a binding for Synopsys emac max-mtu
From: Florian Fainelli @ 2014-01-11 0:31 UTC (permalink / raw)
To: Vince Bridgers
Cc: devicetree@vger.kernel.org, netdev, Giuseppe Cavallaro, robh+dt,
Pawel Moll, Mark Rutland, ijc+devicetree, galak, dinguyen,
Rayagond Kokatanur
In-Reply-To: <1389397669-10929-3-git-send-email-vbridgers2013@gmail.com>
2014/1/10 Vince Bridgers <vbridgers2013@gmail.com>:
> This change adds a parameter for the Synopsys 10/100/1000
> stmmac Ethernet driver to configure the maximum MTU supported
> by the EMAC instance. Synopsys allows the FIFO sizes to
> be configured when the cores are built for a particular
> device, but do not provide a way for the driver to read
> information from the device about the maximum MTU size
> supported as limited by the device's FIFO size.
>
> Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index eba0e5e..7db314e 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -30,6 +30,10 @@ Required properties:
>
> Optional properties:
> - mac-address: 6 bytes, mac address
> +- snps,max-mtu: Maximum MTU permitted. This parameter is useful since
> + different implementations of the Synopsys MAC may have
> + different FIFO sizes depending on the selections
> + made in Synopsys Core Consultant.
ePAPR v1.1 defines "max-frame-size" as being "Specifies maximum packet
length in bytes that the physical interface can send and receive.", I
would recommend you use that instead of this custom property.
>
> Examples:
>
> @@ -40,5 +44,6 @@ Examples:
> interrupts = <24 23>;
> interrupt-names = "macirq", "eth_wake_irq";
> mac-address = [000000000000]; /* Filled in by U-Boot */
> + snps,max-mtu = <3800>;
> phy-mode = "gmii";
> };
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Florian
^ permalink raw reply
* [Patch net-next] ipv4: register igmp_notifier even when !CONFIG_PROC_FS
From: Cong Wang @ 2014-01-11 0:09 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, David S. Miller, Patrick McHardy, Cong Wang
We still need this notifier even when we don't config
PROC_FS.
It should be rare to have a kernel without PROC_FS,
so just for completeness.
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/include/net/ip.h b/include/net/ip.h
index 5356644..4fcc6dc 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -90,7 +90,7 @@ struct packet_type;
struct rtable;
struct sockaddr;
-int igmp_mc_proc_init(void);
+int igmp_mc_init(void);
/*
* Functions provided by ip.c
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 84c4329..bcbf33e 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -2762,6 +2762,7 @@ static struct pernet_operations igmp_net_ops = {
.init = igmp_net_init,
.exit = igmp_net_exit,
};
+#endif
static int igmp_netdev_event(struct notifier_block *this,
unsigned long event, void *ptr)
@@ -2785,8 +2786,9 @@ static struct notifier_block igmp_notifier = {
.notifier_call = igmp_netdev_event,
};
-int __init igmp_mc_proc_init(void)
+int __init igmp_mc_init(void)
{
+#if defined(CONFIG_PROC_FS)
int err;
err = register_pernet_subsys(&igmp_net_ops);
@@ -2800,5 +2802,7 @@ int __init igmp_mc_proc_init(void)
reg_notif_fail:
unregister_pernet_subsys(&igmp_net_ops);
return err;
-}
+#else
+ return register_netdevice_notifier(&igmp_notifier);
#endif
+}
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index df18461..535a515 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1551,7 +1551,7 @@ void __init ip_init(void)
ip_rt_init();
inet_initpeers();
-#if defined(CONFIG_IP_MULTICAST) && defined(CONFIG_PROC_FS)
- igmp_mc_proc_init();
+#if defined(CONFIG_IP_MULTICAST)
+ igmp_mc_init();
#endif
}
^ permalink raw reply related
* Re: [PATCH net-next 1/2] ARM: dts: socfpga: DTS updates for stmmac driver
From: Vince Bridgers @ 2014-01-10 23:58 UTC (permalink / raw)
To: devicetree, netdev
Cc: Giuseppe CAVALLARO, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, dinguyen, Rayagond Kokatanur,
Vince Bridgers
In-Reply-To: <1389397669-10929-2-git-send-email-vbridgers2013@gmail.com>
Please disregard, sorry for the noise.
On Fri, Jan 10, 2014 at 5:47 PM, Vince Bridgers <vbridgers2013@gmail.com> wrote:
> This change adds a parameter for the Synopsys 10/100/1000
> stmmac Ethernet driver to configure the maximum MTU supported
> by the EMAC instance. Synopsys allows the FIFO sizes to
> be configured when the cores are built for a particular
> device, but do not provide a way for the driver to read
> information from the device about the maximum MTU size
> supported as limited by the device's FIFO size.
>
> This patch has been tested with changes being submitted
> seperately for the Synopsys 10/100/1000 stmmac driver.
>
> Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index eba0e5e..7db314e 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -30,6 +30,10 @@ Required properties:
>
> Optional properties:
> - mac-address: 6 bytes, mac address
> +- snps,max-mtu: Maximum MTU permitted. This parameter is useful since
> + different implementations of the Synopsys MAC may have
> + different FIFO sizes depending on the selections
> + made in Synopsys Core Consultant.
>
> Examples:
>
> @@ -40,5 +44,6 @@ Examples:
> interrupts = <24 23>;
> interrupt-names = "macirq", "eth_wake_irq";
> mac-address = [000000000000]; /* Filled in by U-Boot */
> + snps,max-mtu = <3800>;
> phy-mode = "gmii";
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH net-next 2/2] stmmac: Fix kernel crashes for jumbo frames
From: Vince Bridgers @ 2014-01-10 23:47 UTC (permalink / raw)
To: devicetree, netdev
Cc: peppe.cavallaro, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, dinguyen, rayagond, vbridgers2013
In-Reply-To: <1389397669-10929-1-git-send-email-vbridgers2013@gmail.com>
These changes correct the following issues with jumbo frames on the
stmmac driver:
1) The Synopsys EMAC can be configured to support different FIFO
sizes at core configuration time. There's no way to query the
controller and know the FIFO size, so the driver needs to get this
information from the device tree in order to know how to correctly
handle MTU changes and setting up dma buffers. A change was submitted
for the device tree seperately to add a maxmtu property for the
Synopsys EMAC configuration.
2) The driver was enabling Jumbo frames by default, but was not allocating
dma buffers of sufficient size to handle the maximum possible packet
size that could be received. This led to memory corruption since DMAs were
occurring beyond the extent of the allocated receive buffers for certain types
of network traffic.
kernel BUG at net/core/skbuff.c:126!
Internal error: Oops - BUG: 0 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 563 Comm: sockperf Not tainted 3.13.0-rc6-01523-gf7111b9 #31
task: ef35e580 ti: ef252000 task.ti: ef252000
PC is at skb_panic+0x60/0x64
LR is at skb_panic+0x60/0x64
pc : [<c03c7c3c>] lr : [<c03c7c3c>] psr: 60000113
sp : ef253c18 ip : 60000113 fp : 00000000
r10: ef3a5400 r9 : 00000ebc r8 : ef3a546c
r7 : ee59f000 r6 : ee59f084 r5 : ee59ff40 r4 : ee59f140
r3 : 000003e2 r2 : 00000007 r1 : c0b9c420 r0 : 0000007d
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 2e8ac04a DAC: 00000015
Process sockperf (pid: 563, stack limit = 0xef252248)
Stack: (0xef253c18 to 0xef254000)
3c00: 00000ebc ee59f000
3c20: ee59f084 ee59ff40 ee59f140 c04a9cd8 ee8c50c0 00000ebc ee59ff40 00000000
3c40: ee59f140 c02d0ef0 00000056 ef1eda80 ee8c50c0 00000ebc 22bbef29 c0318f8c
3c60: 00000056 ef3a547c ffe2c716 c02c9c90 c0ba1298 ef3a5838 ef3a5838 ef3a5400
3c80: 000020c0 ee573840 000055cb ef3f2050 c053f0e0 c0319214 22b9b085 22d92813
3ca0: 00001c80 004b8e00 ef3a5400 ee573840 ef3f2064 22d92813 ef3f2064 000055cb
3cc0: ef3f2050 c031a19c ef252000 00000000 00000000 c0561bc0 00000000 ff00ffff
3ce0: c05621c0 ef3a5400 ef3f2064 ee573840 00000020 ef3f2064 000055cb ef3f2050
3d00: c053f0e0 c031cad0 c053e740 00000e60 00000000 00000000 ee573840 ef3a5400
3d20: ef0a6e00 00000000 ef3f2064 c032507c 00010000 00000020 c0561bc0 c0561bc0
3d40: ee599850 c032799c 00000000 ee573840 c055a380 ef3a5400 00000000 ef3f2064
3d60: ef3f2050 c032799c 0101c7c0 2b6755cb c059a280 c030e4d8 000055cb ffffffff
3d80: ee574fc0 c055a380 ee574000 ee573840 00002b67 ee573840 c03fe9c4 c053fa68
3da0: c055a380 00001f6f 00000000 ee573840 c053f0e0 c0304fdc ef0a6e01 ef3f2050
3dc0: ee573858 ef031000 ee573840 c03055d8 c0ba0c40 ef000f40 00100100 c053f0dc
3de0: c053ffdc c053f0f0 00000008 00000000 ef031000 c02da948 00001140 00000000
3e00: c0563c78 ef253e5f 00000020 ee573840 00000020 c053f0f0 ef313400 ee573840
3e20: c053f0e0 00000000 00000000 c05380c0 ef313400 00001000 00000015 c02df280
3e40: ee574000 ef001e00 00000000 00001080 00000042 005cd980 ef031500 ef031500
3e60: 00000000 c02df824 ef031500 c053e390 c0541084 f00b1e00 c05925e8 c02df864
3e80: 00001f5c ef031440 c053e390 c0278524 00000002 00000000 c0b9eb48 c02df280
3ea0: ee8c7180 00000100 c0542ca8 00000015 00000040 ef031500 ef031500 ef031500
3ec0: c027803c ef252000 00000040 000000ec c05380c0 c0b9eb40 c0b9eb48 c02df940
3ee0: ef060780 ffffa4dd c0564a9c c056343c 002e80a8 00000080 ef031500 00000001
3f00: c053808c ef252000 fffec100 00000003 00000004 002e80a8 0000000c c00258f0
3f20: 002e80a8 c005e704 00000005 00000100 c05634d0 c0538080 c05333e0 00000000
3f40: 0000000a c0565580 c05380c0 ffffa4dc c05434f4 00400100 00000004 c0534cd4
3f60: 00000098 00000000 fffec100 002e80a8 00000004 002e80a8 002a20e0 c0025da8
3f80: c0534cd4 c000f020 fffec10c c053ea60 ef253fb0 c0008530 0000ffe2 b6ef67f4
3fa0: 40000010 ffffffff 00000124 c0012f3c 0000ffe2 002e80f0 0000ffe2 00004000
3fc0: becb6338 becb6334 00000004 00000124 002e80a8 00000004 002e80a8 002a20e0
3fe0: becb6300 becb62f4 002773bb b6ef67f4 40000010 ffffffff 00000000 00000000
[<c03c7c3c>] (skb_panic+0x60/0x64) from [<c02d0ef0>] (skb_put+0x4c/0x50)
[<c02d0ef0>] (skb_put+0x4c/0x50) from [<c0318f8c>] (tcp_collapse+0x314/0x3ec)
[<c0318f8c>] (tcp_collapse+0x314/0x3ec) from [<c0319214>]
(tcp_try_rmem_schedule+0x1b0/0x3c4)
[<c0319214>] (tcp_try_rmem_schedule+0x1b0/0x3c4) from [<c031a19c>]
(tcp_data_queue+0x480/0xe6c)
[<c031a19c>] (tcp_data_queue+0x480/0xe6c) from [<c031cad0>]
(tcp_rcv_established+0x180/0x62c)
[<c031cad0>] (tcp_rcv_established+0x180/0x62c) from [<c032507c>]
(tcp_v4_do_rcv+0x13c/0x31c)
[<c032507c>] (tcp_v4_do_rcv+0x13c/0x31c) from [<c032799c>]
(tcp_v4_rcv+0x718/0x73c)
[<c032799c>] (tcp_v4_rcv+0x718/0x73c) from [<c0304fdc>]
(ip_local_deliver+0x98/0x274)
[<c0304fdc>] (ip_local_deliver+0x98/0x274) from [<c03055d8>]
(ip_rcv+0x420/0x758)
[<c03055d8>] (ip_rcv+0x420/0x758) from [<c02da948>]
(__netif_receive_skb_core+0x44c/0x5bc)
[<c02da948>] (__netif_receive_skb_core+0x44c/0x5bc) from [<c02df280>]
(netif_receive_skb+0x48/0xb4)
[<c02df280>] (netif_receive_skb+0x48/0xb4) from [<c02df824>]
(napi_gro_flush+0x70/0x94)
[<c02df824>] (napi_gro_flush+0x70/0x94) from [<c02df864>]
(napi_complete+0x1c/0x34)
[<c02df864>] (napi_complete+0x1c/0x34) from [<c0278524>]
(stmmac_poll+0x4e8/0x5c8)
[<c0278524>] (stmmac_poll+0x4e8/0x5c8) from [<c02df940>]
(net_rx_action+0xc4/0x1e4)
[<c02df940>] (net_rx_action+0xc4/0x1e4) from [<c00258f0>]
(__do_softirq+0x12c/0x2e8)
[<c00258f0>] (__do_softirq+0x12c/0x2e8) from [<c0025da8>] (irq_exit+0x78/0xac)
[<c0025da8>] (irq_exit+0x78/0xac) from [<c000f020>] (handle_IRQ+0x44/0x90)
[<c000f020>] (handle_IRQ+0x44/0x90) from [<c0008530>]
(gic_handle_irq+0x2c/0x5c)
[<c0008530>] (gic_handle_irq+0x2c/0x5c) from [<c0012f3c>]
(__irq_usr+0x3c/0x60)
3) The driver was setting the dma buffer size after allocating dma buffers,
which caused a system panic when changing the MTU.
BUG: Bad page state in process ifconfig pfn:2e850
page:c0b72a00 count:0 mapcount:0 mapping: (null) index:0x0
page flags: 0x200(arch_1)
Modules linked in:
CPU: 0 PID: 566 Comm: ifconfig Not tainted 3.13.0-rc6-01523-gf7111b9 #29
[<c001547c>] (unwind_backtrace+0x0/0xf8) from [<c00122dc>]
(show_stack+0x10/0x14)
[<c00122dc>] (show_stack+0x10/0x14) from [<c03c793c>] (dump_stack+0x70/0x88)
[<c03c793c>] (dump_stack+0x70/0x88) from [<c00b2620>] (bad_page+0xc8/0x118)
[<c00b2620>] (bad_page+0xc8/0x118) from [<c00b302c>]
(get_page_from_freelist+0x744/0x870)
[<c00b302c>] (get_page_from_freelist+0x744/0x870) from [<c00b40f4>]
(__alloc_pages_nodemask+0x118/0x86c)
[<c00b40f4>] (__alloc_pages_nodemask+0x118/0x86c) from [<c00b4858>]
(__get_free_pages+0x10/0x54)
[<c00b4858>] (__get_free_pages+0x10/0x54) from [<c00cba1c>]
(kmalloc_order_trace+0x24/0xa0)
[<c00cba1c>] (kmalloc_order_trace+0x24/0xa0) from [<c02d199c>]
(__kmalloc_reserve.isra.21+0x24/0x70)
[<c02d199c>] (__kmalloc_reserve.isra.21+0x24/0x70) from [<c02d240c>]
(__alloc_skb+0x68/0x13c)
[<c02d240c>] (__alloc_skb+0x68/0x13c) from [<c02d3930>]
(__netdev_alloc_skb+0x3c/0xe8)
[<c02d3930>] (__netdev_alloc_skb+0x3c/0xe8) from [<c0279378>]
(stmmac_open+0x63c/0x1024)
[<c0279378>] (stmmac_open+0x63c/0x1024) from [<c02e18cc>]
(__dev_open+0xa0/0xfc)
[<c02e18cc>] (__dev_open+0xa0/0xfc) from [<c02e1b40>]
(__dev_change_flags+0x94/0x158)
[<c02e1b40>] (__dev_change_flags+0x94/0x158) from [<c02e1c24>]
(dev_change_flags+0x18/0x48)
[<c02e1c24>] (dev_change_flags+0x18/0x48) from [<c0337bc0>]
(devinet_ioctl+0x638/0x700)
[<c0337bc0>] (devinet_ioctl+0x638/0x700) from [<c02c7aec>]
(sock_ioctl+0x64/0x290)
[<c02c7aec>] (sock_ioctl+0x64/0x290) from [<c0100890>]
(do_vfs_ioctl+0x78/0x5b8)
[<c0100890>] (do_vfs_ioctl+0x78/0x5b8) from [<c0100e0c>] (SyS_ioctl+0x3c/0x5c)
[<c0100e0c>] (SyS_ioctl+0x3c/0x5c) from [<c000e760>]
The fixes have been verified using reproducible, automated testing.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 7 ++-----
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 7 ++++++-
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++++++----
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +++++
include/linux/stmmac.h | 1 +
7 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index fc94f20..97bfb6b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -293,6 +293,8 @@ struct dma_features {
#define STMMAC_CHAIN_MODE 0x1
#define STMMAC_RING_MODE 0x2
+#define JUMBO_LEN 9000
+
struct stmmac_desc_ops {
/* DMA RX descriptor ring initialization */
void (*init_rx_desc) (struct dma_desc *p, int disable_rx_ic, int mode,
@@ -369,7 +371,7 @@ struct stmmac_dma_ops {
struct stmmac_ops {
/* MAC core initialization */
- void (*core_init) (void __iomem *ioaddr);
+ void (*core_init) (void __iomem *ioaddr, int mtu);
/* Enable and verify that the IPC module is supported */
int (*rx_ipc) (void __iomem *ioaddr);
/* Dump MAC registers */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index c12aabb..f37d90f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -126,11 +126,8 @@ enum power_event {
#define GMAC_ANE_PSE (3 << 7)
#define GMAC_ANE_PSE_SHIFT 7
- /* GMAC Configuration defines */
-#define GMAC_CONTROL_TC 0x01000000 /* Transmit Conf. in RGMII/SGMII */
-#define GMAC_CONTROL_WD 0x00800000 /* Disable Watchdog on receive */
-
/* GMAC Configuration defines */
+#define GMAC_CONTROL_2K 0x08000000 /* IEEE 802.3as 2K packets */
#define GMAC_CONTROL_TC 0x01000000 /* Transmit Conf. in RGMII/SGMII */
#define GMAC_CONTROL_WD 0x00800000 /* Disable Watchdog on receive */
#define GMAC_CONTROL_JD 0x00400000 /* Jabber disable */
@@ -156,7 +153,7 @@ enum inter_frame_gap {
#define GMAC_CONTROL_RE 0x00000004 /* Receiver Enable */
#define GMAC_CORE_INIT (GMAC_CONTROL_JD | GMAC_CONTROL_PS | GMAC_CONTROL_ACS | \
- GMAC_CONTROL_JE | GMAC_CONTROL_BE)
+ GMAC_CONTROL_BE)
/* GMAC Frame Filter defines */
#define GMAC_FRAME_FILTER_PR 0x00000001 /* Promiscuous Mode */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index cdd9268..b3e148e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -32,10 +32,15 @@
#include <asm/io.h>
#include "dwmac1000.h"
-static void dwmac1000_core_init(void __iomem *ioaddr)
+static void dwmac1000_core_init(void __iomem *ioaddr, int mtu)
{
u32 value = readl(ioaddr + GMAC_CONTROL);
value |= GMAC_CORE_INIT;
+ if (mtu > 1500)
+ value |= GMAC_CONTROL_2K;
+ if (mtu > 2000)
+ value |= GMAC_CONTROL_JE;
+
writel(value, ioaddr + GMAC_CONTROL);
/* Mask GMAC interrupts */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 5857d67..2ff767b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -32,7 +32,7 @@
#include <asm/io.h>
#include "dwmac100.h"
-static void dwmac100_core_init(void __iomem *ioaddr)
+static void dwmac100_core_init(void __iomem *ioaddr, int mtu)
{
u32 value = readl(ioaddr + MAC_CONTROL);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b8e3a4c..4f5dfd7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -52,7 +52,6 @@
#include "stmmac.h"
#define STMMAC_ALIGN(x) L1_CACHE_ALIGN(x)
-#define JUMBO_LEN 9000
/* Module parameters */
#define TX_TIMEO 5000
@@ -91,7 +90,7 @@ static int tc = TC_DEFAULT;
module_param(tc, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(tc, "DMA threshold control value");
-#define DMA_BUFFER_SIZE BUF_SIZE_2KiB
+#define DMA_BUFFER_SIZE BUF_SIZE_4KiB
static int buf_sz = DMA_BUFFER_SIZE;
module_param(buf_sz, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(buf_sz, "DMA buffer size");
@@ -990,6 +989,8 @@ static int init_dma_desc_rings(struct net_device *dev)
if (bfsize < BUF_SIZE_16KiB)
bfsize = stmmac_set_bfsize(dev->mtu, priv->dma_buf_sz);
+ priv->dma_buf_sz = bfsize;
+
if (netif_msg_probe(priv))
pr_debug("%s: txsize %d, rxsize %d, bfsize %d\n", __func__,
txsize, rxsize, bfsize);
@@ -1079,7 +1080,6 @@ static int init_dma_desc_rings(struct net_device *dev)
}
priv->cur_rx = 0;
priv->dirty_rx = (unsigned int)(i - rxsize);
- priv->dma_buf_sz = bfsize;
buf_sz = bfsize;
/* Setup the chained descriptor addresses */
@@ -1642,7 +1642,7 @@ static int stmmac_open(struct net_device *dev)
priv->plat->bus_setup(priv->ioaddr);
/* Initialize the MAC Core */
- priv->hw->mac->core_init(priv->ioaddr);
+ priv->hw->mac->core_init(priv->ioaddr, dev->mtu);
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
@@ -2229,6 +2229,9 @@ static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
else
max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
+ if (priv->plat->maxmtu < max_mtu)
+ max_mtu = priv->plat->maxmtu;
+
if ((new_mtu < 46) || (new_mtu > max_mtu)) {
pr_err("%s: invalid MTU, max MTU is: %d\n", dev->name, max_mtu);
return -EINVAL;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 38bd1f4..1028c19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -51,6 +51,10 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
sizeof(struct stmmac_mdio_bus_data),
GFP_KERNEL);
+ /* Set the maxmtu to a default of 1500 in case the
+ * parameter is not present in the device tree
+ */
+ plat->maxmtu = JUMBO_LEN;
/*
* Currently only the properties needed on SPEAr600
@@ -60,6 +64,7 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
if (of_device_is_compatible(np, "st,spear600-gmac") ||
of_device_is_compatible(np, "snps,dwmac-3.70a") ||
of_device_is_compatible(np, "snps,dwmac")) {
+ of_property_read_u32(np, "snps,max-mtu", &plat->maxmtu);
plat->has_gmac = 1;
plat->pmt = 1;
}
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index bb5deb0..9689706 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -110,6 +110,7 @@ struct plat_stmmacenet_data {
int force_sf_dma_mode;
int force_thresh_dma_mode;
int riwt_off;
+ int maxmtu;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void (*bus_setup)(void __iomem *ioaddr);
int (*init)(struct platform_device *pdev);
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 1/2] dts: Add a binding for Synopsys emac max-mtu
From: Vince Bridgers @ 2014-01-10 23:47 UTC (permalink / raw)
To: devicetree, netdev
Cc: peppe.cavallaro, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, dinguyen, rayagond, vbridgers2013
In-Reply-To: <1389397669-10929-1-git-send-email-vbridgers2013@gmail.com>
This change adds a parameter for the Synopsys 10/100/1000
stmmac Ethernet driver to configure the maximum MTU supported
by the EMAC instance. Synopsys allows the FIFO sizes to
be configured when the cores are built for a particular
device, but do not provide a way for the driver to read
information from the device about the maximum MTU size
supported as limited by the device's FIFO size.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index eba0e5e..7db314e 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -30,6 +30,10 @@ Required properties:
Optional properties:
- mac-address: 6 bytes, mac address
+- snps,max-mtu: Maximum MTU permitted. This parameter is useful since
+ different implementations of the Synopsys MAC may have
+ different FIFO sizes depending on the selections
+ made in Synopsys Core Consultant.
Examples:
@@ -40,5 +44,6 @@ Examples:
interrupts = <24 23>;
interrupt-names = "macirq", "eth_wake_irq";
mac-address = [000000000000]; /* Filled in by U-Boot */
+ snps,max-mtu = <3800>;
phy-mode = "gmii";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 1/2] ARM: dts: socfpga: DTS updates for stmmac driver
From: Vince Bridgers @ 2014-01-10 23:47 UTC (permalink / raw)
To: devicetree, netdev
Cc: peppe.cavallaro, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, dinguyen, rayagond, vbridgers2013
In-Reply-To: <1389397669-10929-1-git-send-email-vbridgers2013@gmail.com>
This change adds a parameter for the Synopsys 10/100/1000
stmmac Ethernet driver to configure the maximum MTU supported
by the EMAC instance. Synopsys allows the FIFO sizes to
be configured when the cores are built for a particular
device, but do not provide a way for the driver to read
information from the device about the maximum MTU size
supported as limited by the device's FIFO size.
This patch has been tested with changes being submitted
seperately for the Synopsys 10/100/1000 stmmac driver.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index eba0e5e..7db314e 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -30,6 +30,10 @@ Required properties:
Optional properties:
- mac-address: 6 bytes, mac address
+- snps,max-mtu: Maximum MTU permitted. This parameter is useful since
+ different implementations of the Synopsys MAC may have
+ different FIFO sizes depending on the selections
+ made in Synopsys Core Consultant.
Examples:
@@ -40,5 +44,6 @@ Examples:
interrupts = <24 23>;
interrupt-names = "macirq", "eth_wake_irq";
mac-address = [000000000000]; /* Filled in by U-Boot */
+ snps,max-mtu = <3800>;
phy-mode = "gmii";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 0/2] stmmac: Fix kernel crashes for jumbo frames
From: Vince Bridgers @ 2014-01-10 23:47 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: peppe.cavallaro-qxv4g6HH51o, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, dinguyen-EIB2kfCEclfQT0dZR+AlfA,
rayagond-AmucfkJibqKGw+nKnLezzg,
vbridgers2013-Re5JQEeQqe8AvxtiuMwx3w
These patches address two kernel crashes seen when using jumbo frames on
the Synopsys stmmac driver, and adds device tree configurability for the
maximum mtu. The Synopsys emac fifo sizes can be configured when a logic
design is synthesized, but does not provide a way for a driver to query the
exact fifo size.
The crashes seen were due to two issues.
1) The dma buffer size was being set after the dma buffers were allocated.
This caused a crash when changing the mtu since it was possible the buffers
would subsequently be freed using an incorrect dma buffer size. This could
also cause kernel panics due to memory corruption since a large mtu size could
have been configured, but the dma buffers were not sized accordingly.
2) Jumbo frames were being enabled by default, but the dma buffers were not
sized accordingly. This caused memory corruption in the context of certain
types of network traffic, leading to kernel panics.
I've tested these changes using automated, reproducible testware. I can
demonstrate the panics described before the fixes and show that the fixes
address the problems described.
Testing and improvements continue through the use of the mentioned automated
and reproducible testware.
Vince Bridgers
Vince Bridgers (2):
dts: Add a binding for Synopsys emac max-mtu
stmmac: Fix kernel crashes for jumbo frames
Documentation/devicetree/bindings/net/stmmac.txt | 5 +++++
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 7 ++-----
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 7 ++++++-
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++++++----
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +++++
include/linux/stmmac.h | 1 +
8 files changed, 30 insertions(+), 12 deletions(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] sh_eth: fix garbled TX error message
From: Sergei Shtylyov @ 2014-01-10 23:41 UTC (permalink / raw)
To: netdev; +Cc: linux-sh
sh_eth_error() in case of a TX error tries to print a message using 2 dev_err()
calls with the first string not finished by '\n', so that the resulting message
would inevitably come out garbled, with something like "3net eth0: " inserted
in the middle. Avoid that by merging 2 calls into one.
While at it, insert an empty line after the nearby declaration.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Although being a fix, this patch is against the 'net-next.git' repo as it's does
not seem important enough at this time in the release cycle. Please consider it
for the stable kernel though...
drivers/net/ethernet/renesas/sh_eth.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1513,11 +1513,11 @@ ignore_link:
if (intr_status & mask) {
/* Tx error */
u32 edtrr = sh_eth_read(ndev, EDTRR);
+
/* dmesg */
- dev_err(&ndev->dev, "TX error. status=%8.8x cur_tx=%8.8x ",
- intr_status, mdp->cur_tx);
- dev_err(&ndev->dev, "dirty_tx=%8.8x state=%8.8x EDTRR=%8.8x.\n",
- mdp->dirty_tx, (u32) ndev->state, edtrr);
+ dev_err(&ndev->dev, "TX error. status=%8.8x cur_tx=%8.8x dirty_tx=%8.8x state=%8.8x EDTRR=%8.8x.\n",
+ intr_status, mdp->cur_tx, mdp->dirty_tx,
+ (u32)ndev->state, edtrr);
/* dirty buffer free */
sh_eth_txfree(ndev);
^ permalink raw reply
* Re: PROBLEM: usbnet / ax88179_178a: Panic in usb_hcd_map_urb_for_dma
From: Thomas Kear @ 2014-01-10 23:41 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Ben Hutchings, netdev, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87ob3j1ocb.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
On Sat, Jan 11, 2014 at 11:09 AM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
> But looking at the code I think I found and obvious miss in the SG list
> initialisation. I'll post a proposed fix for that. Would be good if
> someone was able to test it.
I've built 3.13.0-rc7-next-20140110 with your patch applied.
Unfortunately since this bug has taken anywhere from minutes to days
to manifest previously I'm not sure how quickly I'll be able to report
on its efficacy.
I currently have the adapter plugged in through a 4-port USB3 hub
(2109:0811, which appears to be a VIA chip) but I will test it
directly attached to the laptop too.
-Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH iproute2] vxlan: add missing dst port setup option
From: Daniel Borkmann @ 2014-01-10 23:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20140110153654.2548f143@nehalam.linuxnetplumber.net>
On 01/11/2014 12:36 AM, Stephen Hemminger wrote:
> On Thu, 9 Jan 2014 12:56:26 +0100
> Daniel Borkmann <dborkman@redhat.com> wrote:
>
>> Kernel commit 823aa873bc ("vxlan: allow choosing destination port
>> per vxlan") and 553675fb5e ("vxlan: listen on multiple ports")
>> make it "now possible to define the same virtual network id but
>> with different UDP port values which can be useful for migration."
>>
>> However, IFLA_VXLAN_PORT netlink attribute was available in the
>> kernel but hasn't been pushed to iproute2 in order to make use
>> of it, hence, add this option so that people can use it.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> ---
>> ip/iplink_vxlan.c | 17 ++++++++++++++++-
>> man/man8/ip-link.8.in | 6 ++++++
>> 2 files changed, 22 insertions(+), 1 deletion(-)
>>
>
> I restored the older version of IFLA_VXLAN_PORT stuff that was reverted
> because that option was broken on 3.10.
Ok, that's fine, thanks Stephen!
^ permalink raw reply
* Re: [PATCH iproute2] vxlan: add missing dst port setup option
From: Stephen Hemminger @ 2014-01-10 23:36 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev
In-Reply-To: <1389268586-3205-1-git-send-email-dborkman@redhat.com>
On Thu, 9 Jan 2014 12:56:26 +0100
Daniel Borkmann <dborkman@redhat.com> wrote:
> Kernel commit 823aa873bc ("vxlan: allow choosing destination port
> per vxlan") and 553675fb5e ("vxlan: listen on multiple ports")
> make it "now possible to define the same virtual network id but
> with different UDP port values which can be useful for migration."
>
> However, IFLA_VXLAN_PORT netlink attribute was available in the
> kernel but hasn't been pushed to iproute2 in order to make use
> of it, hence, add this option so that people can use it.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> ip/iplink_vxlan.c | 17 ++++++++++++++++-
> man/man8/ip-link.8.in | 6 ++++++
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
I restored the older version of IFLA_VXLAN_PORT stuff that was reverted
because that option was broken on 3.10.
^ permalink raw reply
* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: Tom Herbert @ 2014-01-10 23:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1389386629.31367.142.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Jan 10, 2014 at 12:43 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2014-01-10 at 11:42 -0800, Tom Herbert wrote:
>> > Really, 99% of the time gro_list contains zero or one single slot, I
>> > have hard data saying so.
>> >
>> Please provide the data.
>
> Based on a Google patch you can run on your lab host.
>
I don't think your data supports your supposition to be generally true
:-). Just by setting MTU to 500 in your test conditions I was able to
lower the zero or one slot ratio to 80%. In any case, I don't see any
reason to believe that real NAT boxes, routers, cable modems, Android
devices, etc. aren't getting lower rates-- this would *not* be a bad
thing, as link rate increases, request sizes get larger, and there are
more active flows there are going to be more opportunities for packet
aggregation and thus more entries in the gro_list anyway. Throw in
fact that GRO is increasingly important for its value in
virtualization and encapsulation (cases where LRO doesn't apply), and
it's clear that GRO path performance is important and should be
scrutinized!
> lpaa5:~# ethtool -S eth1|egrep "rx_packets|gro"
> rx_packets: 235709959
> gro_complete[0]: 5895809
> gro_overflows[0]: 1495
> gro_nogro[0]: 63584
> gro_msgs[0]: 9791617
> gro_segs[0]: 52290544
> gro_flush[0]: 25
> gro_complete[1]: 6464583
> gro_overflows[1]: 5920
> gro_nogro[1]: 74680
> gro_msgs[1]: 11797481
> gro_segs[1]: 62081299
> gro_flush[1]: 35
> gro_complete[2]: 6289929
> gro_overflows[2]: 4016
> gro_nogro[2]: 71479
> gro_msgs[2]: 11111473
> gro_segs[2]: 58518690
> gro_flush[2]: 42
> gro_complete[3]: 6448928
> gro_overflows[3]: 6781
> gro_nogro[3]: 76417
> gro_msgs[3]: 11845717
> gro_segs[3]: 62730931
> gro_flush[3]: 42
> gro_complete: 25099249
> gro_overflows: 18212
> gro_nogro: 286160
> gro_msgs: 44546288
> gro_segs: 235621464
> gro_flush: 144
>
> The key is the gro_complete thing, meaning that most NAPI poll are
> completed and GRO list flushed.
>
> Here the results are from a synthetic bench (400 concurrent TCP_STREAM),
> very small number of RX queues (trying to force stress load you want),
> increase coalescing parameters on the NIC (to really try to increase
> batches load), plenty of ECN marking to force GRO flushes, and even so,
> you can see :
>
> Average aggregation is : (235621464-286160)/44546288 = 5.28 frames per
> GRO packet.
>
> average NAPI run handles 235709959/25099249 = 9.39 packets
>
> Very few overflows of the gro_list : 18212
>
>
>> > If you want to optimize the case where list is fully populated (because
>> > of yet another synthetic benchmark you use), you really need to build a
>> > temporary list so that all layers do not even have to check
>> > NAPI_GRO_CB(p)->same_flow
>> >
>> Well if you prefer, you can think of the "synthetic benchmark" as
>> emulating an obvious DOS attack by pumping MSS sized TCP segments with
>> random ports to a server. The stack needs to be resilient to such
>> things, an O(n*m) algorithm in the data path is a red flag.
>
> SYN floods are way more effective, or sending small packets with
> MSS=10 : Even with one flow your host wont be resilient at all.
>
> n is what , and m is what ?
>
> GRO is O(8), or O(1). This is the least of your concerns under attack.
>
> I played last year adding a hash table (based on rxhash), and
> my performance tests were not good enough.
>
> profile exactly showed flow dissection being a problem. This is what
> your patch is trying to do.
>
> Optimizing GRO stack to better react to attacks, but lowering
> performance in normal cases was not a win.
>
> So if you believe your patch is really useful in its current form,
> please provide your data.
>
> My opinion is that this one liner is much better.
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index ce01847793c0..be3135d6c12a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3800,6 +3800,7 @@ static void gro_list_prepare(struct napi_struct *napi, struct sk_buff *skb)
>
> diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
> diffs |= p->vlan_tci ^ skb->vlan_tci;
> + diffs |= p->rxhash ^ skb->rxhash;
> if (maclen == ETH_HLEN)
> diffs |= compare_ether_header(skb_mac_header(p),
> skb_gro_mac_header(skb));
>
>
^ permalink raw reply
* Fw: [Bug 68501] New: llc_fixup_skb considers PDU len including ETH_HLEN
From: Stephen Hemminger @ 2014-01-10 23:11 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 10 Jan 2014 03:24:59 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 68501] New: llc_fixup_skb considers PDU len including ETH_HLEN
https://bugzilla.kernel.org/show_bug.cgi?id=68501
Bug ID: 68501
Summary: llc_fixup_skb considers PDU len including ETH_HLEN
Product: Networking
Version: 2.5
Kernel Version: 3.0.75
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: vkatabat@gmail.com
Regression: No
In below snip of code in llc_fixup_skb we calculate pdulen from
eth_hdr(skb)->h_proto which contains total length of packet include ETH_HLEN.
<snip>
119 if (skb->protocol == htons(ETH_P_802_2)) {
120 __be16 pdulen = eth_hdr(skb)->h_proto;
121 s32 data_size = ntohs(pdulen) - llc_len;
122
123 if (data_size < 0 ||
124 !pskb_may_pull(skb, data_size))
125 return 0;
</snip>
Line 121 should be changed to
121 s32 data_size = ntohs(pdulen) - llc_len - ETH_HLEN;
Log
---
kernel: pdu len 18432(72), data_size 69
kernel: skb len 55, skb data_len 0
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] tcp: metrics: Add source-address to tcp-metrics
From: Hannes Frederic Sowa @ 2014-01-10 23:10 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, christoph.paasch, netdev, ycheng, ja
In-Reply-To: <20140110.173711.1541969326146414340.davem@davemloft.net>
On Fri, Jan 10, 2014 at 05:37:11PM -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 08 Jan 2014 15:13:46 -0800
>
> > On Wed, 2014-01-08 at 23:43 +0100, Christoph Paasch wrote:
> >> Hello Eric,
> >>
> >> On 08/01/14 - 09:55:51, Eric Dumazet wrote:
> >> > On Wed, 2014-01-08 at 16:05 +0100, Christoph Paasch wrote:
> >> > > We add the source-address to the tcp-metrics, so that different metrics
> >> > > will be used per source/destination-pair. We use the destination-hash to
> >> > > store the metric inside the hash-table. That way, deleting and dumping
> >> > > via "ip tcp_metrics" is easy.
> >> >
> >> > Note that this has the following problem :
> >> >
> >> > Some applications use a set of source IP addresses to overcome the 64K
> >> > port limitation.
> >>
> >> Ok, did not know about that.
> >>
> >> > tcp_metrics uses a hard-coded TCP_METRICS_RECLAIM_DEPTH value of 5,
> >> > meaning that cache wont be able to store more than 5 source IP addresses
> >> > (reaching one particular remote IP).
> >>
> >> Maybe we could do something like the below (yet untested). That way we allow
> >> up to 32 entries with the same destination but different source and still
> >> only 5 with different destinations.
> >>
> >> I guess 32 * 64K connections is enough. :)
> >> We could also make TCP_METRICS_RECLAIM_DEPTH(_DST) a tunable.
> >
> > Well, not sure if this is a problem anyway, and if we want extra
> > complexity for this rare use case, considering tcp metrics for
> > high number of flows sharing a common path is unlikely to be useful
> > (with exception of Fast Open, but again it must be rare)
>
> I think we are overthinking this, even for the aforementioned case.
>
> If people report that this is a real problem they are hitting, and
> not just with constructed test cases, we can work on a solution.
I was thinking if this would be a problem then one could switch to not
use the source address but something like the interface group index as
the additional match. Seems to fit into the weak end host model.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH v4 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: David Miller @ 2014-01-10 23:10 UTC (permalink / raw)
To: thaller; +Cc: hannes, jiri, netdev, stephen, dcbw
In-Reply-To: <1389227404-12586-1-git-send-email-thaller@redhat.com>
From: Thomas Haller <thaller@redhat.com>
Date: Thu, 9 Jan 2014 01:30:02 +0100
> v1 -> v2: add a second commit, handling NOPREFIXROUTE in ip6_del_addr.
> v2 -> v3: reword commit messages, code comments and some refactoring.
> v3 -> v4: refactor, rename variables, add enum
>
> Thomas Haller (2):
> ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of
> IP6 routes
> ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE
Series applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH] drivers/net: delete non-required instances of include <linux/init.h>
From: David Miller @ 2014-01-10 23:07 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev
In-Reply-To: <1389213167-720-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Wed, 8 Jan 2014 15:32:47 -0500
> None of these files are actually using any __init type directives
> and hence don't need to include <linux/init.h>. Most are just a
> left over from __devinit and __cpuinit removal, or simply due to
> code getting copied from one driver to the next.
>
> This covers everything under drivers/net except for wireless, which
> has been submitted separately.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>
> [build tested drivers/net allyes/modconfig for x86-64, x86, ARM,
> ppc, sparc on todays net-next - v3.13-rc6-1503-g80077935cad2]
Applied, thanks Paul.
^ permalink raw reply
* Re: [PATCH net-next 0/3] bonding: cleanup bond_3ad.c
From: David Miller @ 2014-01-10 23:06 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy
In-Reply-To: <1389196008-28578-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Wed, 8 Jan 2014 16:46:45 +0100
> It's a huge mess there currently - and, thus, really hard to read and
> debug.
>
> This is the first series, and doesn't change the logic at all, only makes
> it a bit more readable.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Series applied, thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2014-01-09
From: David Miller @ 2014-01-10 23:00 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1389279182-3256-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Thu, 9 Jan 2014 15:52:49 +0100
> this is a batch of patches intended for net-next/linux-3.14.
Pulled, thanks Antonio.
> p.s. thanks for notifying me the merge of net into net-next! In this way I
> avoided you to deal with some ugly merge conflicts :)
No problem.
^ permalink raw reply
* Re: [PATCH v3 net-next] packet: doc: describe PACKET_MMAP with one packet socket for rx and tx
From: David Miller @ 2014-01-10 22:58 UTC (permalink / raw)
To: dborkman; +Cc: netdev, nvbolhuis
In-Reply-To: <1389345757-13579-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Fri, 10 Jan 2014 10:22:37 +0100
> From: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
>
> Document how to use one AF_PACKET mmap socket for RX and TX.
>
> Signed-off-by: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Don't you need to evaluate need_rehook with at least the socket
lock held?
Otherwise how would two parallel bind() calls pan out?
^ permalink raw reply
* Re: [PATCH V2 0/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager
From: Ravi Patel @ 2014-01-10 22:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, Loc Ho, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jon Masters, patches-qTEPVZfXA3Y@public.gmane.org, Keyur Chudgar
In-Reply-To: <CAN1v_PsaAeDiLaiP7FfTHFbNRG=UHuom6-2L6NMwzyOOyB+5cA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Jan 5, 2014 at 12:48 PM, Ravi Patel <rapatel-qTEPVZfXA3Y@public.gmane.org> wrote:
> On Sun, Jan 5, 2014 at 10:11 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Sunday 05 January 2014, Ravi Patel wrote:
>>> On Sat, Dec 21, 2013 at 11:03 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>> >
>>> > Please describe here what the purpose of the qmtm is, as this is not
>>> > entirely clear from the code or from your reply.
>>> >
>>> > Greg was guessing that it's a bus controller, my best guess is a DMA
>>> > engine. If it's something completely different, you have to let
>>> > us know what it is so we can do a proper review rather than guessing.
>>> >
>>> > Please provide a link to the data sheet if you are unable to explain.
>>>
>>> Here is URL to a text document explaining role of QMTM device with CPU, Ethernet
>>> subsystem.
>>>
>>> https://drive.google.com/file/d/0B28TgQZ3JLoRRGNnbjJoUGNHWW8/edit?usp=sharing
>>>
>>> For simplicity, I have shown only Ethernet.
>>> PktDMA and Security subsystem interfaces with QMTM in the same way as Ethernet.
>>
>> Thanks, that helps a lot. Please add this file to an appropriate place
>> in the Documentation directory in the next version of your patches.
>>
>> There is still one central aspect that remains unclear to me, which is
>> what the QMTM is actually good for, as opposed to how it gets used from
>> the OS.
>
> The document shows the run-time flow of messages between CPU, QMTM and Ethernet.
> QMTM is a centralized resource manager/driver which exports APIs to
> 1. Initialize & allocate queue & pbn to the Ethernet, PktDMA and
> Security subsystem.
> 2. Read queue state so that subsystems driver knows how much more work
> it can offload
> to its subsystem.
> 3. Apply QoS for subsystems on their queues.
>
>> In the text description, it sounds like the ethernet is the DMA
>> master and performs DMA all by itself but from that it's not clear why
>> a message to and from the QMTM is needed. From your drawing on the other
>> hand, it seems like the QMTM is really the DMA master and performs the
>> DMA on behalf of the ethernet device, which isn't connected to the
>> coherent interface itself. If this is correct, it seems that QMTM is more
>> like a DMA engine after all that should use the existing slave API to
>> provide services to slave drivers.
>
> Each subsystem defines their own format of work message.
> A message (or queue descriptor) has attribute fields (QMTM specific)
> which is common
> for all subsystem work messages.
> The remaining fields of a message are specific to subsystem.
> QMTM device doesn't have any knowledge of these subsystem specific
> fields and the data
> operation which subsystem is going to perform using these fields.
> e.g.
> 1. Ethernet work message includes data address & length which is used
> by Ethernet
> DMA engine for copying the data to/from its internal FIFO
> 2. PktDMA work message includes multiple data addresses & lengths for
> doing scatter/gather,
> XOR operations and result data address/es to give back result to the
> CPU (driver)
> 3. Security work message includes data address & length for doing
> encryption or decryption,
> the type of encryption or decryption and result data address to give
> back result to the CPU (driver)
Do you want any further clarification or document related to QMTM.
We want to make sure everyone is on same page, understand and
conclude upon that QMTM is a device and and not a bus or a dma
engine.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] Make tcp-metrics source-address aware
From: David Miller @ 2014-01-10 22:38 UTC (permalink / raw)
To: christoph.paasch; +Cc: netdev, eric.dumazet, ycheng, ja
In-Reply-To: <1389193559-16756-1-git-send-email-christoph.paasch@uclouvain.be>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Wed, 8 Jan 2014 16:05:54 +0100
> Currently tcp-metrics only stores per-destination addresses. This brings
> problems, when a host has multiple interfaces (e.g., a smartphone having
> WiFi/3G):
>
> For example, a host contacting a server over WiFi will store the tcp-metrics
> per destination IP. If then the host contacts the same server over 3G, the
> same tcp-metrics will be used, although the path-characteristics are completly
> different (e.g., the ssthresh is probably not the same).
>
> In case of TFO this is not a problem, as the server will provide us a new cookie
> once he saw our SYN+DATA with an incorrect cookie.
> It may be (in case of carrier-grade NAT), that we keep the same public IP but
> have a different private IP. Thus, we better reuse the old cookie even if our
> source-IP has changed. However, this scenario is probably very uncommon, as
> carriers try to provide the same src-IP to the clients behind their CGN.
>
> Patches 1 + 2 add the source-IP to the tcp metrics.
>
> Patches 3 to 5 modify the netlink-api to support the source-IP. From now on,
> when using the command "ip tcp_metrics delete address ADDRESS" all entries
> which match this destination IP will be deleted.
>
> Today's iproute2 will complain when doing "ip tcp_metrics flush PREFIX" if
> several entries are present for the same destination-IP but with different
> source-IPs:
>
> root@client:~/test# ip tcp_metrics
> 10.2.1.2 age 3.640sec rtt 16250us rttvar 15000us cwnd 10
> 10.2.1.2 age 4.030sec rtt 18750us rttvar 15000us cwnd 10
> root@client:~/test# ip tcp_metrics flush 10.2.1.2/16
> Failed to send flush request
> : No such process
>
>
> Follow-up patches will modify iproute2 to handle this correctly and allow
> specifying the source-IP in the get/del commands.
>
>
> v2: Added the patch that allows to selectively get/del of tcp-metrics based
> on src-IP and moved the patch that adds the new netlink attribute before
> the other patches.
Looks good, series applied, thanks Christoph.
^ 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