* Re: [PATCH net-next FIX] RDMA/cma: Fix build breakage when infiniband is built-in
From: Or Gerlitz @ 2013-11-12 8:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, amirv, eyalpe
In-Reply-To: <20131111.004319.58572524940129607.davem@davemloft.net>
On 11/11/2013 07:43, David Miller wrote:
> I really want to merge the net-next tree as soon as possible so I
> committed the following:
>
> ====================
> [PATCH] vlan: Implement vlan_dev_get_egress_qos_mask as an inline.
>
> This is to avoid very silly Kconfig dependencies for modules
> using this routine.
>
> Signed-off-by: David S. Miller<davem@davemloft.net>
Dave, I have checked it in our environment and things work as expected,
thanks for taking care.
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Arnaud Ebalard @ 2013-11-12 7:56 UTC (permalink / raw)
To: Cong Wang; +Cc: linux-arm-kernel, netdev, stable, edumazet
In-Reply-To: <slrnl83jr5.49f.xiyou.wangcong@linux-6brj.site>
Hi,
Thanks for the pointer. See below.
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Sun, 10 Nov 2013 at 13:53 GMT, Arnaud Ebalard <arno@natisbad.org> wrote:
>> Hi,
>>
>> I decided to upgrade the kernel on one of my ReadyNAS 102 from 3.11.1 to
>> 3.11.7. The device is based on Marvell Armada 370 SoC and uses mvneta
>> driver. Mine runs Debian armel unstable but I can confirm the issue also
>> happens on a debian harmhf unstable.
>>
> [...]
>>
>> Then, knowing that, I started a git bisect session on stable tree to end
>> up with the following suspects. I failed to go any further to a single
>> commit, due to crashes, but I could recompile a kernel w/ debug info and
>> report what I get if neeeded.
>>
>> commit dc0791aee672 tcp: do not forget FIN in tcp_shifted_skb() [bad]
>> commit 18ddf5127c9f tcp: must unclone packets before mangling them
>> commit 80bd5d8968d8 tcp: TSQ can use a dynamic limit
>> commit dbeb18b22197 tcp: TSO packets automatic sizing
>> commit 50704410d014 Linux 3.11.6 [good]
>>
>
> This regression is probably introduced the last TSQ commit, Eric has a patch
> for mvneta in the other thread:
>
> http://article.gmane.org/gmane.linux.network/290359
I had some offline (*) discussions w/ Eric and did some test w/ the patches
he sent. It does not fix the regression I see. It would be nice if someone
w/ the hardware and more knowledge of mvneta driver could reproduce the
issue and spend some time on it.
That been said, even if the driver is most probably not the only one to
blame here (considering the result of bisect and current thread on
netdev), I never managed to get the performance I have on my ReadyNAS
Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
platform (RN102, RN104 or RN2120). Understanding why is on an already a
long todo list.
Cheers,
a+
(*): for some reasons, my messages to netdev and stable are not published
even though I can interact w/ {majordomo,autoanswer}@vger.kernel.org. I
poked postmaster@ bug got no reply yet.
^ permalink raw reply
* Re: WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70()
From: Zhouping Liu @ 2013-11-12 7:45 UTC (permalink / raw)
To: linux-mm, LKML; +Cc: Mel Gorman, netdev
In-Reply-To: <988917896.22733181.1384226183266.JavaMail.root@redhat.com>
CC'ing netdev@ to make more relative people know it.
On 11/12/2013 11:16 AM, Zhouping Liu wrote:
> Hi All,
>
> I found the WARNING in the latest mainline with commint 8b5baa460b.
>
> [61323.305424] ------------[ cut here ]------------
> [61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70()
> [61323.319779] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache sg nfsd netxen_nic hpilo sp5100_tco auth_rpcgss hpwdt amd64_edac_mod edac_mce_amd microcode pcspkr shpchp serio_raw i2c_piix4 edac_core ipmi_si k10temp nfs_acl lockd ipmi_msghandler acpi_power_meter acpi_cpufreq sunrpc xfs libcrc32c radeon i2c_algo_bit drm_kms_helper ttm sd_mod crc_t10dif ata_generic crct10dif_common drm pata_acpi ahci libahci pata_atiixp libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod
> [61323.368625] CPU: 8 PID: 12860 Comm: swapoff Not tainted 3.12.0+ #1
> [61323.375452] Hardware name: HP ProLiant DL585 G7, BIOS A16 12/17/2012
> [61323.382463] 0000000000000009 ffff882dfce43e68 ffffffff816204b7 0000000000000000
> [61323.390692] ffff882dfce43ea0 ffffffff8106495d ffff88190b551d00 ffff88080ff0b600
> [61323.398940] ffff88080ff0b650 0000000000000001 ffff880810fe64a0 ffff882dfce43eb0
> [61323.407188] Call Trace:
> [61323.409916] [] dump_stack+0x45/0x56
> [61323.415616] [] warn_slowpath_common+0x7d/0xa0
> [61323.422257] [] warn_slowpath_null+0x1a/0x20
> [61323.428705] [] sk_clear_memalloc+0x49/0x70
> [61323.435094] [] xs_swapper+0x41/0x60 [sunrpc]
> [61323.441671] [] nfs_swap_deactivate+0x2d/0x30 [nfs]
> [61323.448796] [] destroy_swap_extents+0x61/0x70
> [61323.455436] [] SyS_swapoff+0x220/0x610
> [61323.461420] [] ? do_page_fault+0x1a/0x70
> [61323.467582] [] system_call_fastpath+0x16/0x1b
> [61323.474215] ---[ end trace 919f685513b38356 ]---
>
> I found the warning during doing swapoff the swap over NFS mount, so if you need to reproduce it,
> you should do the following:
> 1. Open CONFIG_NFS_SWAP in testing machine
> 2. Create a NFS server, and create a swap file in NFS server
> in NFS server: # dd if=/dev/zero of=/NFS_FOLDER/swapfile bs=1M count=1024; mkswap swapfile
> 3. Inside testing machine, setup a swap over NFS, then swapoff it, the swapoff action will
> trigger the WARNING.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: TCP performance regression
From: Willy Tarreau @ 2013-11-12 7:42 UTC (permalink / raw)
To: David Laight; +Cc: Eric Dumazet, Sujith Manoharan, netdev, Dave Taht
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73FD@saturn3.aculab.com>
On Mon, Nov 11, 2013 at 04:35:30PM -0000, David Laight wrote:
> > > It should be ok if the mac driver only gives the hardware a small
> > > number of bytes/packets - or one appropriate for the link speed.
> >
> > There is some confusion here.
> >
> > mvneta has a TX ring buffer, which can hold up to 532 TX descriptors.
> >
> > If this driver used skb_orphan(), a single TCP flow could use the whole
> > TX ring.
> >
> > TCP Small Queue would only limit the number of skbs on Qdisc.
> >
> > Try then to send a ping message, it will have to wait a lot.
>
> 532 is a ridiculously large number especially for a slow interface.
> At a guess you don't want more than 10-20ms of data in the tx ring.
Well, it's not *that* large, 532 descriptors is 800 kB or 6.4 ms with
1500-bytes packets, and 273 microseconds for 64-byte packets. In fact
it's not a slow interface, it's the systems it runs on which are
generally not that fast. For example it is possible to saturate two
gig ports at once on a single-core Armada370. But you need buffers
large enough to compensate for the context switch time if you use
multiple threads to send.
Regards,
Willy
^ permalink raw reply
* Re: [PATCH net-next v3 5/10] bonding: create bond_first_slave_rcu()
From: Ding Tianhong @ 2013-11-12 6:55 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131111125917.GX19702@redhat.com>
On 2013/11/11 20:59, Veaceslav Falico wrote:
> On Mon, Nov 11, 2013 at 08:36:41PM +0800, Ding Tianhong wrote:
>> The bond_first_slave_rcu() will be used to instead of bond_first_slave()
>> in rcu_read_lock().
>>
>> So move the struct netdev_adjacent to the netdevice.h and make the
>> bond_first_slave_rcu() could use the struct.
>
> The whole point in netdev_adjacent functions was to hide it from the users
> who wanted to use it directly. See
>
> http://www.spinics.net/lists/netdev/msg248026.html
>
> for reference. Please try to avoid that.
>
Hi, Veaceslav
following the point, I rebuild the bond_first_slave_rcu(),
if you have no comments, I will move it in the patch set.
Regards
Ding
+/* Caller must have rcu_read_lock */
+#define bond_first_slave_rcu(bond) \
+ netdev_lower_get_first_private_rcu(bond->dev)
+
#define bond_is_first_slave(bond, pos) (pos == bond_first_slave(bond))
#define bond_is_last_slave(bond, pos) (pos == bond_last_slave(bond))
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 15fa01c..abfcfad 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2869,6 +2869,7 @@ void *netdev_lower_get_next_private_rcu(struct net_device *dev,
priv = netdev_lower_get_next_private_rcu(dev, &(iter)))
void *netdev_adjacent_get_private(struct list_head *adj_list);
+void *netdev_lower_get_first_private_rcu(struct net_device *dev);
struct net_device *netdev_master_upper_dev_get(struct net_device *dev);
struct net_device *netdev_master_upper_dev_get_rcu(struct net_device *dev);
int netdev_upper_dev_link(struct net_device *dev, struct net_device *upper_dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index 8ffc52e..39bc202 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4570,6 +4570,27 @@ void *netdev_lower_get_next_private_rcu(struct net_device *dev,
EXPORT_SYMBOL(netdev_lower_get_next_private_rcu);
/**
+ * netdev_lower_get_first_private_rcu - Get the first ->private from the
+ * lower neighbour list, RCU
+ * variant
+ * @dev: device
+ *
+ * Gets the first netdev_adjacent->private from the dev's lower neighbour
+ * list. The caller must hold RCU read lock.
+ */
+void *netdev_lower_get_first_private_rcu(struct net_device *dev)
+{
+ struct netdev_adjacent *lower;
+
+ lower = list_first_or_null_rcu(&dev->adj_list.lower,
+ struct netdev_adjacent, list);
+ if (lower)
+ return lower->private;
+ return NULL;
+}
+EXPORT_SYMBOL(netdev_lower_get_first_private_rcu);
^ permalink raw reply related
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Cong Wang @ 2013-11-12 6:48 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: netdev, stable
In-Reply-To: <8761s0cqhh.fsf@natisbad.org>
On Sun, 10 Nov 2013 at 13:53 GMT, Arnaud Ebalard <arno@natisbad.org> wrote:
> Hi,
>
> I decided to upgrade the kernel on one of my ReadyNAS 102 from 3.11.1 to
> 3.11.7. The device is based on Marvell Armada 370 SoC and uses mvneta
> driver. Mine runs Debian armel unstable but I can confirm the issue also
> happens on a debian harmhf unstable.
>
[...]
>
> Then, knowing that, I started a git bisect session on stable tree to end
> up with the following suspects. I failed to go any further to a single
> commit, due to crashes, but I could recompile a kernel w/ debug info and
> report what I get if neeeded.
>
> commit dc0791aee672 tcp: do not forget FIN in tcp_shifted_skb() [bad]
> commit 18ddf5127c9f tcp: must unclone packets before mangling them
> commit 80bd5d8968d8 tcp: TSQ can use a dynamic limit
> commit dbeb18b22197 tcp: TSO packets automatic sizing
> commit 50704410d014 Linux 3.11.6 [good]
>
This regression is probably introduced the last TSQ commit, Eric has a patch
for mvneta in the other thread:
http://article.gmane.org/gmane.linux.network/290359
^ permalink raw reply
* Re: [PATCH net] core/dev: do not ignore dmac in dev_forward_skb()
From: Isaku Yamahata @ 2013-11-12 5:25 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Maciej Żenczykowski, isaku.yamahata, David S. Miller,
Eric Dumazet, Linux NetDev, Nicolas Dichtel, yamahatanetdev
In-Reply-To: <CAMEtUuzmZd0RXO+=YhCW7OwfE1kvc2aA2K0gqXRN+LwS-O1f2w@mail.gmail.com>
On Mon, Nov 11, 2013 at 05:12:10PM -0800,
Alexei Starovoitov <ast@plumgrid.com> wrote:
> On Mon, Nov 11, 2013 at 4:39 PM, Maciej Żenczykowski
> <zenczykowski@gmail.com> wrote:
> > Ack.
> >
> > I'm sure this breaks whatever the original commit was trying to 'fix',
> > however it does so in a clearly incorrect manner by effectively
> > disabling dst mac address filtering.
>
> actually it doesn't break it. Isaku's testcase works for me.
The changeset of 963a88b31ddbbe99f38502239b1a46601773d217
"tunnels: harmonize cleanup done on skb on xmit path"
addresses the issue by calling skb_scrub_packet() when sending skb
through tunnel. So it is safe to revert it.
thanks,
--
Isaku Yamahata <isaku.yamahata@gmail.com>
^ permalink raw reply
* Re: [PATCHv2.1] net: wireless: iwlwifi: remove minor dead code
From: Emmanuel Grumbach @ 2013-11-12 5:24 UTC (permalink / raw)
To: Michal Nazarewicz, Johannes Berg
Cc: Sergei Shtylyov, Emmanuel Grumbach, John W. Linville,
Intel Linux Wireless, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <xa1tr4amwkrt.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
On 11/12/2013 02:01 AM, Michal Nazarewicz wrote:
> inta is checked to be zero in a IRQ_NONE branch so afterwards it
> cannot be zero as it is never modified.
>
> Signed-off-by: Michal Nazarewicz <mina86-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/net/wireless/iwlwifi/pcie/rx.c | 24 +++++++++---------------
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> On Mon, Nov 11 2013, Johannes Berg wrote:
>> no signed-off-by
>
> Sorry, fixed. Interestingly, I did not forget about it in my first patch.
>
no worries - I picked it up in our internal tree.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: manual merge of the random tree with the net-next tree
From: Stephen Rothwell @ 2013-11-12 4:55 UTC (permalink / raw)
To: Theodore Ts'o
Cc: linux-next, linux-kernel, Hannes Frederic Sowa, David Miller,
netdev, Daniel Borkmann
[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]
Hi Ted,
Today's linux-next merge of the random tree got a conflict in
drivers/char/random.c between commit 0244ad004a54 ("random32: add
prandom_reseed_late() and call when nonblocking pool becomes
initialized") from the net-next tree and commit 301f0595c0e7 ("random:
printk notifications for urandom pool initialization") from the random
tree.
I fixed it up (probably not properly - see below) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/char/random.c
index 4fe5609eeb72,cdf4cfb2da4d..000000000000
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@@ -255,8 -255,12 +255,9 @@@
#include <linux/fips.h>
#include <linux/ptrace.h>
#include <linux/kmemcheck.h>
+#include <linux/irq.h>
+ #include <linux/workqueue.h>
-#ifdef CONFIG_GENERIC_HARDIRQS
-# include <linux/irq.h>
-#endif
-
#include <asm/processor.h>
#include <asm/uaccess.h>
#include <asm/irq.h>
@@@ -601,12 -654,14 +651,16 @@@ retry
if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
goto retry;
+ r->entropy_total += nbits;
if (!r->initialized && nbits > 0) {
- r->entropy_total += nbits;
if (r->entropy_total > 128) {
+ if (r == &nonblocking_pool)
+ pr_notice("random: %s pool is initialized\n",
+ r->name);
r->initialized = 1;
+ if (r == &nonblocking_pool)
+ prandom_reseed_late();
+ r->entropy_total = 0;
}
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Fugang Duan @ 2013-11-12 2:54 UTC (permalink / raw)
To: b20596, davem; +Cc: netdev
Enable CONFIG_HAVE_DMA_API_DEBUG, the kernel dump warning:
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:937 check_unmap+0x43c/0x7d8()
fec 2188000.ethernet: DMA-API: device driver failed to check map
error[device address=0x00000000383a8040] [size=2048 bytes] [mapped as single]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.17-16827-g9cdb0ba-dirty #188
[<80013c4c>] (unwind_backtrace+0x0/0xf8) from [<80011704>] (show_stack+0x10/0x14)
[<80011704>] (show_stack+0x10/0x14) from [<80025614>] (warn_slowpath_common+0x4c/0x6c)
[<80025614>] (warn_slowpath_common+0x4c/0x6c) from [<800256c8>] (warn_slowpath_fmt+0x30/0x40)
[<800256c8>] (warn_slowpath_fmt+0x30/0x40) from [<8026bfdc>] (check_unmap+0x43c/0x7d8)
[<8026bfdc>] (check_unmap+0x43c/0x7d8) from [<8026c584>] (debug_dma_unmap_page+0x6c/0x78)
[<8026c584>] (debug_dma_unmap_page+0x6c/0x78) from [<8038049c>] (fec_enet_rx_napi+0x254/0x8a8)
[<8038049c>] (fec_enet_rx_napi+0x254/0x8a8) from [<804dc8c0>] (net_rx_action+0x94/0x160)
[<804dc8c0>] (net_rx_action+0x94/0x160) from [<8002c758>] (__do_softirq+0xe8/0x1d0)
[<8002c758>] (__do_softirq+0xe8/0x1d0) from [<8002c8e8>] (do_softirq+0x4c/0x58)
[<8002c8e8>] (do_softirq+0x4c/0x58) from [<8002cb50>] (irq_exit+0x90/0xc8)
[<8002cb50>] (irq_exit+0x90/0xc8) from [<8000ea88>] (handle_IRQ+0x3c/0x94)
[<8000ea88>] (handle_IRQ+0x3c/0x94) from [<8000855c>] (gic_handle_irq+0x28/0x5c)
[<8000855c>] (gic_handle_irq+0x28/0x5c) from [<8000de00>] (__irq_svc+0x40/0x50)
Exception stack(0x815a5f38 to 0x815a5f80)
5f20: 815a5f80 3b9aca00
5f40: 0fe52383 00000002 0dd8950e 00000002 81e7b080 00000000 00000000 815ac4d8
5f60: 806032ec 00000000 00000017 815a5f80 80059028 8041fc4c 60000013 ffffffff
[<8000de00>] (__irq_svc+0x40/0x50) from [<8041fc4c>] (cpuidle_enter_state+0x50/0xf0)
[<8041fc4c>] (cpuidle_enter_state+0x50/0xf0) from [<8041fd94>] (cpuidle_idle_call+0xa8/0x14c)
[<8041fd94>] (cpuidle_idle_call+0xa8/0x14c) from [<8000edac>] (arch_cpu_idle+0x10/0x4c)
[<8000edac>] (arch_cpu_idle+0x10/0x4c) from [<800582f8>] (cpu_startup_entry+0x60/0x130)
[<800582f8>] (cpu_startup_entry+0x60/0x130) from [<80bc7a48>] (start_kernel+0x2d0/0x328)
[<80bc7a48>] (start_kernel+0x2d0/0x328) from [<10008074>] (0x10008074)
---[ end trace c6edec32436e0042 ]---
Because dma-debug add new interfaces to debug dma mapping errors, pls refer
to: http://lwn.net/Articles/516640/
After dma mapping, it must call dma_mapping_error() to check mapping error,
otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define
the mapping is not checked and dump the error msg.
So, and dma_mapping_error() checking to fix the WARNING.
Signed-off-by: Fugang Duan <B38611@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index b2793b9..d93cb0c 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -386,7 +386,11 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
*/
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, bufaddr,
FEC_ENET_TX_FRSIZE, DMA_TO_DEVICE);
-
+ if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
+ bdp->cbd_bufaddr = 0;
+ netdev_err(ndev, "Tx DMA memory map failed\n");
+ return NETDEV_TX_OK;
+ }
/* Send it on its way. Tell FEC it's ready, interrupt when done,
* it's the last BD of the frame, and to put the CRC on the end.
*/
@@ -1001,6 +1005,9 @@ fec_enet_rx(struct net_device *ndev, int budget)
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, data,
FEC_ENET_TX_FRSIZE, DMA_FROM_DEVICE);
+ /* here dma mapping shouldn't be error, just avoid kernel dump */
+ if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr))
+ netdev_err(ndev, "Rx DMA memory map failed\n");
rx_processing_done:
/* Clear the status flags for this buffer */
status &= ~BD_ENET_RX_STATS;
@@ -1719,6 +1726,11 @@ static int fec_enet_alloc_buffers(struct net_device *ndev)
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, skb->data,
FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
+ fec_enet_free_buffers(ndev);
+ netdev_err(ndev, "Rx DMA memory map failed\n");
+ return -ENOMEM;
+ }
bdp->cbd_sc = BD_ENET_RX_EMPTY;
if (fep->bufdesc_ex) {
--
1.7.2.rc3
^ permalink raw reply related
* Re: [patch iproute2] ipaddress: add a black line for each device to make the output more readable
From: Hangbin Liu @ 2013-11-12 2:09 UTC (permalink / raw)
To: Jiri Benc; +Cc: network dev
In-Reply-To: <20131111173100.108e9026@griffin>
On Mon, Nov 11, 2013 at 05:31:00PM +0100, Jiri Benc wrote:
> On Mon, 11 Nov 2013 23:03:30 +0800, Hangbin Liu wrote:
> > When we have multi links, the output huddled together and make it hard to read.
> > Let's use the old ifconfig output style.
>
> No. You can't break others' scripts like that.
Hi Jiri,
Thanks for you reminding.
Although I think a blank line won't have much influence for most of strong
scripts, it MAY break some. But the output will be more readable. I think that
worth it.
>
> bash$ function ip { /sbin/ip "$@" | sed '2,$s/^[0-9]*:/\n&/' ; }
Yes, this function works great. But for administrators who have lots of systems
and NICs, it's hard to add the function/alias on each system. And the output
of ifconfig, which is still used by lots of admins, looks clearly. So why
don't we also use it?
--
Thanks & Best Regards
Hangbin Liu <liuhangbin@gmail.com>
^ permalink raw reply
* [PATCH] ath6kl: sdio: fix system panic when doing wifi stress test
From: Jason Liu @ 2013-11-12 1:53 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: netdev, kvalo, linux-wireless, linville, linux-kernel
When did the wifi iperf test, meet one following kernel panic:
command: iperf -c $TARGET_IP -i 5 -t 50 -w 1M
Unable to handle kernel paging request at virtual address 1a480000
pgd = 80004000
[1a480000] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core]
CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1
Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio]
task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000
PC is at v7_dma_clean_range+0x20/0x38
LR is at dma_cache_maint_page+0x50/0x54
pc : [<8001a6f8>] lr : [<800170fc>] psr: 20000093
sp : dc9afcf8 ip : 8001a748 fp : 00000004
r10: 00000000 r9 : 00000001 r8 : 00000000
r7 : 00000001 r6 : 00000000 r5 : 80cb7000 r4 : 03f9a480
r3 : 0000001f r2 : 00000020 r1 : 1a480000 r0 : 1a480000
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 6cc5004a DAC: 00000015
Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238)
Stack: (0xdc9afcf8 to 0xdc9b0000)
fce0: 80c9b29c 00000000
fd00: 00000000 80017134 8001a748 dc302ac0 00000000 00000000 dc454a00 80c12ed8
fd20: dc115410 80017238 00000000 dc454a10 00000001 80017588 00000001 00000000
fd40: 00000000 dc302ac0 dc9afe38 dc9afe68 00000004 80c12ed8 00000000 dc454a00
fd60: 00000004 80436f88 00000000 00000000 00000600 0000ffff 0000000c 80c113c4
fd80: 80c9b29c 00000001 00000004 dc115470 60000013 dc302ac0 dc46e000 dc302800
fda0: dc9afe10 dc302b78 60000013 dc302ac0 dc46e000 00000035 dc46e5b0 80438c90
fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 00000005 dc9afe10
fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00
fe00: 000001b5 7f619d64 dcc7c830 00000000 00000000 dc9afe38 dc9afe68 00000000
fe20: 00000000 00000000 dc9afe28 dc9afe28 80424d80 00000000 00000035 9cac0034
fe40: 00000000 00000000 00000000 00000000 000001b5 00000000 00000000 00000000
fe60: dc9afe68 dc9afe10 3b9aca00 00000000 00000080 00000034 00000000 00000100
fe80: 00000000 00000000 dc9afe10 00000004 dc454a00 00000000 dc46e010 dc46e96c
fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 00000600 80c0e770
fec0: dc15a900 dcc7c838 00000000 dc46e954 8042d434 dcc44680 dc46e954 dc004400
fee0: dc454500 00000000 00000000 dc9ae038 dc004400 8003c450 dcc44680 dc004414
ff00: dc46e954 dc454500 00000001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030
ff20: 00000001 dc9ae000 dc004400 8003d158 8003d020 00000000 00000000 80c53941
ff40: dc9aff64 dcb71ea0 00000000 dcc44680 8003d020 00000000 00000000 00000000
ff60: 00000000 80042480 00000000 00000000 000000f8 dcc44680 00000000 00000000
ff80: dc9aff80 dc9aff80 00000000 00000000 dc9aff90 dc9aff90 dc9affac dcb71ea0
ffa0: 800423cc 00000000 00000000 8000e018 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] (dma_cache_maint_page+0x50/0x54)
[<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c)
[<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] (arm_dma_map_page+0x64/0x68)
[<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] (arm_dma_map_sg+0x7c/0xf4)
[<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] (sdhci_send_command+0x894/0xe00)
[<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] (sdhci_request+0xc0/0x1ec)
[<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] (mmc_start_request+0xb8/0xd4)
[<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] (__mmc_start_req+0x60/0x84)
[<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] (mmc_wait_for_req+0x10/0x20)
[<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio])
[<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio])
[<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from [<8003c450>] (process_one_work+0x10c/0x370)
[<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] (worker_thread+0x138/0x3fc)
[<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] (kthread+0xb4/0xb8)
[<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c)
Code: e1a02312 e2423001 e1c00003 f57ff04f (ee070f3a)
---[ end trace 0c038f0b8e0b67a3 ]---
Kernel panic - not syncing: Fatal exception
The kernel panic is caused by the sg_buf is not set correctly with the
following code when compiled with Yocto GCC 4.8.1:
drivers/net/wireless/ath/ath6kl/hif.h:
struct hif_scatter_req {
struct list_head list;
/* address for the read/write operation */
u32 addr;
...
/* bounce buffer for upper layers to copy to/from */
u8 *virt_dma_buf;
struct hif_scatter_item scat_list[1];
u32 scat_q_depth;
};
(Note: the scat_req.scat_list[] will dynamiclly grow with run-time)
drivers/net/wireless/ath/ath6kl/sdio.c: ath6kl_sdio_setup_scat_data(...)
/* assemble SG list */
for (i = 0; i < scat_req->scat_entries; i++, sg++) {
ath6kl_dbg(ATH6KL_DBG_SCATTER, "%d: addr:0x%p, len:%d\n",
i, scat_req->scat_list[i].buf,
scat_req->scat_list[i].len);
sg_set_buf(sg, scat_req->scat_list[i].buf,
scat_req->scat_list[i].len);
}
The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead,
it only run one round loop. This may be caused by that the GCC 4.8.1 thought
that the scat_list only have one item and then no need to do full iteration,
but this is simply wrong by looking at the assebly code. This will cause the
sg buffer not get set when scat_entries > 1 and thus lead to kernel panic.
This patch is a workaround to the GCC 4.8.1 complier issue by passing the
entry address of the scat_req->scat_list to the for-loop and interate it,
then, GCC 4.8.1 will do the full for-loop correctly.
(Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)
This patch does not change any function logic and no any performance downgrade.
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jason Liu <r64343@freescale.com>
---
drivers/net/wireless/ath/ath6kl/sdio.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index 7126bdd..c31df7e 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -222,6 +222,7 @@ static void ath6kl_sdio_setup_scat_data(struct hif_scatter_req *scat_req,
struct mmc_data *data)
{
struct scatterlist *sg;
+ struct hif_scatter_item *scat_list;
int i;
data->blksz = HIF_MBOX_BLOCK_SIZE;
@@ -240,14 +241,14 @@ static void ath6kl_sdio_setup_scat_data(struct hif_scatter_req *scat_req,
sg = scat_req->sgentries;
sg_init_table(sg, scat_req->scat_entries);
+ scat_list = &scat_req->scat_list[0];
+
/* assemble SG list */
- for (i = 0; i < scat_req->scat_entries; i++, sg++) {
+ for (i = 0; i < scat_req->scat_entries; i++, sg++, scat_list++) {
ath6kl_dbg(ATH6KL_DBG_SCATTER, "%d: addr:0x%p, len:%d\n",
- i, scat_req->scat_list[i].buf,
- scat_req->scat_list[i].len);
+ i, scat_list->buf, scat_list->len);
- sg_set_buf(sg, scat_req->scat_list[i].buf,
- scat_req->scat_list[i].len);
+ sg_set_buf(sg, scat_list->buf, scat_list->len);
}
/* set scatter-gather table for request */
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCHv2 3/4] of: provide a binding for fixed link PHYs
From: Florian Fainelli @ 2013-11-12 1:43 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: David S. Miller, netdev, devicetree@vger.kernel.org, Lior Amsalem,
Gregory Clement, Ezequiel Garcia,
linux-arm-kernel@lists.infradead.org, Mark Rutland, Sascha Hauer,
Christian Gmeiner
In-Reply-To: <1378480701-12908-4-git-send-email-thomas.petazzoni@free-electrons.com>
Hello Thomas,
2013/9/6 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> +Some Ethernet MACs have a "fixed link", and are not connected to a
> +normal MDIO-managed PHY device. For those situations, a Device Tree
> +binding allows to describe a "fixed link".
> +
> +Such a fixed link situation is described by creating a PHY node as a
> +sub-node of an Ethernet device, with the following properties:
> +
> +* 'fixed-link' (boolean, mandatory), to indicate that this PHY is a
> + fixed link PHY.
> +* 'speed' (integer, mandatory), to indicate the link speed. Accepted
> + values are 10, 100 and 1000
'max-speed' might be better here to match ePAPR v1.1 (if we do care,
'speed') works for me too.
> +* 'full-duplex' (boolean, optional), to indicate that full duplex is
> + used. When absent, half duplex is assumed.
> +* 'pause' (boolean, optional), to indicate that pause should be
> + enabled.
> +* 'asym-pause' (boolean, optional), to indicate that asym_pause should
> + be enabled.
We also need to add a property: 'connection-type' which can be any of
'mii', 'rgmii' etc... When operating Ethernet devices with Ethernet
devices connected back to back, it might be required to configure the
Ethernet MAC with an appropriate connection type.
Note that I picked 'connection-type' here because this the ePAPR v1.1
terminology. Now the good thing is that it is a new "feature" wrt. the
old binding.
^ permalink raw reply
* [Fwd: Re: [PATCH v2 2/2] x86: add prefetching to do_csum]
From: Joe Perches @ 2013-11-12 1:42 UTC (permalink / raw)
To: netdev, Neil Horman
Cc: Dave Jones, linux-kernel, sebastien.dugue, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86, Eric Dumazet
Hi again Neil.
Forwarding on to netdev with a concern as to how often
do_csum is used via csum_partial for very short headers
and what impact any prefetch would have there.
Also, what changed in your test environment?
Why are the new values 5+% higher cycles/byte than the
previous values?
And here is the new table reformatted:
len set iterations Readahead cachelines vs cycles/byte
1 2 3 4 6 10 20
1500B 64MB 1000000 1.4342 1.4300 1.4350 1.4350 1.4396 1.4315 1.4555
1500B 128MB 1000000 1.4312 1.4346 1.4271 1.4284 1.4376 1.4318 1.4431
1500B 256MB 1000000 1.4309 1.4254 1.4316 1.4308 1.4418 1.4304 1.4367
1500B 512MB 1000000 1.4534 1.4516 1.4523 1.4563 1.4554 1.4644 1.4590
9000B 64MB 1000000 0.8921 0.8924 0.8932 0.8949 0.8952 0.8939 0.8985
9000B 128MB 1000000 0.8841 0.8856 0.8845 0.8854 0.8861 0.8879 0.8861
9000B 256MB 1000000 0.8806 0.8821 0.8813 0.8833 0.8814 0.8827 0.8895
9000B 512MB 1000000 0.8838 0.8852 0.8841 0.8865 0.8846 0.8901 0.8865
64KB 64MB 1000000 0.8132 0.8136 0.8132 0.8150 0.8147 0.8149 0.8147
64KB 128MB 1000000 0.8013 0.8014 0.8013 0.8020 0.8041 0.8015 0.8033
64KB 256MB 1000000 0.7956 0.7959 0.7956 0.7976 0.7981 0.7967 0.7973
64KB 512MB 1000000 0.7934 0.7932 0.7937 0.7951 0.7954 0.7943 0.7948
-------- Forwarded Message --------
From: Neil Horman <nhorman@tuxdriver.com>
To: Joe Perches <joe@perches.com>
Cc: Dave Jones <davej@redhat.com>, linux-kernel@vger.kernel.org,
sebastien.dugue@bull.net, Thomas Gleixner <tglx@linutronix.de>, Ingo
Molnar <mingo@redhat.com>, H. Peter Anvin <hpa@zytor.com>,
x86@kernel.org
Subject: Re: [PATCH v2 2/2] x86: add prefetching to do_csum
On Fri, Nov 08, 2013 at 12:29:07PM -0800, Joe Perches wrote:
> On Fri, 2013-11-08 at 15:14 -0500, Neil Horman wrote:
> > On Fri, Nov 08, 2013 at 11:33:13AM -0800, Joe Perches wrote:
> > > On Fri, 2013-11-08 at 14:01 -0500, Neil Horman wrote:
> > > > On Wed, Nov 06, 2013 at 09:19:23AM -0800, Joe Perches wrote:
> > > > > On Wed, 2013-11-06 at 10:54 -0500, Neil Horman wrote:
> > > > > > On Wed, Nov 06, 2013 at 10:34:29AM -0500, Dave Jones wrote:
> > > > > > > On Wed, Nov 06, 2013 at 10:23:19AM -0500, Neil Horman wrote:
> > > > > > > > do_csum was identified via perf recently as a hot spot when doing
> > > > > > > > receive on ip over infiniband workloads. After alot of testing and
> > > > > > > > ideas, we found the best optimization available to us currently is to
> > > > > > > > prefetch the entire data buffer prior to doing the checksum
> > > > > []
> > > > > > I'll fix this up and send a v3, but I'll give it a day in case there are more
> > > > > > comments first.
> > > > >
> > > > > Perhaps a reduction in prefetch loop count helps.
> > > > >
> > > > > Was capping the amount prefetched and letting the
> > > > > hardware prefetch also tested?
> > > > >
> > > > > prefetch_lines(buff, min(len, cache_line_size() * 8u));
> > > > >
> > > >
> > > > Just tested this out:
> > >
> > > Thanks.
> > >
> > > Reformatting the table so it's a bit more
> > > readable/comparable for me:
> > >
> > > len SetSz Loops cycles/byte
> > > limited unlimited
> > > 1500B 64MB 1M 1.3442 1.3605
> > > 1500B 128MB 1M 1.3410 1.3542
> > > 1500B 256MB 1M 1.3536 1.3710
> > > 1500B 512MB 1M 1.3463 1.3536
> > > 9000B 64MB 1M 0.8522 0.8504
> > > 9000B 128MB 1M 0.8528 0.8536
> > > 9000B 256MB 1M 0.8532 0.8520
> > > 9000B 512MB 1M 0.8527 0.8525
> > > 64KB 64MB 1M 0.7686 0.7683
> > > 64KB 128MB 1M 0.7695 0.7686
> > > 64KB 256MB 1M 0.7699 0.7708
> > > 64KB 512MB 1M 0.7799 0.7694
> > >
> > > This data appears to show some value
> > > in capping for 1500b lengths and noise
> > > for shorter and longer lengths.
> > >
> > > Any idea what the actual distribution of
> > > do_csum lengths is under various loads?
> > >
> > I don't have any hard data no, sorry.
>
> I think you should before you implement this.
> You might find extremely short lengths.
>
> > I'll cap the prefetch at 1500B for now, since it
> > doesn't seem to hurt or help beyond that
>
> The table data has a max prefetch of
> 8 * boot_cpu_data.x86_cache_alignment so
> I believe it's always less than 1500 but
> perhaps 4 might be slightly better still.
>
So, you appear to be correct, I reran my test set with different prefetch
ceilings and got the results below. There are some cases in which there is a
performance gain, but the gain is small, and occurs at different spots depending
on the input buffer size (though most peak gains appear around 2 cache lines).
I'm guessing it takes about 2 prefetches before hardware prefetching catches up,
at which point we're just spending time issuing instructions that get discarded.
Given the small prefetch limit, and the limited gains (which may also change on
different hardware), I think we should probably just drop the prefetch idea
entirely, and perhaps just take the perf patch so that we can revisit this area
when hardware that supports the avx extensions and/or adcx/adox becomes
available.
Ingo, does that seem reasonable to you?
Neil
1 cache line:
len | set | iterations | cycles/byte
========|=======|===============|=============
1500B | 64MB | 1000000 | 1.434190
1500B | 128MB | 1000000 | 1.431216
1500B | 256MB | 1000000 | 1.430888
1500B | 512MB | 1000000 | 1.453422
9000B | 64MB | 1000000 | 0.892055
9000B | 128MB | 1000000 | 0.884050
9000B | 256MB | 1000000 | 0.880551
9000B | 512MB | 1000000 | 0.883848
64KB | 64MB | 1000000 | 0.813187
64KB | 128MB | 1000000 | 0.801326
64KB | 256MB | 1000000 | 0.795643
64KB | 512MB | 1000000 | 0.793400
2 cache lines:
len | set | iterations | cycles/byte
========|=======|===============|=============
1500B | 64MB | 1000000 | 1.430030
1500B | 128MB | 1000000 | 1.434589
1500B | 256MB | 1000000 | 1.425430
1500B | 512MB | 1000000 | 1.451570
9000B | 64MB | 1000000 | 0.892369
9000B | 128MB | 1000000 | 0.885577
9000B | 256MB | 1000000 | 0.882091
9000B | 512MB | 1000000 | 0.885201
64KB | 64MB | 1000000 | 0.813629
64KB | 128MB | 1000000 | 0.801377
64KB | 256MB | 1000000 | 0.795861
64KB | 512MB | 1000000 | 0.793242
3 cache lines:
len | set | iterations | cycles/byte
========|=======|===============|=============
1500B | 64MB | 1000000 | 1.435048
1500B | 128MB | 1000000 | 1.427103
1500B | 256MB | 1000000 | 1.431558
1500B | 512MB | 1000000 | 1.452250
9000B | 64MB | 1000000 | 0.893162
9000B | 128MB | 1000000 | 0.884488
9000B | 256MB | 1000000 | 0.881314
9000B | 512MB | 1000000 | 0.884060
64KB | 64MB | 1000000 | 0.813185
64KB | 128MB | 1000000 | 0.801280
64KB | 256MB | 1000000 | 0.795554
64KB | 512MB | 1000000 | 0.793670
4 cache lines:
len | set | iterations | cycles/byte
========|=======|===============|=============
1500B | 64MB | 1000000 | 1.435013
1500B | 128MB | 1000000 | 1.428434
1500B | 256MB | 1000000 | 1.430780
1500B | 512MB | 1000000 | 1.456285
9000B | 64MB | 1000000 | 0.894877
9000B | 128MB | 1000000 | 0.885387
9000B | 256MB | 1000000 | 0.883293
9000B | 512MB | 1000000 | 0.886462
64KB | 64MB | 1000000 | 0.815036
64KB | 128MB | 1000000 | 0.801962
64KB | 256MB | 1000000 | 0.797618
64KB | 512MB | 1000000 | 0.795138
6 cache lines:
len | set | iterations | cycles/byte
========|=======|===============|=============
1500B | 64MB | 1000000 | 1.439609
1500B | 128MB | 1000000 | 1.437569
1500B | 256MB | 1000000 | 1.441776
1500B | 512MB | 1000000 | 1.455362
9000B | 64MB | 1000000 | 0.895242
9000B | 128MB | 1000000 | 0.886149
9000B | 256MB | 1000000 | 0.881375
9000B | 512MB | 1000000 | 0.884610
64KB | 64MB | 1000000 | 0.814658
64KB | 128MB | 1000000 | 0.804124
64KB | 256MB | 1000000 | 0.798143
64KB | 512MB | 1000000 | 0.795377
10 cache lines:
len | set | iterations | cycles/byte
========|=======|===============|=============
1500B | 64MB | 1000000 | 1.431512
1500B | 128MB | 1000000 | 1.431805
1500B | 256MB | 1000000 | 1.430388
1500B | 512MB | 1000000 | 1.464370
9000B | 64MB | 1000000 | 0.893922
9000B | 128MB | 1000000 | 0.887852
9000B | 256MB | 1000000 | 0.882711
9000B | 512MB | 1000000 | 0.890067
64KB | 64MB | 1000000 | 0.814890
64KB | 128MB | 1000000 | 0.801470
64KB | 256MB | 1000000 | 0.796658
64KB | 512MB | 1000000 | 0.794266
20 cache lines:
len | set | iterations | cycles/byte
========|=======|===============|=============
1500B | 64MB | 1000000 | 1.455539
1500B | 128MB | 1000000 | 1.443117
1500B | 256MB | 1000000 | 1.436739
1500B | 512MB | 1000000 | 1.458973
9000B | 64MB | 1000000 | 0.898470
9000B | 128MB | 1000000 | 0.886110
9000B | 256MB | 1000000 | 0.889549
9000B | 512MB | 1000000 | 0.886547
64KB | 64MB | 1000000 | 0.814665
64KB | 128MB | 1000000 | 0.803252
64KB | 256MB | 1000000 | 0.797268
64KB | 512MB | 1000000 | 0.794830
^ permalink raw reply
* Re: [PATCH net] core/dev: do not ignore dmac in dev_forward_skb()
From: Alexei Starovoitov @ 2013-11-12 1:12 UTC (permalink / raw)
To: Maciej Żenczykowski, isaku.yamahata
Cc: David S. Miller, Eric Dumazet, Linux NetDev, Nicolas Dichtel
In-Reply-To: <CAHo-Ooz8aqwOH6HBbBK3AD2=odCQtDyuV8+GdA4SqOWEwX6WTA@mail.gmail.com>
On Mon, Nov 11, 2013 at 4:39 PM, Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
> Ack.
>
> I'm sure this breaks whatever the original commit was trying to 'fix',
> however it does so in a clearly incorrect manner by effectively
> disabling dst mac address filtering.
actually it doesn't break it. Isaku's testcase works for me.
^ permalink raw reply
* Re: [PATCH net] core/dev: do not ignore dmac in dev_forward_skb()
From: Maciej Żenczykowski @ 2013-11-12 0:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Eric Dumazet, Linux NetDev, Nicolas Dichtel
In-Reply-To: <1384206735-4226-1-git-send-email-ast@plumgrid.com>
Ack.
I'm sure this breaks whatever the original commit was trying to 'fix',
however it does so in a clearly incorrect manner by effectively
disabling dst mac address filtering.
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Karl Beldan @ 2013-11-12 0:37 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Theodore Ts'o, Daniel Borkmann, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
fweimer-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet, linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131112000307.GB14929-5j1vdhnGyZutBveJljeh2VPnkB77EeZ12LY78lusg7I@public.gmane.org>
On Tue, Nov 12, 2013 at 01:03:07AM +0100, Hannes Frederic Sowa wrote:
> On Mon, Nov 11, 2013 at 08:43:57AM -0500, Theodore Ts'o wrote:
> > On Mon, Nov 11, 2013 at 12:20:34PM +0100, Daniel Borkmann wrote:
> > > From: Hannes Frederic Sowa <hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
> > >
> > > The Tausworthe PRNG is initialized at late_initcall time. At that time the
> > > entropy pool serving get_random_bytes is not filled sufficiently. This
> > > patch adds an additional reseeding step as soon as the nonblocking pool
> > > gets marked as initialized.
> > >
> > > On some machines it might be possible that late_initcall gets called after
> > > the pool has been initialized. In this situation we won't reseed again.
> > >
> > > (A call to prandom_seed_late blocks later invocations of early reseed
> > > attempts.)
> > >
> > > Joint work with Daniel Borkmann.
> >
> > Acked-by: "Theodore Ts'o" <tytso-3s7WtUTddSA@public.gmane.org>
> >
> > I wasn't cc'ed on the full series (I didn't see the 0/3 or the 4/6
> > messages) but there are two other things that you might want to
> > consider.
> >
> > 1) I'm pretty sure, but it would be good to get netdev confirmation,
> > that the call to get_random_bytes() in
> > net/mac80211/rc80211_minstrel.c's init_sample_table() can be replaced
> > by calls to prandom_u32().
>
> Would make sense. I added wireless-devel to confirm.
>
> [...]
> [ 0.673260] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> [ 0.674024] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> [ 0.675012] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> [ 0.676032] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> [ 0.677020] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> [ 0.678011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> [ 0.679011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> [...]
>
> In total 80 calls to get_random_bytes.
>
It is already 8 times what rc80211_minstrel_ht_init uses.
If you could apply on top of:
http://marc.info/?l=linux-wireless&m=138392850030987&w=2
although Johannes has not yet agreed/applied this.
Karl
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: iproute2: potential upgrade regression with 58a3e827
From: Dilip Daya @ 2013-11-12 0:36 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Chris J Arges, Brian Haley, shemminger, netdev@vger.kernel.org
In-Reply-To: <871u2mblzk.fsf@xmission.com>
Hi Eric,
On Mon, 2013-11-11 at 14:40 -0800, Eric W. Biederman wrote:
> Dilip Daya <dilip.daya@hp.com> writes:
>
> > Hi Chris,
> >
> > On Mon, 2013-11-11 at 15:26 -0600, Chris J Arges wrote:
> >
> >> Good suggestion,
> >> So I'll use a more simple example now:
> >>
> >> 1)
> >> ip netns add first
> >> ip netns exec first bash
> >>
> >> 2)
> >> ip netns add second
> >> ip netns exec second bash
> >>
> >> 3)
> >> ip netns exec first bash
> >>
> >> If we do not upgrade the package, after we execute (2) we have:
> >> # ls -l /var/run/netns
> >> total 0
> >> -r-------- 1 root root 0 Nov 11 20:38 first
> >> -r-------- 1 root root 0 Nov 11 20:38 second
> >>
> >> If we upgrade after (1), then run (2) we have:
> >> # ls -l /var/run/netns
> >> total 0
> >> ---------- 1 root root 0 Nov 11 20:56 first
> >> -r-------- 1 root root 0 Nov 11 20:57 second
> >>
> >> So looks like netns add is doing something different from 58a3e827 and on.
>
> I will just add that it is worth looking at /proc/mounts as well.
>
> Although I have to admit that the difference in permissions is odd.
=> kernel v3.2.51 with iproute2-ss130903
Terminal #1--Add first netns
# ip netns add first
Terminal #1:
# tree --inodes /var/run/netns ; echo "=====" ; ls -li /var/run/netns ; echo "====="; cat /proc/self/mounts | grep first ; echo "=====" ; cat /proc/self/mountinfo | grep -e first
/var/run/netns
└── [ 5204] first
0 directories, 1 file
=====
total 0
5204 -r-------- 1 root root 0 Nov 11 17:17 first
=====
none /var/run/netns/first proc rw,nosuid,nodev,noexec,relatime 0 0
=====
23 22 0:3 /1935/ns/net /var/run/netns/first rw,nosuid,nodev,noexec,relatime shared:2 - proc none rw
Terminal #1:
# ip netns exec first /bin/bash
Terminal #1:
# tree --inodes /var/run/netns ; echo "=====" ; ls -li /var/run/netns ; echo "====="; cat /proc/self/mounts | grep first ; echo "=====" ; cat /proc/self/mountinfo | grep -e first
/var/run/netns
└── [ 5204] first
0 directories, 1 file
=====
total 0
5204 -r-------- 1 root root 0 Nov 11 17:17 first
=====
none /var/run/netns/first proc rw,nosuid,nodev,noexec,relatime 0 0
first /sys sysfs rw,relatime 0 0
=====
33 32 0:3 /1935/ns/net /var/run/netns/first rw,nosuid,nodev,noexec,relatime master:2 - proc none rw
29 25 0:17 / /sys rw,relatime - sysfs first rw
Terminal #1:
# ip netns add second
Terminal #1:
# tree --inodes /var/run/netns ; echo "=====" ; ls -li /var/run/netns ; echo "====="; cat /proc/self/mounts | grep first ; echo "=====" ; cat /proc/self/mountinfo | grep -e first -e second
/var/run/netns
├── [ 5204] first
└── [ 5236] second
0 directories, 2 files
=====
total 0
5204 -r-------- 1 root root 0 Nov 11 17:17 first
5236 -r-------- 1 root root 0 Nov 11 17:21 second <<< observe this inode # and permissions
=====
none /var/run/netns/first proc rw,nosuid,nodev,noexec,relatime 0 0
first /sys sysfs rw,relatime 0 0
=====
33 32 0:3 /1935/ns/net /var/run/netns/first rw,nosuid,nodev,noexec,relatime shared:4 master:2 - proc none rw
29 25 0:17 / /sys rw,relatime - sysfs first rw
34 32 0:3 /1955/ns/net /var/run/netns/second rw,nosuid,nodev,noexec,relatime shared:5 - proc none rw
Terminal #2--in main (not in netns):
# tree --inodes /var/run/netns ; echo "=====" ; ls -li /var/run/netns ; echo "====="; cat /proc/self/mounts | grep first ; echo "=====" ; cat /proc/self/mountinfo | grep -e first -e second
/var/run/netns
├── [ 5204] first
└── [ 51492] second <<< inode is different
0 directories, 2 files
=====
total 0
5204 -r-------- 1 root root 0 Nov 11 17:17 first
51492 ---------- 1 root root 0 Nov 11 17:21 second << inode different with NULL permissions
=====
none /var/run/netns/first proc rw,nosuid,nodev,noexec,relatime 0 0
=====
23 22 0:3 /1935/ns/net /var/run/netns/first rw,nosuid,nodev,noexec,relatime shared:2 - proc none rw
=> When in main (not in netns) "second" netns is not viewable.
Terminal #2--Enter first:
# ip netns exec first bash
Terminal #2:
# tree --inodes /var/run/netns ; echo "=====" ; ls -li /var/run/netns ; echo "====="; cat /proc/self/mounts | grep first ; echo "=====" ; cat /proc/self/mountinfo | grep -e first -e second
/var/run/netns
├── [ 5204] first
└── [ 51492] second <<< inode different then when created from first in Terminal #1 above
0 directories, 2 files
=====
total 0
5204 -r-------- 1 root root 0 Nov 11 17:17 first
51492 ---------- 1 root root 0 Nov 11 17:21 second <<< inode with NULL permissions
=====
none /var/run/netns/first proc rw,nosuid,nodev,noexec,relatime 0 0
first /sys sysfs rw,relatime 0 0
=====
44 43 0:3 /1935/ns/net /var/run/netns/first rw,nosuid,nodev,noexec,relatime master:2 - proc none rw
40 36 0:17 / /sys rw,relatime - sysfs first rw
=> mounts and mountinfo does not show "second"
Terminal #2:
# ip netns exec second /bin/bash
seting the network namespace "second" failed: Invalid argument
=> "second" netns is now rendered unusable from "first" netns and from main.
Thanks,
-DilipD.
>
> Eric
--
-DilipD.
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Hannes Frederic Sowa @ 2013-11-12 0:03 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Daniel Borkmann, davem, shemminger, fweimer, netdev, Eric Dumazet,
linux-wireless
In-Reply-To: <20131111134357.GC10104@thunk.org>
On Mon, Nov 11, 2013 at 08:43:57AM -0500, Theodore Ts'o wrote:
> On Mon, Nov 11, 2013 at 12:20:34PM +0100, Daniel Borkmann wrote:
> > From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> >
> > The Tausworthe PRNG is initialized at late_initcall time. At that time the
> > entropy pool serving get_random_bytes is not filled sufficiently. This
> > patch adds an additional reseeding step as soon as the nonblocking pool
> > gets marked as initialized.
> >
> > On some machines it might be possible that late_initcall gets called after
> > the pool has been initialized. In this situation we won't reseed again.
> >
> > (A call to prandom_seed_late blocks later invocations of early reseed
> > attempts.)
> >
> > Joint work with Daniel Borkmann.
>
> Acked-by: "Theodore Ts'o" <tytso@mit.edu>
>
> I wasn't cc'ed on the full series (I didn't see the 0/3 or the 4/6
> messages) but there are two other things that you might want to
> consider.
>
> 1) I'm pretty sure, but it would be good to get netdev confirmation,
> that the call to get_random_bytes() in
> net/mac80211/rc80211_minstrel.c's init_sample_table() can be replaced
> by calls to prandom_u32().
Would make sense. I added wireless-devel to confirm.
[...]
[ 0.673260] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
[ 0.674024] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
[ 0.675012] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
[ 0.676032] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
[ 0.677020] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
[ 0.678011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
[ 0.679011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
[...]
In total 80 calls to get_random_bytes.
Normally this initialization is called at module load time, so with most
distributions it runs much later. I had it built-in.
> That is, I don't believe cryptographic strength randomness is needed
> --- which is good, because my debugging indicates on a test system
> indicates that it gets called so early that there is typically less
> than two dozen bits of entropy collected in the non-blocking pool
> before it calls get_random_bytes(). If we can move away from using
> get_random_bytes(), those two dozen bits of entropy can be used to
> make sure the urandom pool is initialized much more quickly.
>
> 2) Since the minstrel code apparently uses this information for
> initializing a machine learning algorithm for backoff purposes, I
> suspect it might be good if the numbers it gets are different from
> machine to machine --- and right now prandom_init() does not mix in
> any kind of personalization information, so calls to prandom_u32()
> will be the same across machines until it gets initialized from the
> /dev/random subsysem.
Yes, I agree.
We are much too early to enumerate hardware, so it would be hard to
integrate something like mac addresses etc.
On x86 it would be easy to seed the cpu type and model from a cpuid call,
but I fear we could not easily extend it to all architectures. And it
does not differ that much between systems.
> Currently, the way we get personlization information which uniquifies
> the randomness in early boot is via add_device_randomness(). Yes,
> some of the function names are a bit misleading; maybe we should try
> to fix this at some point. So perhaps we should add a hook to
> add_device_randomness() so that each time it gets called, if the
> random32.c state hasn't been strongly initialized by the call to
> prandom_reseed_late(), we also use that information add some per-host
> uniqueness into prandom32.c. (Note: I'd prefer that we do this via
> some interface other than get_random_bytes(), so we don't end up
> draining entropy from the non_blocking pool, and thus delay the point
> where we can strongly initialize the non_blocking pool, and thus
> strongly initialize prandom32.c)
>
> Does this make sense to folks?
Totally! That was also the reason why I left the late_initcall intact
in this patch.
Btw. do you see problems regarding get_random_int on architectures without
hardware offloading?
We are initializing random_int_secret really late (after all the init
calls) and I wonder if we should also use a two stage initialization
there, so we have a more unpredictable MD5 hash at early boot.
Greetings,
Hannes
^ permalink raw reply
* [PATCHv2.1] net: wireless: iwlwifi: remove minor dead code
From: Michal Nazarewicz @ 2013-11-12 0:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergei Shtylyov, Emmanuel Grumbach, John W. Linville,
Intel Linux Wireless, linux-wireless, netdev, linux-kernel
In-Reply-To: <1384177312.14334.12.camel@jlt4.sipsolutions.net>
inta is checked to be zero in a IRQ_NONE branch so afterwards it
cannot be zero as it is never modified.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
drivers/net/wireless/iwlwifi/pcie/rx.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
On Mon, Nov 11 2013, Johannes Berg wrote:
> no signed-off-by
Sorry, fixed. Interestingly, I did not forget about it in my first patch.
diff --git a/drivers/net/wireless/iwlwifi/pcie/rx.c b/drivers/net/wireless/iwlwifi/pcie/rx.c
index 3f237b4..7d0fdc0 100644
--- a/drivers/net/wireless/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/rx.c
@@ -1121,7 +1121,6 @@ static irqreturn_t iwl_pcie_isr(int irq, void *data)
struct iwl_trans *trans = data;
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
u32 inta, inta_mask;
- irqreturn_t ret = IRQ_NONE;
lockdep_assert_held(&trans_pcie->irq_lock);
@@ -1150,7 +1149,14 @@ static irqreturn_t iwl_pcie_isr(int irq, void *data)
* or due to sporadic interrupts thrown from our NIC. */
if (!inta) {
IWL_DEBUG_ISR(trans, "Ignore interrupt, inta == 0\n");
- goto none;
+ /* re-enable interrupts here since we don't have anything to
+ * service. only Re-enable if disabled by irq and no
+ * schedules tasklet.
+ */
+ if (test_bit(STATUS_INT_ENABLED, &trans_pcie->status) &&
+ !trans_pcie->inta)
+ iwl_enable_interrupts(trans);
+ return IRQ_NONE;
}
if ((inta == 0xFFFFFFFF) || ((inta & 0xFFFFFFF0) == 0xa5a5a5a0)) {
@@ -1168,19 +1174,7 @@ static irqreturn_t iwl_pcie_isr(int irq, void *data)
trans_pcie->inta |= inta;
/* the thread will service interrupts and re-enable them */
- if (likely(inta))
- return IRQ_WAKE_THREAD;
-
- ret = IRQ_HANDLED;
-
-none:
- /* re-enable interrupts here since we don't have anything to service. */
- /* only Re-enable if disabled by irq and no schedules tasklet. */
- if (test_bit(STATUS_INT_ENABLED, &trans_pcie->status) &&
- !trans_pcie->inta)
- iwl_enable_interrupts(trans);
-
- return ret;
+ return IRQ_WAKE_THREAD;
}
/* interrupt handler using ict table, with this interrupt driver will
--
1.8.3.2
^ permalink raw reply related
* [PATCH] MAINTAINERS: cxgb3: Update cxgb3 maintainer entry
From: Divy Le Ray @ 2013-11-11 23:01 UTC (permalink / raw)
To: davem; +Cc: netdev, santosh, linux-kernel
Santosh raspatur is taking over the maintenance of cxgb3.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ffcaf97..92c062d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2455,7 +2455,7 @@ S: Maintained
F: drivers/media/dvb-frontends/cxd2820r*
CXGB3 ETHERNET DRIVER (CXGB3)
-M: Divy Le Ray <divy@chelsio.com>
+M: Santosh Raspatur <santosh@chelsio.com>
L: netdev@vger.kernel.org
W: http://www.chelsio.com
S: Supported
^ permalink raw reply related
* Re: Bug - regression - Via velocity interface coming up freezes kernel
From: Michele Baldessari @ 2013-11-11 23:46 UTC (permalink / raw)
To: Francois Romieu; +Cc: Dirk Kraft, netdev, Julia Lawall
In-Reply-To: <20130922221109.GA14246@electric-eye.fr.zoreil.com>
Hi Francois,
On Mon, Sep 23, 2013 at 12:11:09AM +0200, Francois Romieu wrote:
> Dirk Kraft <dirk.kraft@gmail.com> :
> [...]
> > I observe problems with my machine freezing when bringing up the
> > network interface (via velocity based). Detailed report below.
> >
> > First message was rejected because of html. Julia Lawall, sorry about
> > sending multiple copies.
> >
> > [1.] One line summary of the problem:
> > Via_velocity interface coming up freezes kernel - WARNING: CPU: 0 PID:
> > 1529 at /build/buildd/linux-3.11.0/kernel/softirq.c:159
> > local_bh_enable+0x60/0x90()
>
> netif_receive_skb with irq disabled ?
>
> You can try this one as a wild guess before I have more time to analyze.
>
> diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
> index d022bf9..64c42be 100644
> --- a/drivers/net/ethernet/via/via-velocity.c
> +++ b/drivers/net/ethernet/via/via-velocity.c
> @@ -2172,16 +2172,13 @@ static int velocity_poll(struct napi_struct *napi, int budget)
> unsigned int rx_done;
> unsigned long flags;
>
> - spin_lock_irqsave(&vptr->lock, flags);
> /*
> * Do rx and tx twice for performance (taken from the VIA
> * out-of-tree driver).
> */
> - rx_done = velocity_rx_srv(vptr, budget / 2);
> - velocity_tx_srv(vptr);
> - rx_done += velocity_rx_srv(vptr, budget - rx_done);
> + rx_done = velocity_rx_srv(vptr, budget);
> + spin_lock_irqsave(&vptr->lock, flags);
> velocity_tx_srv(vptr);
> -
> /* If budget not fully consumed, exit the polling mode */
> if (rx_done < budget) {
> napi_complete(napi);
any chance you can submit this officially? Or does this patch need some
more work?
Two people confirmed it fixed the issue for them on netdev and one
on Fedora's bugzilla so far.
Thanks,
Michele
--
Michele Baldessari <michele@acksyn.org>
C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
^ permalink raw reply
* Re: [patch net-next RFC 0/2] ipv6: allow temporary address management for user-created addresses
From: David Miller @ 2013-11-11 23:03 UTC (permalink / raw)
To: jiri
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, thaller, stephen,
hannes, vyasevich, dcbw
In-Reply-To: <20131111210404.GB2397@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 11 Nov 2013 22:04:04 +0100
> Anyway, should I touch the state in netdev patchwork or should I always
> leave that to you?
>
> I'm used to set "changes requested" before I send another patch version
> and "RFC" when I send RFC patch.
I'd rather others not touch the patchwork state.
You plan to send this again, so whether it's marked RFC or changes requested
is not all that important :-)
^ permalink raw reply
* Re: iproute2: potential upgrade regression with 58a3e827
From: Eric W. Biederman @ 2013-11-11 22:40 UTC (permalink / raw)
To: dilip.daya; +Cc: Chris J Arges, Brian Haley, shemminger, netdev@vger.kernel.org
In-Reply-To: <1384205890.2758.28.camel@dilip-laptop>
Dilip Daya <dilip.daya@hp.com> writes:
> Hi Chris,
>
> On Mon, 2013-11-11 at 15:26 -0600, Chris J Arges wrote:
>
>> Good suggestion,
>> So I'll use a more simple example now:
>>
>> 1)
>> ip netns add first
>> ip netns exec first bash
>>
>> 2)
>> ip netns add second
>> ip netns exec second bash
>>
>> 3)
>> ip netns exec first bash
>>
>> If we do not upgrade the package, after we execute (2) we have:
>> # ls -l /var/run/netns
>> total 0
>> -r-------- 1 root root 0 Nov 11 20:38 first
>> -r-------- 1 root root 0 Nov 11 20:38 second
>>
>> If we upgrade after (1), then run (2) we have:
>> # ls -l /var/run/netns
>> total 0
>> ---------- 1 root root 0 Nov 11 20:56 first
>> -r-------- 1 root root 0 Nov 11 20:57 second
>>
>> So looks like netns add is doing something different from 58a3e827 and on.
I will just add that it is worth looking at /proc/mounts as well.
Although I have to admit that the difference in permissions is odd.
Eric
^ permalink raw reply
* [PATCH net] core/dev: do not ignore dmac in dev_forward_skb()
From: Alexei Starovoitov @ 2013-11-11 21:52 UTC (permalink / raw)
To: David S. Miller
Cc: Eric Dumazet, netdev, Maciej Zenczykowski, Nicolas Dichtel
commit 06a23fe31ca3
("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
and refactoring 64261f230a91
("dev: move skb_scrub_packet() after eth_type_trans()")
are forcing pkt_type to be PACKET_HOST when skb traverses veth.
which means that ip forwarding will kick in inside netns
even if skb->eth->h_dest != dev->dev_addr
Revert offending commit
Fixes: 06a23fe31ca3 ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
CC: Maciej Zenczykowski <zenczykowski@gmail.com>
CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
commit-06a23fe31ca3's testcase is still working,
since pkt_type is now set by ip tunnel
the diff is for 3.12
imo the bug is severe enough that worth queueing for 3.11
net/core/dev.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 3430b1e..2afc521 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1691,13 +1691,9 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
kfree_skb(skb);
return NET_RX_DROP;
}
- skb->protocol = eth_type_trans(skb, dev);
- /* eth_type_trans() can set pkt_type.
- * call skb_scrub_packet() after it to clear pkt_type _after_ calling
- * eth_type_trans().
- */
skb_scrub_packet(skb, true);
+ skb->protocol = eth_type_trans(skb, dev);
return netif_rx(skb);
}
--
1.7.9.5
^ 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