* [PATCH 2/3] ixgb: Add missing dma_mapping_error-call in ixgb_alloc_rx_buffers
From: Christoph Paasch @ 2013-03-16 10:32 UTC (permalink / raw)
To: Jeff Kirsher, Bruce Allan, Alex Duyck; +Cc: e1000-devel, netdev, David Miller
In-Reply-To: <1363429925-12724-1-git-send-email-christoph.paasch@uclouvain.be>
After dma_map_single, dma_mapping_error must be called. It seems safe to
not free the skb allocated in this function, as the skb can be reused
later.
Additionally this patch fixes one coding-style error.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index e23f023..6662c7c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -2155,6 +2155,10 @@ map_skb:
skb->data,
adapter->rx_buffer_len,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(&pdev->dev, buffer_info->dma)) {
+ adapter->alloc_rx_buff_failed++;
+ break;
+ }
rx_desc = IXGB_RX_DESC(*rx_ring, i);
rx_desc->buff_addr = cpu_to_le64(buffer_info->dma);
@@ -2164,7 +2168,8 @@ map_skb:
rx_desc->status = 0;
- if (++i == rx_ring->count) i = 0;
+ if (++i == rx_ring->count)
+ i = 0;
buffer_info = &rx_ring->buffer_info[i];
}
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH 0/3] net/intel: Add missing calls to dma_mapping_error
From: Christoph Paasch @ 2013-03-16 10:32 UTC (permalink / raw)
To: Jeff Kirsher, Bruce Allan, Alex Duyck; +Cc: e1000-devel, netdev, David Miller
After dma_map_single/page, dma_mapping_error must be called.
Christoph Paasch (3):
e1000: ethtool: Add missing dma_mapping_error-call in
e1000_setup_desc_rings
ixgb: Add missing dma_mapping_error-call in ixgb_alloc_rx_buffers
e1000e: Add missing dma_mapping_error-call in
e1000_alloc_jumbo_rx_buffers
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 14 +++++++++++---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++++++-
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 7 ++++++-
3 files changed, 23 insertions(+), 5 deletions(-)
--
1.8.1.227.g44fe835
^ permalink raw reply
* [PATCH 1/3] e1000: ethtool: Add missing dma_mapping_error-call in e1000_setup_desc_rings
From: Christoph Paasch @ 2013-03-16 10:32 UTC (permalink / raw)
To: Jeff Kirsher, Bruce Allan, Alex Duyck; +Cc: e1000-devel, netdev, David Miller
In-Reply-To: <1363429925-12724-1-git-send-email-christoph.paasch@uclouvain.be>
After dma_map_single, dma_mapping_error must be called.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index 43462d5..ffd2871 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -1053,6 +1053,10 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
txdr->buffer_info[i].dma =
dma_map_single(&pdev->dev, skb->data, skb->len,
DMA_TO_DEVICE);
+ if (dma_mapping_error(&pdev->dev, txdr->buffer_info[i].dma)) {
+ ret_val = 4;
+ goto err_nomem;
+ }
tx_desc->buffer_addr = cpu_to_le64(txdr->buffer_info[i].dma);
tx_desc->lower.data = cpu_to_le32(skb->len);
tx_desc->lower.data |= cpu_to_le32(E1000_TXD_CMD_EOP |
@@ -1069,7 +1073,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
rxdr->buffer_info = kcalloc(rxdr->count, sizeof(struct e1000_buffer),
GFP_KERNEL);
if (!rxdr->buffer_info) {
- ret_val = 4;
+ ret_val = 5;
goto err_nomem;
}
@@ -1077,7 +1081,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
rxdr->desc = dma_alloc_coherent(&pdev->dev, rxdr->size, &rxdr->dma,
GFP_KERNEL);
if (!rxdr->desc) {
- ret_val = 5;
+ ret_val = 6;
goto err_nomem;
}
memset(rxdr->desc, 0, rxdr->size);
@@ -1101,7 +1105,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, GFP_KERNEL);
if (!skb) {
- ret_val = 6;
+ ret_val = 7;
goto err_nomem;
}
skb_reserve(skb, NET_IP_ALIGN);
@@ -1110,6 +1114,10 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
rxdr->buffer_info[i].dma =
dma_map_single(&pdev->dev, skb->data,
E1000_RXBUFFER_2048, DMA_FROM_DEVICE);
+ if (dma_mapping_error(&pdev->dev, rxdr->buffer_info[i].dma)) {
+ ret_val = 8;
+ goto err_nomem;
+ }
rx_desc->buffer_addr = cpu_to_le64(rxdr->buffer_info[i].dma);
memset(skb->data, 0x00, skb->len);
}
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH 3/3] e1000e: Add missing dma_mapping_error-call in e1000_alloc_jumbo_rx_buffers
From: Christoph Paasch @ 2013-03-16 10:32 UTC (permalink / raw)
To: Jeff Kirsher, Bruce Allan, Alex Duyck; +Cc: e1000-devel, netdev, David Miller
In-Reply-To: <1363429925-12724-1-git-send-email-christoph.paasch@uclouvain.be>
After dma_map_page, dma_mapping_error must be called. It seems safe to
not free the skb/page allocated in this function, as the skb/page can be
reused later.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 142ca39..5706dcd 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -846,11 +846,16 @@ check_page:
}
}
- if (!buffer_info->dma)
+ if (!buffer_info->dma) {
buffer_info->dma = dma_map_page(&pdev->dev,
buffer_info->page, 0,
PAGE_SIZE,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(&pdev->dev, buffer_info->dma)) {
+ adapter->alloc_rx_buff_failed++;
+ break;
+ }
+ }
rx_desc = E1000_RX_DESC_EXT(*rx_ring, i);
rx_desc->read.buffer_addr = cpu_to_le64(buffer_info->dma);
--
1.8.1.227.g44fe835
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: igb_poll - device driver failed to check map error
From: Christoph Paasch @ 2013-03-16 9:27 UTC (permalink / raw)
To: Allan, Bruce W
Cc: Alexander Duyck, Kirsher, Jeffrey T, Brandeburg, Jesse,
Duyck, Alexander H, Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <804857E1F29AAC47BF68C404FC60A1844D9E2F00@ORSMSX103.amr.corp.intel.com>
On Friday 15 March 2013 16:03:47 Allan, Bruce W wrote:
> You are correct re. the missing calls to dma_mapping_error and I have that
> on my to-do list for e1000e, but if you have patches already feel free to
> send them along (please cc the Intel wired ethernet list
> e1000-devel@lists.sourceforge.net).
I will send them soon, after some basic tests.
Cheers,
Christoph
--
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://multipath-tcp.org
UCLouvain
--
^ permalink raw reply
* RE: [PATCH net] bnx2x: add missing napi deletion in error path
From: Dmitry Kravkov @ 2013-03-16 8:18 UTC (permalink / raw)
To: Michal Schmidt, netdev@vger.kernel.org
Cc: Merav Sicron, Eilon Greenstein, Yuval Mintz
In-Reply-To: <1363361274-25754-1-git-send-email-mschmidt@redhat.com>
> -----Original Message-----
> From: Michal Schmidt [mailto:mschmidt@redhat.com]
> Sent: Friday, March 15, 2013 5:28 PM
> To: netdev@vger.kernel.org
> Cc: Merav Sicron; Eilon Greenstein; Dmitry Kravkov; Yuval Mintz
> Subject: [PATCH net] bnx2x: add missing napi deletion in error path
>
> If the hardware initialization fails in bnx2x_nic_load() after adding
> napi objects, they would not be deleted. A subsequent attempt to unload
> the bnx2x module detects a corruption in the napi list.
>
> Add the missing napi deletion to the error path.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> index a923bc4..4046f97 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> @@ -2760,6 +2760,7 @@ load_error2:
> bp->port.pmf = 0;
> load_error1:
> bnx2x_napi_disable(bp);
> + bnx2x_del_all_napi(bp);
>
> /* clear pf_load status, as it was already set */
> if (IS_PF(bp))
> --
> 1.8.1.4
>
Thanks, Michal!
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
^ permalink raw reply
* Re: [RFC PATCH net-next (V2, RESENT)] ipv6: Queue fragments per interface for multicast/link-local addresses.
From: Hannes Frederic Sowa @ 2013-03-16 7:47 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev, netfilter-devel
In-Reply-To: <511FB776.8000901@linux-ipv6.org>
On Sun, Feb 17, 2013 at 01:44:38AM +0900, YOSHIFUJI Hideaki wrote:
> We should queue fragments for the same link-local address on
> different interfaces (e.g. fe80::1%eth0 and fe80::1%eth1) to the
> different queue, because of nature of addressing architecture.
>
> Similarly, we should queue fragments for multicast on different
> interface to the different queue. This is okay because
> application joins group on speicific interface, and multicast
> traffic is expected only on that interface.
>
> CC: Ben Greear <greearb@candelatech.com>
> CC: Vlad Yasevich <vyasevic@redhat.com>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
I just found this patch while cleaning up my tree. I don't know its state
(netdev patchworks says RFC and netfilter patchworks still lists it as
new). However, I also do think that the per interface matching would be
the right thing to do for multicast|linklocal fragments. Perhaps this patch
should be resend?
Yoshifuji, do you think we should also implement RFC 3168 5.3 ECN
fragmentation protection in reassembly.c? I think it should be
straightforward because it is already implemented for ipv4 and the
relevant bits just need to be moved to inet_fragment.c and become a bit
more generalized.
Thanks,
Hannes
^ permalink raw reply
* Re: [net PATCH 1/1] drivers: net: ethernet: ti: davinci_emac: fix usage of cpdma_check_free_tx_desc()
From: Prabhakar Lad @ 2013-03-16 7:13 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem, linux-omap, dlos
In-Reply-To: <1363356616-32480-1-git-send-email-mugunthanvnm@ti.com>
Hi Mugunthan
Thanks for the patch!
On Fri, Mar 15, 2013 at 7:40 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> Fix which was done in the following commit in cpsw driver has
> to be taken forward to davinci emac driver as well.
>
> commit d35162f89b8f00537d7b240b76d2d0e8b8d29aa0
> Author: Daniel Mack <zonque@gmail.com>
> Date: Tue Mar 12 06:31:19 2013 +0000
>
> net: ethernet: cpsw: fix usage of cpdma_check_free_tx_desc()
>
> Commit fae50823d0 ("net: ethernet: davinci_cpdma: Add boundary for rx
> and tx descriptors") introduced a function to check the current
> allocation state of tx packets. The return value is taken into account
> to stop the netqork queue on the adapter in case there are no free
> slots.
>
> However, cpdma_check_free_tx_desc() returns 'true' if there is room in
> the bitmap, not 'false', so the usage of the function is wrong.
>
> Reported-by: Prabhakar Lad <prabhakar.csengg@gmail.com>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Tested-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Cheers,
--Prabhakar Lad
http://www.linkedin.com/pub/prabhakar-lad/19/92b/955
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 52c0536..ae1b77a 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -1102,7 +1102,7 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
> /* If there is no more tx desc left free then we need to
> * tell the kernel to stop sending us tx frames.
> */
> - if (unlikely(cpdma_check_free_tx_desc(priv->txchan)))
> + if (unlikely(!cpdma_check_free_tx_desc(priv->txchan)))
> netif_stop_queue(ndev);
>
> return NETDEV_TX_OK;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* connect(2) reassociation regression
From: William Ahern @ 2013-03-16 5:56 UTC (permalink / raw)
To: netdev
I've stumbled upon what may be a regression in connect(2) behavior.
My DNS library uses connect(2) to reassociate UDP sockets. That way the
kernel can filter my packets, and it makes for cleaner code overall. The
Linux manual page makes it pretty clear that this is okay, and at least one
interpretation of POSIX (certainly the one I had) does as well.
At some point in the 3.x cycle (maybe after 3.2.0) something was changed.
Whereas previously any reassociation worked, regardless of destination
network, now if the _first_ association is to the loopback, any subsequent
association to non-loopback fails with EINVAL. However, if the loopback is
the second or later association then everything continues to work. In other
words, the sequence
connect(127.0.0.1), connect(8.8.8.8)
fails with EINVAL, but
connect(8.8.8.8), connect(127.0.0.1), connect(1.2.3.4)
succeeds.
I admit that originally I simply presumed that on each reassociation the
kernel would handle reassociating the source address in addition to the
destination address. The technique worked everywhere I tested, including
Linux, Solaris, NetBSD, OpenBSD, FreeBSD. And I should note that it even
worked when reassociating to different external networks (and still works on
everything but Linux, AFAICT).
I realize now that arguably POSIX only requires that a second connnect call
change the destination address, and not the source address. But what would
be the point of allowing a reassociation if the source address is never
changed? Because any two addresses may route to entirely different networks
or over different devices, the capability to reassociate would be pointless.
OTOH, if you explicitly called bind before connect, most systems these days
will unbind the source address when reassociating. That may be undesirable
behavior, but it is long-standing behavior AFAICT, including on Linux. One
way to bypass the new Linux behavior is to reset the socket with
connect(AF_UNSPEC), but under the pedantic interpretation of POSIX that's
not guaranteed to work.
I first posted this issue on comp.unix.programmer, including example code.
The thread is at
https://groups.google.com/forum/?fromgroups=#!topic/comp.unix.programmer/ya0V-rr8ip0
Although it's hard to follow w/ Google's horrendous interface.
^ permalink raw reply
* Re: [PATCH net-next] drivers:net: dma_alloc_coherent: use __GFP_ZERO instead of memset(, 0)
From: Joe Perches @ 2013-03-16 4:18 UTC (permalink / raw)
To: Abodunrin, Akeem G
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
e1000-devel@lists.sourceforge.net, linux-wireless@vger.kernel.org,
b43-dev@lists.infradead.org, users@rt2x00.serialmonkey.com
In-Reply-To: <CFEEE81102D91947B9CC368106979EBA3CF55939@ORSMSX102.amr.corp.intel.com>
On Fri, 2013-03-15 at 22:51 +0000, Abodunrin, Akeem G wrote:
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Joe Perches
[]
> Reduce the number of calls required to alloc a zeroed block of memory.
[]
> diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
[]
> @@ -488,7 +487,6 @@ int igbvf_setup_rx_resources(struct igbvf_adapter *adapter,
>
> rx_ring->desc = dma_alloc_coherent(&pdev->dev, rx_ring->size,
> &rx_ring->dma, GFP_KERNEL);
> -
> if (!rx_ring->desc)
> goto err;
>
> Hi Joe,
Hello Akeem.
> Your changes did not seem to make it to igbvf/netdev.c - I think
> instead of removing an extra line added for code clarity, you
> want to add:
> "tx_ring->desc = dma_alloc_coherent(&pdev->dev, tx_ring->size,
> &tx_ring->dma, GFP_KERNEL| __GFP_ZERO);"
Not really, there's no memset here so this
bit is just a whitespace neatening.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: reset transport header if it was not set before transmission
From: Eric Dumazet @ 2013-03-16 2:10 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, mst, Eric Dumazet
In-Reply-To: <1363333305-54398-2-git-send-email-jasowang@redhat.com>
On Fri, 2013-03-15 at 15:41 +0800, Jason Wang wrote:
> Some drivers depends on transport_header to do packet transmission, but it was
> unset in some cases (one example is macvtap driver which build skbs from
> userspace and generate CHECKSUM_NONE packets). The driver may crash in those
> cases since the transport_header was not valid. The problem becomes more obvious
> since commit fda55eca5a33f33ffcd4192c6b2d75179714a52c (net: introduce
> skb_transport_header_was_set()) since it initializes transport_header to ~0U.
>
> So before passing the skb to driver, this patch reset the transport_header if it
> was not set to avoid such crash such as:
>
> hp-z800-04.qe.lab.eng.nay.redhat.com login: BUG: unable to handle kernel paging
> request at ffff8805166f760c
> IP: [<ffffffffa035a5d0>] ixgbe_xmit_frame_ring+0x220/0x5e0 [ixgbe]
> PGD 1ece067 PUD 0
> Oops: 0000 [#1] SMP
> Modules linked in: vhost_net tun nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache
> lockd autofs4 sunrpc openvswitch ipv6 iTCO_wdt iTCO_vendor_support hp_wmi
> sparse_keymap rfkill acpi_cpufreq freq_table mperf coretemp kvm_intel kvm
> crc32c_intel ghash_clmulni_intel microcode serio_raw pcspkr sg lpc_ich mfd_core
> tg3 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
> snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac
> edac_core ixgbe dca ptp pps_core mdio ext4(F) mbcache(F) jbd2(F) sd_mod(F)
> crc_t10dif(F) sr_mod(F) cdrom(F) firewire_ohci(F) firewire_core(F) crc_itu_t(F)
> aesni_intel(F) ablk_helper(F) cryptd(F) lrw(F) aes_x86_64(F) xts(F) gf128mul(F)
> floppy(F) mptsas(F) mptscsih(F) mptbase(F) scsi_transport_sas(F) ahci(F)
> libahci(F) nouveau(F) ttm(F) drm_kms_helper(F) drm(F) i2c_algo_bit(F)
> i2c_core(F) mxm_wmi(F) video(F) wmi(F) dm_mirror(F) dm_region_hash(F) dm_log(F)
> dm_mod(F) [last unloaded: tun]
> CPU 6
> Pid: 17337, comm: vhost-17317 Tainted: GF 3.9.0-rc1+ #7
> Hewlett-Packard HP Z800 Workstation/0AECh
> RIP: 0010:[<ffffffffa035a5d0>] [<ffffffffa035a5d0>]
> ixgbe_xmit_frame_ring+0x220/0x5e0 [ixgbe]
> RSP: 0018:ffff880222cddb18 EFLAGS: 00010286
> RAX: 00000000ffffffff RBX: ffff880416b4b000 RCX: ffff8805166f75ff
> RDX: 0000000000000008 RSI: ffff8804166f760e RDI: 0000000000000007
> RBP: ffff880222cddb68 R08: 0000000000000008 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90009dce120
> R13: ffff880416b4b300 R14: 0000000000000000 R15: ffff8804118f0800
> FS: 0000000000000000(0000) GS:ffff88042fc40000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffff8805166f760c CR3: 000000041e98c000 CR4: 00000000000027e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process vhost-17317 (pid: 17337, threadinfo ffff880222cdc000, task
> ffff8802211d4040)
> Stack:
> 00000000ffffffff 0000000000000180 ffff880222cddbb7 0000000000000180
> ffff880222cddb48 ffff88040d5dd1c0 ffff8804118f0000 0000000000000036
> ffff8804118f0000 ffff8804165d7a9c ffff880222cddb88 ffffffffa035a9d3
> Call Trace:
> [<ffffffffa035a9d3>] ixgbe_xmit_frame+0x43/0x90 [ixgbe]
> [<ffffffff8149d54a>] dev_hard_start_xmit+0x12a/0x570
> [<ffffffff814bd8da>] sch_direct_xmit+0xfa/0x1d0
> [<ffffffff8149db28>] dev_queue_xmit+0x198/0x4c0
> [<ffffffff813d23fa>] macvlan_start_xmit+0x6a/0x170
> [<ffffffff813d3974>] macvtap_get_user+0x404/0x4e0
> [<ffffffff813d3a7b>] macvtap_sendmsg+0x2b/0x30
> [<ffffffffa06d9efa>] handle_tx+0x34a/0x680 [vhost_net]
> [<ffffffffa06da265>] handle_tx_kick+0x15/0x20 [vhost_net]
> [<ffffffffa06d7dfc>] vhost_worker+0x10c/0x1c0 [vhost_net]
> [<ffffffffa06d7cf0>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
> [<ffffffffa06d7cf0>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
> [<ffffffff8107b77e>] kthread+0xce/0xe0
> [<ffffffff8107b6b0>] ? kthread_freezable_should_stop+0x70/0x70
> [<ffffffff815749ec>] ret_from_fork+0x7c/0xb0
> [<ffffffff8107b6b0>] ? kthread_freezable_should_stop+0x70/0x70
> Code: 34 31 0f 84 d3 01 00 00 66 83 fa 08 0f 85 b9 00 00 00 80 7e 09 06 0f 85 af
> 00 00 00 8b 80 cc 00 00 00 48 01 c1 0f 84 a0 00 00 00 <0f> b6 41 0d a8 01 0f 85
> 94 00 00 00 a8 02 75 0a 41 3a 7d 5c 0f
> RIP [<ffffffffa035a5d0>] ixgbe_xmit_frame_ring+0x220/0x5e0 [ixgbe]
> RSP <ffff880222cddb18>
> CR2: ffff8805166f760c
>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> net/core/dev.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 480114d..db315a1 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2525,6 +2525,9 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> }
> }
>
> + if (!skb_transport_header_was_set(skb))
> + skb_reset_transport_header(skb);
> +
> if (!list_empty(&ptype_all))
> dev_queue_xmit_nit(skb, dev);
>
Hmm... This really looks strange.
Any way we can avoid adding this to fast path, for people not using
macvtap and ixgbe ?
^ permalink raw reply
* Re: [PATCH] net core: optimize netdev_create_hash()
From: Wei Yang @ 2013-03-16 1:19 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20130316000051.GA5941@richard.(null)>
[resend for syntax error in Message-ID]
David,
Thanks for pointing out the error, it really helps.
I guess last mail is still blocked by the mail server, so I resend it.
Hope it works now.
On Sat, Mar 16, 2013 at 08:00:51AM +0800, Wei Yang wrote:
On Fri, Mar 15, 2013 at 05:39:30PM -0400, David Miller wrote:
>From: Wei Yang <weiyang@linux.vnet.ibm.com>
>Date: Sat, 16 Mar 2013 00:32:11 +0800
>
>> netdev_create_hash() is divded into two steps:
>> 1. allocate space for hash_head
>> 2. initialize hash_head->first to NULL for each hash_head
>>
>> This patch merge the two steps into one step.
>>
>> When allocating the space for hash_head, it will use kzalloc() instead of
>> kmalloc(). Then hash_head->first is set to NULL during the allocation step,
>> which means it is not necessary to call INIT_HLIST_HEAD() for each hash_head.
>>
>> This will:
>> 1. reduce the code size
>> 2. reduce the run time of iteration on initializing hash_head array
>
>Please do not ever post changes like this.
>
>This makes assumtions about the list head implementation that
>we should not make. If someone adds a debugging facility that
>causes lists to be initialized differently, it will be broken
>for this hash table now.
Yes, this is based on the assumtion.
And agree, this will break the behavior.
>
>The reason the abstractions exist is so that people do not
>do things like you are trying to do.
>
>If you want to add an interface in the generic list facilities which
>performs this simplifcation, fine. Implement it and post such a
>suggestion to linux-kernel, and then once such a facility is present
>in Linus's tree we can start using it in the networkng code.
Thanks for your suggestion and kindness.
--
Richard Yang
Help you, Help me
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: igb_poll - device driver failed to check map error
From: Alexander Duyck @ 2013-03-15 23:08 UTC (permalink / raw)
To: christoph.paasch
Cc: Alexander Duyck, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Eric Dumazet, netdev
In-Reply-To: <1899985.NhtD8IVCbT@cpaasch-mac>
On 03/15/2013 12:52 AM, Christoph Paasch wrote:
> On Thursday 14 March 2013 19:18:18 Alexander Duyck wrote:
>> On 03/12/2013 02:31 AM, Christoph Paasch wrote:
>>> Hello,
>>>
>>> I'm seeing a warning while booting my machine when DMA_API_DEBUG is set:
>>>
>>> [ 36.402824] ------------[ cut here ]------------
>>> [ 36.458070] WARNING: at
>>> /home/cpaasch/builder/net-next/lib/dma-debug.c:934
>>> check_unmap+0x648/0x702()
>>> [ 36.567377] Hardware name: ProLiant DL165 G7
>>> [ 36.618452] igb 0000:04:00.0: DMA-API: device driver failed to check
>>> map
>>> error[device address=0x0000000233d9b232] [size=154 bytes] [mapped as
>>> single] [ 36.776640] Modules linked in:
>>> [ 36.815446] Pid: 0, comm: swapper/7 Not tainted 3.9.0-rc1-mptcp+ #101
>>> [ 36.892515] Call Trace:
>>> [ 36.921745] <IRQ> [<ffffffff8102ad7f>] warn_slowpath_common+0x80/0x9a
>>> [ 37.001023] [<ffffffff8102ae2d>] warn_slowpath_fmt+0x41/0x43
>>> [ 37.069771] [<ffffffff811db17f>] check_unmap+0x648/0x702
>>> [ 37.134363] [<ffffffff811db3e9>] debug_dma_unmap_page+0x50/0x52
>>> [ 37.206234] [<ffffffff8136676a>] igb_poll+0x144/0xf7c
>>> [ 37.267706] [<ffffffff8104dd19>] ? sched_clock_cpu+0x46/0xd1
>>> [ 37.336456] [<ffffffff814458ce>] net_rx_action+0xa7/0x1d0
>>> [ 37.402085] [<ffffffff81030b65>] __do_softirq+0xb4/0x16f
>>> [ 37.466673] [<ffffffff81030c90>] irq_exit+0x40/0x87
>>> [ 37.526067] [<ffffffff81002db1>] do_IRQ+0x98/0xaf
>>> [ 37.583378] [<ffffffff815210aa>] common_interrupt+0x6a/0x6a
>>> [ 37.651086] <EOI> [<ffffffff8105d4be>] ?
>>> __tick_nohz_idle_enter+0x116/0x31f
>>> [ 37.736595] [<ffffffff81008a04>] ? default_idle+0x24/0x39
>>> [ 37.802224] [<ffffffff81008c62>] cpu_idle+0x68/0xa4
>>> [ 37.861616] [<ffffffff81519f78>] start_secondary+0x1a9/0x1ad
>>> [ 37.930364] ---[ end trace 01b5bb0fd75a464c ]---
>>>
>>>
>>> It happens shortly after mounting the NFS-root filesystem.
>>>
>>> I tried to understand what is going on, but I am now at my wit's end.
>>>
>>> By adding some print-statements, here is what I found out (not sure if
>>> this is anyhow helpful):
>>>
>>> The difference between tx_buffer->time_stamp and the current 'jiffies' is
>>> up to 2000 jiffies (HZ==1000) at the first time the above warning happens
>>> (this seems too much for me). From then on, I see my print 3-4 times
>>> appear but without such a big difference between the timestamps
>>> (difference around 1 and 2 jiffies).
>>>
>>> Some other stuff, I printed:
>>> tx_buffer->skb: ffff880235054c80
>>> tx_buffer->bytecount: 154
>>> tx_buffer->gso_segs: 1
>>> tx_buffer->protocol: 8
>>> tx_buffer->tx_flags 0x20
>>>
>>>
>>> One last thing:
>>> Am I right that after each call to dma_map_single/page a call to
>>> dma_mapping_error is needed? If that's the case, I have some patches that
>>> add this statement at missing places in the e1000, e1000e and ixgb
>>> driver. But these patches do not fix my above problem.
>>>
>>>
>>> Thanks for your help,
>>> Christoph
>>
>> Christoph,
>>
>> One thing that might be useful would be to reproduce this with a
>> standard 3.9-rc kernel instead of one using the multipath TCP patches.
>> This will help us to verify that the issue is reproducible with a stock
>> kernel and is not related to any ongoing work you may have only in your
>> tree.
>
> Hello,
>
> this is on a clean net-next kernel without any MPTCP-code.
>
> I bisected it down to 787314c35fbb (Merge tag 'iommu-updates-v3.8' of
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu), which simply
> introduces the debug_dma_mapping_error-checks.
>
> Am I right with the missing calls to dma_mapping_error in e1000, e1000e and
> ixgb?
>
> Cheers,
> Christoph
Christoph,
The cause of this issues you are seeing may be due to the fact that the
buffer triggering the error is being reused. I was able to reproduce
this issue occasionally with pktgen if I cloned the skb. What may be
happening is that the buffer is being mapped in the transmit path on one
CPU while on another CPU the buffer is being cleaned. Since the output
of each mapping is the physical address there is nothing to make each
mapping unique and I suspect this is resulting in false hits.
You should be able to verify this if you were to check the skb->users
count as well as the dataref value in the skb_shared_info. I suspect
either the users count of the dataref will be greater than 1.
You might also try testing the patch below to see if it has any effect.
All it does is reorder the free and the unmap so that the buffer is not
freed for reuse until after we have checked it in the unmap path.
Thanks,
Alex
---
drivers/net/ethernet/intel/igb/igb_main.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 4dbd629..0f9c324 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5959,15 +5959,15 @@ static bool igb_clean_tx_irq(struct igb_q_vector
*q_vector)
total_bytes += tx_buffer->bytecount;
total_packets += tx_buffer->gso_segs;
- /* free the skb */
- dev_kfree_skb_any(tx_buffer->skb);
-
/* unmap skb header data */
dma_unmap_single(tx_ring->dev,
dma_unmap_addr(tx_buffer, dma),
dma_unmap_len(tx_buffer, len),
DMA_TO_DEVICE);
+ /* free the skb */
+ dev_kfree_skb_any(tx_buffer->skb);
+
/* clear tx_buffer data */
tx_buffer->skb = NULL;
dma_unmap_len_set(tx_buffer, len, 0);
^ permalink raw reply related
* RE: [PATCH net-next] drivers:net: dma_alloc_coherent: use __GFP_ZERO instead of memset(, 0)
From: Abodunrin, Akeem G @ 2013-03-15 22:51 UTC (permalink / raw)
To: Joe Perches, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, e1000-devel@lists.sourceforge.net,
linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org,
users@rt2x00.serialmonkey.com
In-Reply-To: <dbbfc5e66dba7d2b63549d218407fb0c4031f2ed.1363367992.git.joe@perches.com>
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Joe Perches
Sent: Friday, March 15, 2013 10:24 AM
To: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; e1000-devel@lists.sourceforge.net; linux-wireless@vger.kernel.org; b43-dev@lists.infradead.org; users@rt2x00.serialmonkey.com
Subject: [PATCH net-next] drivers:net: dma_alloc_coherent: use __GFP_ZERO instead of memset(, 0)
Reduce the number of calls required to alloc a zeroed block of memory.
Trivially reduces overall object size.
Other changes around these removals
o Neaten call argument alignment
o Remove an unnecessary OOM message after dma_alloc_coherent failure o Remove unnecessary gfp_t stack variable
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/aeroflex/greth.c | 8 ++------
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 8 ++++----
drivers/net/ethernet/broadcom/bnx2.c | 5 ++---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 9 +++------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 14 ++++++-------
drivers/net/ethernet/broadcom/tg3.c | 11 +++--------
drivers/net/ethernet/brocade/bna/bnad.c | 5 ++---
drivers/net/ethernet/emulex/benet/be_main.c | 14 ++++++-------
drivers/net/ethernet/faraday/ftgmac100.c | 5 ++---
drivers/net/ethernet/faraday/ftmac100.c | 8 ++++----
drivers/net/ethernet/ibm/emac/mal.c | 3 +--
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 6 ++----
drivers/net/ethernet/intel/igbvf/netdev.c | 2 --
snip...
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index d60cd43..bea46bb 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -447,7 +447,6 @@ int igbvf_setup_tx_resources(struct igbvf_adapter *adapter,
tx_ring->desc = dma_alloc_coherent(&pdev->dev, tx_ring->size,
&tx_ring->dma, GFP_KERNEL);
-
if (!tx_ring->desc)
goto err;
@@ -488,7 +487,6 @@ int igbvf_setup_rx_resources(struct igbvf_adapter *adapter,
rx_ring->desc = dma_alloc_coherent(&pdev->dev, rx_ring->size,
&rx_ring->dma, GFP_KERNEL);
-
if (!rx_ring->desc)
goto err;
Hi Joe,
Your changes did not seem to make it to igbvf/netdev.c - I think instead of removing an extra line added for code clarity, you want to add:
"tx_ring->desc = dma_alloc_coherent(&pdev->dev, tx_ring->size,
&tx_ring->dma, GFP_KERNEL| __GFP_ZERO);"
Regards,
Akeem Abodunrin
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] bnx2x: fix occasional statistics off-by-4GB error
From: Maciej Żenczykowski @ 2013-03-15 21:56 UTC (permalink / raw)
To: Maciej Żenczykowski, David S. Miller; +Cc: netdev, Mintz Yuval
In-Reply-To: <CANP3RGdWMHv-7TZ4fvASrmz7NXkO7B2g2RCZwV8ecExUsQTQ2w@mail.gmail.com>
From: Maciej Żenczykowski <maze@google.com>
The UPDATE_QSTAT function introduced on February 15, 2012
in commit 1355b704b9ba "bnx2x: consistent statistics after
internal driver reload" incorrectly fails to handle overflow
during addition of the lower 32-bit field of a stat.
This bug is present since 3.4-rc1 and should thus be considered
a candidate for stable 3.4+ releases.
Google-Bug-Id: 8374428
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Cc: Mintz Yuval <yuvalmin@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
index 364e37ecbc5c..198f6f1c9ad5 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
@@ -459,8 +459,9 @@ struct bnx2x_fw_port_stats_old {
#define UPDATE_QSTAT(s, t) \
do { \
- qstats->t##_hi = qstats_old->t##_hi + le32_to_cpu(s.hi); \
qstats->t##_lo = qstats_old->t##_lo + le32_to_cpu(s.lo); \
+ qstats->t##_hi = qstats_old->t##_hi + le32_to_cpu(s.hi) \
+ + ((qstats->t##_lo < qstats_old->t##_lo) ? 1 : 0); \
} while (0)
#define UPDATE_QSTAT_OLD(f) \
--
1.8.1.3
^ permalink raw reply related
* Re: [PATCH] net core: optimize netdev_create_hash()
From: David Miller @ 2013-03-15 21:39 UTC (permalink / raw)
To: weiyang; +Cc: netdev
In-Reply-To: <1363365131-7906-1-git-send-email-weiyang@linux.vnet.ibm.com>
From: Wei Yang <weiyang@linux.vnet.ibm.com>
Date: Sat, 16 Mar 2013 00:32:11 +0800
> netdev_create_hash() is divded into two steps:
> 1. allocate space for hash_head
> 2. initialize hash_head->first to NULL for each hash_head
>
> This patch merge the two steps into one step.
>
> When allocating the space for hash_head, it will use kzalloc() instead of
> kmalloc(). Then hash_head->first is set to NULL during the allocation step,
> which means it is not necessary to call INIT_HLIST_HEAD() for each hash_head.
>
> This will:
> 1. reduce the code size
> 2. reduce the run time of iteration on initializing hash_head array
Please do not ever post changes like this.
This makes assumtions about the list head implementation that
we should not make. If someone adds a debugging facility that
causes lists to be initialized differently, it will be broken
for this hash table now.
The reason the abstractions exist is so that people do not
do things like you are trying to do.
If you want to add an interface in the generic list facilities which
performs this simplifcation, fine. Implement it and post such a
suggestion to linux-kernel, and then once such a facility is present
in Linus's tree we can start using it in the networkng code.
^ permalink raw reply
* [PATCH net] inet: limit length of fragment queue hash table bucket lists
From: Hannes Frederic Sowa @ 2013-03-15 21:32 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, jbrouer
This patch introduces a constant limit of the fragment queue hash
table bucket list lengths. Currently the limit 128 is choosen somewhat
arbitrary and just ensures that we can fill up the fragment cache with
empty packets up to the default ip_frag_high_thresh limits. It should
just protect from list iteration eating considerable amounts of cpu.
If we reach the maximum length in one hash bucket a warning is printed.
This is implemented on the caller side of inet_frag_find to distinguish
between the different users of inet_fragment.c.
I dropped the out of memory warning in the ipv4 fragment lookup path,
because we already get a warning by the slab allocator.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/inet_frag.h | 9 +++++++++
net/ipv4/inet_fragment.c | 20 +++++++++++++++++++-
net/ipv4/ip_fragment.c | 11 ++++-------
net/ipv6/netfilter/nf_conntrack_reasm.c | 12 ++++++------
net/ipv6/reassembly.c | 8 ++++++--
5 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index 76c3fe5..0a1dcc2 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -43,6 +43,13 @@ struct inet_frag_queue {
#define INETFRAGS_HASHSZ 64
+/* averaged:
+ * max_depth = default ipfrag_high_thresh / INETFRAGS_HASHSZ /
+ * rounded up (SKB_TRUELEN(0) + sizeof(struct ipq or
+ * struct frag_queue))
+ */
+#define INETFRAGS_MAXDEPTH 128
+
struct inet_frags {
struct hlist_head hash[INETFRAGS_HASHSZ];
/* This rwlock is a global lock (seperate per IPv4, IPv6 and
@@ -76,6 +83,8 @@ int inet_frag_evictor(struct netns_frags *nf, struct inet_frags *f, bool force);
struct inet_frag_queue *inet_frag_find(struct netns_frags *nf,
struct inet_frags *f, void *key, unsigned int hash)
__releases(&f->lock);
+void inet_frag_maybe_warn_overflow(struct inet_frag_queue *q,
+ const char *prefix);
static inline void inet_frag_put(struct inet_frag_queue *q, struct inet_frags *f)
{
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index 245ae07..f4fd23d 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -21,6 +21,7 @@
#include <linux/rtnetlink.h>
#include <linux/slab.h>
+#include <net/sock.h>
#include <net/inet_frag.h>
static void inet_frag_secret_rebuild(unsigned long dummy)
@@ -277,6 +278,7 @@ struct inet_frag_queue *inet_frag_find(struct netns_frags *nf,
__releases(&f->lock)
{
struct inet_frag_queue *q;
+ int depth = 0;
hlist_for_each_entry(q, &f->hash[hash], list) {
if (q->net == nf && f->match(q, key)) {
@@ -284,9 +286,25 @@ struct inet_frag_queue *inet_frag_find(struct netns_frags *nf,
read_unlock(&f->lock);
return q;
}
+ depth++;
}
read_unlock(&f->lock);
- return inet_frag_create(nf, f, key);
+ if (depth <= INETFRAGS_MAXDEPTH)
+ return inet_frag_create(nf, f, key);
+ else
+ return ERR_PTR(-ENOBUFS);
}
EXPORT_SYMBOL(inet_frag_find);
+
+void inet_frag_maybe_warn_overflow(struct inet_frag_queue *q,
+ const char *prefix)
+{
+ static const char msg[] = "inet_frag_find: Fragment hash bucket"
+ " list length grew over limit " __stringify(INETFRAGS_MAXDEPTH)
+ ". Dropping fragment.\n";
+
+ if (PTR_ERR(q) == -ENOBUFS)
+ LIMIT_NETDEBUG(KERN_WARNING "%s%s", prefix, msg);
+}
+EXPORT_SYMBOL(inet_frag_maybe_warn_overflow);
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index b6d30ac..a6445b8 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -292,14 +292,11 @@ static inline struct ipq *ip_find(struct net *net, struct iphdr *iph, u32 user)
hash = ipqhashfn(iph->id, iph->saddr, iph->daddr, iph->protocol);
q = inet_frag_find(&net->ipv4.frags, &ip4_frags, &arg, hash);
- if (q == NULL)
- goto out_nomem;
-
+ if (IS_ERR_OR_NULL(q)) {
+ inet_frag_maybe_warn_overflow(q, pr_fmt());
+ return NULL;
+ }
return container_of(q, struct ipq, q);
-
-out_nomem:
- LIMIT_NETDEBUG(KERN_ERR pr_fmt("ip_frag_create: no memory left !\n"));
- return NULL;
}
/* Is the fragment too far ahead to be part of ipq? */
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 54087e9..6700069 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -14,6 +14,8 @@
* 2 of the License, or (at your option) any later version.
*/
+#define pr_fmt(fmt) "IPv6-nf: " fmt
+
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/string.h>
@@ -180,13 +182,11 @@ static inline struct frag_queue *fq_find(struct net *net, __be32 id,
q = inet_frag_find(&net->nf_frag.frags, &nf_frags, &arg, hash);
local_bh_enable();
- if (q == NULL)
- goto oom;
-
+ if (IS_ERR_OR_NULL(q)) {
+ inet_frag_maybe_warn_overflow(q, pr_fmt());
+ return NULL;
+ }
return container_of(q, struct frag_queue, q);
-
-oom:
- return NULL;
}
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 3c6a772..196ab93 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -26,6 +26,9 @@
* YOSHIFUJI,H. @USAGI Always remove fragment header to
* calculate ICV correctly.
*/
+
+#define pr_fmt(fmt) "IPv6: " fmt
+
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/string.h>
@@ -185,9 +188,10 @@ fq_find(struct net *net, __be32 id, const struct in6_addr *src, const struct in6
hash = inet6_hash_frag(id, src, dst, ip6_frags.rnd);
q = inet_frag_find(&net->ipv6.frags, &ip6_frags, &arg, hash);
- if (q == NULL)
+ if (IS_ERR_OR_NULL(q)) {
+ inet_frag_maybe_warn_overflow(q, pr_fmt());
return NULL;
-
+ }
return container_of(q, struct frag_queue, q);
}
--
1.8.1.4
^ permalink raw reply related
* Re: [RFC 0/3] arm: mxs: sanitize enet_out clock handling
From: Trent Piepho @ 2013-03-15 21:27 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-arm-kernel, netdev, Shawn Guo
In-Reply-To: <1359470773-14290-1-git-send-email-w.sang@pengutronix.de>
On Tue, Jan 29, 2013 at 6:46 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> Handling enet_out on MX28 is cumbersome at the moment. Most boards need it
> enabled and for that, they have to add code to mach-mxs.c (see sps1 as an
> example). Since this is board specific, we better encode it in the
> devicetree, that is the reason it was made for.
>
> My proposal will overwrite the generic "clock" and "clock-names" properties
> from imx28.dtsi in the board file. The original one has 2 entries, and boards
> needing enet_out will overload it with three entries. The network driver will
> enable the clock if it was specified. The old code enabling the clock will be
> backward compatible but print a WARN if the legacy mode needs to be used.
Trying this again with proper CCs. gmane's reply interface don't
allow cross-posting or CCs, so I'm trying an alternate method where I
export the raw email from gmane, convert it to an mbox file, then
upload it via imap to gmail, so I can reply from there. We'll see how
badly gmail mangles it.
Anyway, I found this same problem when adding support for a new imx28
board. Ethernet stopped working as soon as I changed the board name
from imx28-evk since the imx28-evk board setup function stopped
running. These patches seem like a good way to fix the problem
without require the same board specific code in the kernel to be
duplicated for each new board.
But as you say most boards need enet_out (AFAICT, all but the Denx
board). So wouldn't it make more sense to add enet_out to the dtsi
file and then just override it in the one board that doesn't need it,
instead of overriding in every board except that one?
^ permalink raw reply
* bnx2x statistics occasionally wrong by near multiples of 4GB.
From: Maciej Żenczykowski @ 2013-03-15 21:03 UTC (permalink / raw)
To: Mintz Yuval; +Cc: Linux NetDev
bnx2x_stats.h:
#define UPDATE_QSTAT(s, t) \
do { \
qstats->t##_hi = qstats_old->t##_hi + le32_to_cpu(s.hi); \
qstats->t##_lo = qstats_old->t##_lo + le32_to_cpu(s.lo); \
} while (0)
Looks wrong because it doesn't deal with overflow of _lo.
I'm not 100% sure if I tracked it down correctly, but I think this is
the root cause of us occasionally seeing stats (/proc/net/dev tx_bytes
in this case) jump back by roughly N*4GB and then go forward again.
In particular we saw successive reads of /proc/net/dev eth0 Transmit bytes show:
0x8F6 45356E60
0x8F4 4C8D72B9
0x8F6 5420D096
(which since this is a sum of 3 values (ucase/mcast/bcast) from all
queues, means we actually wrongly accounted for overflow twice...)
- Maciej
^ permalink raw reply
* Re: [PATCH 1/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
From: Maxime Ripard @ 2013-03-15 21:01 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-doc, netdev, devicetree-discuss, linux-kernel, Rob Herring,
sunny, shuge, Stefan Roese, kevin
In-Reply-To: <1363380605-6577-2-git-send-email-maxime.ripard@free-electrons.com>
Le 15/03/2013 21:50, Maxime Ripard a écrit :
> From: Stefan Roese <sr@denx.de>
>
> The Allwinner A10 has an ethernet controller that is advertised as
> coming from Davicom.
>
> The exact feature set of this controller is unknown, since there is no
> public documentation for this IP, and this driver is mostly the one
> published by Allwinner that has been heavily cleaned up.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../devicetree/bindings/net/davicom-wemac.txt | 20 +
> drivers/net/ethernet/Makefile | 2 +-
> drivers/net/ethernet/davicom/Kconfig | 31 +
> drivers/net/ethernet/davicom/Makefile | 1 +
> drivers/net/ethernet/davicom/wemac.c | 1033 ++++++++++++++++++++
> drivers/net/ethernet/davicom/wemac.h | 130 +++
> 6 files changed, 1216 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/net/davicom-wemac.txt
> create mode 100644 drivers/net/ethernet/davicom/wemac.c
> create mode 100644 drivers/net/ethernet/davicom/wemac.h
>
> diff --git a/Documentation/devicetree/bindings/net/davicom-wemac.txt b/Documentation/devicetree/bindings/net/davicom-wemac.txt
> new file mode 100644
> index 0000000..516cf31
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/davicom-wemac.txt
> @@ -0,0 +1,20 @@
> +* Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
> +
> +Required properties:
> +- compatible: should be "marvell,armada-370-neta".
It looks like I've been a bit too quick to send this one... I'll change
in v2, obviously.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/5] ARM: sunxi: Add support for A10 Ethernet controller
From: Maxime Ripard @ 2013-03-15 20:49 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: kevin, sunny, shuge, netdev
Hi,
The Allwinner A10 SoC has an ethernet that is said to be coming from
Davicom embedded in it. This IP has no public documentation, so exact
details are quite sparse, and this code come from refactored allwinner
code.
Since we don't have any clock support yet for the Allwinner SoCs, we
rely on the bootloader to enable the wemac clock.
Thanks,
Maxime
Maxime Ripard (3):
ARM: sunxi: Add wemac to sun4i dtsi
ARM: sun4i: Add muxing options for the ethernet controller
ARM: hackberry: dt: Add Ethernet controller to the Hackberry device
tree
Stefan Roese (2):
net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
ARM: cubieboard: Enable ethernet (WEMAC) support in dts
.../devicetree/bindings/net/davicom-wemac.txt | 20 +
arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 6 +
arch/arm/boot/dts/sun4i-a10-hackberry.dts | 19 +
arch/arm/boot/dts/sun4i-a10.dtsi | 18 +
drivers/net/ethernet/Makefile | 2 +-
drivers/net/ethernet/davicom/Kconfig | 31 +
drivers/net/ethernet/davicom/Makefile | 1 +
drivers/net/ethernet/davicom/wemac.c | 1033 ++++++++++++++++++++
drivers/net/ethernet/davicom/wemac.h | 130 +++
9 files changed, 1259 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/davicom-wemac.txt
create mode 100644 drivers/net/ethernet/davicom/wemac.c
create mode 100644 drivers/net/ethernet/davicom/wemac.h
--
1.7.10.4
^ permalink raw reply
* [PATCH 5/5] ARM: hackberry: dt: Add Ethernet controller to the Hackberry device tree
From: Maxime Ripard @ 2013-03-15 20:50 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: kevin, sunny, shuge, netdev, Russell King, linux-kernel
In-Reply-To: <1363380605-6577-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun4i-a10-hackberry.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-hackberry.dts b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
index f84549a..3808c1a 100644
--- a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
+++ b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
@@ -23,8 +23,27 @@
};
soc {
+ pio: pinctrl@01c20800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hackberry_hogs>;
+
+ hackberry_hogs: hogs@0 {
+ allwinner,pins = "PH19";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+ };
+
uart0: uart@01c28000 {
status = "okay";
};
+
+ wemac: ethernet@01c0b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wemac_pins_a>;
+ status = "ok";
+ allwinner,power-gpios = <&pio 7 19 0>;
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/5] ARM: cubieboard: Enable ethernet (WEMAC) support in dts
From: Maxime Ripard @ 2013-03-15 20:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: kevin, sunny, shuge, netdev, Stefan Roese, Russell King,
linux-kernel
In-Reply-To: <1363380605-6577-1-git-send-email-maxime.ripard@free-electrons.com>
From: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 88e2dc1..7a3872d 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -43,6 +43,12 @@
uart1: uart@01c28400 {
status = "okay";
};
+
+ wemac: ethernet@01c0b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wemac_pins_a>;
+ status = "okay";
+ };
};
leds {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/5] ARM: sun4i: Add muxing options for the ethernet controller
From: Maxime Ripard @ 2013-03-15 20:50 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Russell King, netdev, linux-kernel, sunny, shuge, kevin
In-Reply-To: <1363380605-6577-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index f3c2158..fc4ce45 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -46,6 +46,17 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ wemac_pins_a: wemac0@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA9", "PA10",
+ "PA11", "PA12", "PA13", "PA14",
+ "PA15", "PA16";
+ allwinner,function = "wemac";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
wemac: ethernet@01c0b000 {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] ARM: sunxi: Add wemac to sun4i dtsi
From: Maxime Ripard @ 2013-03-15 20:50 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Russell King, netdev, linux-kernel, sunny, shuge, kevin
In-Reply-To: <1363380605-6577-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 03d2b53..f3c2158 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -47,5 +47,12 @@
allwinner,pull = <0>;
};
};
+
+ wemac: ethernet@01c0b000 {
+ compatible = "davicom,wemac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ status = "disabled";
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
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