* Re: ping -I eth1 ....
From: Joakim Tjernlund @ 2010-11-05 15:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Thomas Graf
In-Reply-To: <1288969614.2882.590.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/11/05 16:06:54:
>
> Le vendredi 05 novembre 2010 à 15:57 +0100, Joakim Tjernlund a écrit :
> > Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/11/05 15:34:25:
> > t be a reason why in many places we only test (dev->flags &
> > > IFF_UP), and _never_ netif_oper_up() (only in dev_get_flags() to export
> > > it at userspace)
> >
> > Hopefully most of that is legacy or just plain wrong? Unless
> > someone can say why only test IFF_UP one should consider changing them.
> >
>
> Most of the places are hot path.
>
> You dont want to replace one test by four tests.
>
> _This_ would be wrong :)
Wrong is wrong, even if it is in the hot path :)
Perhaps it is time define and internal IFF_OPERATIONAL flag
which is the sum of IFF_UP, IFF_RUNNING etc.? That
way you still get one test in the hot path and can abstract
what defines an operational link.
Jocke
^ permalink raw reply
* [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Eric Dumazet @ 2010-11-05 16:53 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
Andrew
atomic_inc_not_zero() / atomic_add_unless() ... are spreaded in many
arch/xxx/include/asm/atomic.h, but they are generic.
Apparently there is no centralization of some common atomic features...
What do you think adding a new file so that we can move common
definitions in it ?
Thanks
[PATCH] atomic: add atomic_inc_not_zero_hint()
Followup of perf tools session in Netfilter WorkShop 2010
In network stack we make high usage of atomic_inc_not_zero() in contexts
we know the probable value of atomic before increment (2 for udp sockets
for example)
Using a special version of atomic_inc_not_zero() giving this hint can
help processor to use less bus transactions.
On x86 (MESI protocol) for example, this avoids entering Shared state,
because "lock cmpxchg" issues an RFO (Read For Ownership)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
---
include/linux/atomic.h | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
new file mode 100644
index 0000000..c04327a
--- /dev/null
+++ b/include/linux/atomic.h
@@ -0,0 +1,29 @@
+#ifndef _LINUX_ATOMIC_H
+#define _LINUX_ATOMIC_H
+#include <asm/atomic.h>
+
+/**
+ * atomic_inc_not_zero_hint - increment if not null
+ * @v: pointer of type atomic_t
+ * @hint: probable value of the atomic before the increment
+ *
+ * This version of atomic_inc_not_zero() gives a hint of probable
+ * value of the atomic. This helps processor to not read the memory
+ * before doing the atomic read/modify/write cycle, lowering
+ * number of bus transactions on some arches.
+ * Note: hint MUST not be 0 !
+ */
+static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
+{
+ int val, c = hint;
+
+ do {
+ val = atomic_cmpxchg(v, c, c + 1);
+ if (val == c)
+ return 1;
+ c = val;
+ } while (c);
+
+ return 0;
+}
+#endif /* _LINUX_ATOMIC_H */
^ permalink raw reply related
* Re: [PATCH 46/49] net/netfilter: Use vzalloc
From: Jesper Juhl @ 2010-11-05 17:01 UTC (permalink / raw)
To: Eric Dumazet, Joe Perches
Cc: Jiri Kosina, Patrick McHardy, David S. Miller, netfilter-devel,
netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <1288941371.3234.31.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2136 bytes --]
On Fri, 5 Nov 2010, Eric Dumazet wrote:
> Le jeudi 04 novembre 2010 à 23:55 -0700, Joe Perches a écrit :
> > On Fri, 2010-11-05 at 07:30 +0100, Eric Dumazet wrote:
> > > I had _one_ patch, waiting that David actually had vzalloc() in its tree
> > > before sending it.
> >
> > Fine by me, use yours.
>
> I dont care at all, only to say that David tree was not ready yet.
>
>
> >
> > > Given Jesper Juhl was doing this work, could you please take another
> > > one, please ?
> > > For example, explaining him how to use other tools than "bash+egrep
> > > +manual inspection" as he mentioned in a previous mail.
> >
> > Jesper Juhl was both pointed at the cocci docs and
> > given a cocci script. He said he'd investigate it
> > when he could. I trust he will get to it.
> >
>
> Yes, yet you posted patches, knowing he was working on the _same_
> subject.
>
And I will get to look at cocci and spatch, they are definately tools that
I want in my arsenal.
> I remember other occurrences of such behavior.
>
> I find this behavior very unfriendly, time consuming, and not useful.
>
> We try to work together, to increase our common knowledge, not to throw
> a bunch of patches "just because I know better than you"
>
To be completely honest, I did get the feeling that the task I'd set for
myself and was having fun doing in the little spare time I have got
hijacked and I did waste about an hour and a half doing a few more
cleanups before I saw the patchset on lkml.
But on the other hand, the most important thing is that it gets done, not
who ends up doing it - especially since it's such a trivial cleanup, so I
choose to see it as my initial patches just getting the ball rolling.
It would have been nice with at least an email along the lines of "I
know how we can do all those patches in a jiffy, mind if I just go along
and do that?", but I'll live. There's plenty of other stuff to do :-)
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply
* OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-05 17:19 UTC (permalink / raw)
To: NetDev
We are testing 500 mac-vlans with IPv6 addresses on a 32-bit kernel
(2.6.36 + ubuntu patches + our patches) We have one
routing table per interface. It seems that some of them cannot
add routes due to lack of memory.
root@lanforge-ubuntu:/home/lanforge# ip route show table 29
root@lanforge-ubuntu:/home/lanforge# ./local/sbin/ip -6 route add default via 2001:98::1 dev eth12#15 table 29
RTNETLINK answers: Cannot allocate memory
I see errors such as this in the logs:
[507107.846864] PERCPU: allocation failed, size=2048 align=4, failed to allocate new chunk
[507107.846867] Pid: 3246, comm: ip Tainted: P 2.6.36-1-ct #7
[507107.846869] Call Trace:
[507107.846874] [<c05d4996>] ? printk+0x2d/0x2f
[507107.846878] [<c021405e>] pcpu_alloc+0x32e/0x360
[507107.846880] [<c02140bf>] __alloc_percpu+0xf/0x20
[507107.846883] [<c0558d6d>] snmp_mib_init+0x3d/0x70
[507107.846885] [<c0585692>] ipv6_add_dev+0x132/0x350
[507107.846887] [<c0557f39>] ? inetdev_init+0xb9/0x180
[507107.846889] [<c05895ff>] addrconf_notify+0x3f/0x490
[507107.846891] [<c055884f>] ? inetdev_event+0x20f/0x280
[507107.846894] [<c05daef3>] notifier_call_chain+0x43/0x60
[507107.846897] [<c016df4f>] raw_notifier_call_chain+0x1f/0x30
[507107.846899] [<c05008ec>] call_netdevice_notifiers+0x2c/0x60
[507107.846901] [<c0502ecc>] register_netdevice+0x23c/0x380
[507107.846907] [<f80aecf7>] macvlan_common_newlink+0x187/0x2a0 [macvlan]
[507107.846910] [<f80ae540>] ? macvlan_setup+0x0/0x20 [macvlan]
[507107.846912] [<f80aee37>] macvlan_newlink+0x27/0x30 [macvlan]
[507107.846914] [<c0503060>] ? netif_rx+0x0/0x120
[507107.846915] [<c05033c0>] ? dev_forward_skb+0x0/0xf0
[507107.846917] [<f80aee10>] ? macvlan_newlink+0x0/0x30 [macvlan]
[507107.846920] [<c050ea94>] rtnl_newlink+0x464/0x590
[507107.846921] [<c050e7e6>] ? rtnl_newlink+0x1b6/0x590
[507107.846927] [<c050cd2d>] rtnetlink_rcv_msg+0x13d/0x230
[507107.846929] [<c05d721f>] ? _raw_spin_lock_irqsave+0x2f/0x50
[507107.846931] [<c050e630>] ? rtnl_newlink+0x0/0x590
[507107.846933] [<c050cbf0>] ? rtnetlink_rcv_msg+0x0/0x230
[507107.846935] [<c0522276>] netlink_rcv_skb+0x86/0xb0
[507107.846936] [<c050cbdc>] rtnetlink_rcv+0x1c/0x30
[507107.846938] [<c0521f69>] netlink_unicast+0x259/0x280
[507107.846940] [<c0522ba8>] netlink_sendmsg+0x1f8/0x300
[507107.846943] [<c04f0b79>] sock_sendmsg+0xd9/0x100
[507107.846945] [<c013e0dd>] ? finish_task_switch+0x3d/0xc0
[507107.846947] [<c04f0b79>] ? sock_sendmsg+0xd9/0x100
[507107.846950] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
[507107.846957] [<f88bd559>] ? h_d_revalidate+0xe9/0x240 [aufs]
[507107.846958] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
[507107.846962] [<c0364c7d>] ? _copy_from_user+0x3d/0x130
[507107.846965] [<c04f947a>] ? verify_iovec+0x5a/0xa0
[507107.846966] [<c04f112d>] sys_sendmsg+0x15d/0x290
[507107.846972] [<f88c05f1>] ? aufs_fault+0xf1/0x110 [aufs]
[507107.846974] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
[507107.846977] [<c01f8726>] ? handle_mm_fault+0x146/0x400
[507107.846979] [<c05dac0d>] ? do_page_fault+0x1cd/0x470
[507107.846981] [<c023419d>] ? alloc_fd+0xbd/0xf0
[507107.846983] [<c0364c7d>] ? _copy_from_user+0x3d/0x130
[507107.846986] [<c04f183b>] sys_socketcall+0xeb/0x2a0
[507107.846989] [<c0151d99>] ? irq_exit+0x39/0x70
[507107.846991] [<c021bb2e>] ? sys_open+0x2e/0x40
[507107.846993] [<c05d77a4>] syscall_call+0x7/0xb
But, it appears to me that we have plenty of memory available.
top - 10:09:13 up 6 days, 15:56, 9 users, load average: 0.37, 0.39, 0.45
Tasks: 211 total, 2 running, 209 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 2.1%sy, 0.0%ni, 97.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3604332k total, 1510252k used, 2094080k free, 84928k buffers
Swap: 154620k total, 0k used, 154620k free, 1045912k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
root@lanforge-ubuntu:/home/lanforge# cat /proc/meminfo
MemTotal: 3604332 kB
MemFree: 2094568 kB
Buffers: 84928 kB
Cached: 1045920 kB
SwapCached: 0 kB
Active: 466784 kB
Inactive: 805632 kB
Active(anon): 148988 kB
Inactive(anon): 6788 kB
Active(file): 317796 kB
Inactive(file): 798844 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 2752008 kB
HighFree: 1512380 kB
LowTotal: 852324 kB
LowFree: 582188 kB
SwapTotal: 154620 kB
SwapFree: 154620 kB
Dirty: 492 kB
Writeback: 0 kB
AnonPages: 141316 kB
Mapped: 39428 kB
Shmem: 14208 kB
Slab: 170788 kB
SReclaimable: 81904 kB
SUnreclaim: 88884 kB
KernelStack: 2520 kB
PageTables: 4516 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1956784 kB
Committed_AS: 582604 kB
VmallocTotal: 122880 kB
VmallocUsed: 48592 kB
VmallocChunk: 24280 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 4096 kB
DirectMap4k: 12280 kB
DirectMap4M: 897024 kB
Is there any way to tune the system so that it has more memory available
for per-cpu data structures?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Andrew Morton @ 2010-11-05 17:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <1288975980.2882.877.camel@edumazet-laptop>
On Fri, 05 Nov 2010 17:53:00 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Andrew
>
> atomic_inc_not_zero() / atomic_add_unless() ... are spreaded in many
> arch/xxx/include/asm/atomic.h, but they are generic.
>
> Apparently there is no centralization of some common atomic features...
>
> What do you think adding a new file so that we can move common
> definitions in it ?
>
> Thanks
>
> [PATCH] atomic: add atomic_inc_not_zero_hint()
>
> Followup of perf tools session in Netfilter WorkShop 2010
>
> In network stack we make high usage of atomic_inc_not_zero() in contexts
> we know the probable value of atomic before increment (2 for udp sockets
> for example)
>
> Using a special version of atomic_inc_not_zero() giving this hint can
> help processor to use less bus transactions.
>
> On x86 (MESI protocol) for example, this avoids entering Shared state,
> because "lock cmpxchg" issues an RFO (Read For Ownership)
It totally makes sense to add include/linu/atomic.h for common things.
Perhaps there's already code in arch/*/include/asm/atomic.h which
should be hoisted up there. But that can't reliably be done until a
million files have had their #includes switched :(
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Christoph Lameter <cl@linux-foundation.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
> Cc: David Miller <davem@davemloft.net>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Nick Piggin <npiggin@kernel.dk>
> ---
> include/linux/atomic.h | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> new file mode 100644
> index 0000000..c04327a
> --- /dev/null
> +++ b/include/linux/atomic.h
> @@ -0,0 +1,29 @@
> +#ifndef _LINUX_ATOMIC_H
> +#define _LINUX_ATOMIC_H
> +#include <asm/atomic.h>
> +
> +/**
> + * atomic_inc_not_zero_hint - increment if not null
> + * @v: pointer of type atomic_t
> + * @hint: probable value of the atomic before the increment
> + *
> + * This version of atomic_inc_not_zero() gives a hint of probable
> + * value of the atomic. This helps processor to not read the memory
> + * before doing the atomic read/modify/write cycle, lowering
> + * number of bus transactions on some arches.
> + * Note: hint MUST not be 0 !
> + */
It's quite unobvious *why* `hint' cannot be zero. Can you please add
the reasoning to the comment? Also, the local `hint' should be
referred to as "@hint" in a kerneldoc comment.
> +static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
> +{
> + int val, c = hint;
> +
> + do {
> + val = atomic_cmpxchg(v, c, c + 1);
> + if (val == c)
> + return 1;
> + c = val;
> + } while (c);
> +
> + return 0;
> +}
Should/could this have implemented a more general
atomic_add_not_zero_hint() and made atomic_inc_not_zero_hint() a
wrapper around that?
Also, it might make sense to add "#ifndef atomic_inc_not_zero_hint"
wrappers around this function so that the arch can implement an
overriding custom version. And that becomes a general rule as more
functions are added to include/linux/atomic.h.
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Eric Dumazet @ 2010-11-05 18:00 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <20101105102038.53e36f9e.akpm@linux-foundation.org>
Le vendredi 05 novembre 2010 à 10:20 -0700, Andrew Morton a écrit :
> It totally makes sense to add include/linu/atomic.h for common things.
> Perhaps there's already code in arch/*/include/asm/atomic.h which
> should be hoisted up there. But that can't reliably be done until a
> million files have had their #includes switched :(
>
Maybe including <linux/atomic.h> only from the end of various
arch/*/include/asm/atomic.h ?
In this case, I remove the include <asm/atomic.h> from linux/atomic.h
> It's quite unobvious *why* `hint' cannot be zero. Can you please add
> the reasoning to the comment? Also, the local `hint' should be
> referred to as "@hint" in a kerneldoc comment.
Well ;)
We want to increment the counter if its not zero.
Typically used for refcounts, of RCU protected structures.
Giving a zero hint would be curious dont you think ?
I see no usage for this, and using atomic_inc_not_zero() in this case is
the only choice, since we dont ever want to cmpxchg(v, 0, 1) (or risk
double free and crazy things)
Hmm... maybe I can add a test (compiler should optimize it anyway, since
all usages I can foresee will use a constant hint)
>
> > +static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
> > +{
> > + int val, c = hint;
> > +
> > + do {
> > + val = atomic_cmpxchg(v, c, c + 1);
> > + if (val == c)
> > + return 1;
> > + c = val;
> > + } while (c);
> > +
> > + return 0;
> > +}
>
> Should/could this have implemented a more general
> atomic_add_not_zero_hint() and made atomic_inc_not_zero_hint() a
> wrapper around that?
Well, I see no practical use for this, but yes, this could be done.
As atomic_add_not_zero() doesnt exist, I am not sure we need an
atomic_add_not_zero_hint() yet ?
>
> Also, it might make sense to add "#ifndef atomic_inc_not_zero_hint"
> wrappers around this function so that the arch can implement an
> overriding custom version. And that becomes a general rule as more
> functions are added to include/linux/atomic.h.
Ah yes, thats right !
Thanks !
[PATCH v2] atomic: add atomic_inc_not_zero_hint()
Followup of perf tools session in Netfilter WorkShop 2010
In network stack we make high usage of atomic_inc_not_zero() in contexts
we know the probable value of atomic before increment (2 for udp sockets
for example)
Using a special version of atomic_inc_not_zero() giving this hint can
help processor to use less bus transactions.
On x86 (MESI protocol) for example, this avoids entering Shared state,
because "lock cmpxchg" issues an RFO (Read For Ownership)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
---
V2: add #ifndef atomic_inc_not_zero_hint
kerneldoc changes
test that hint is not null
Meant to be included at end of arch/*/asm/atomic.h files
include/linux/atomic.h | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
new file mode 100644
index 0000000..0897bdd
--- /dev/null
+++ b/include/linux/atomic.h
@@ -0,0 +1,36 @@
+#ifndef _LINUX_ATOMIC_H
+#define _LINUX_ATOMIC_H
+
+/**
+ * atomic_inc_not_zero_hint - increment if not null
+ * @v: pointer of type atomic_t
+ * @hint: probable value of the atomic before the increment
+ *
+ * This version of atomic_inc_not_zero() gives a hint of probable
+ * value of the atomic. This helps processor to not read memory
+ * before doing the atomic read/modify/write cycle, lowering
+ * number of bus transactions on some arches.
+ * Note: @hint MUST not be 0, or increment is not done.
+ * Returns: 0 if increment was not done, 1 otherwise.
+ */
+#ifndef atomic_inc_not_zero_hint
+static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
+{
+ int val, c = hint;
+
+ /* sanity test, should be removed by compiler if hint is a constant */
+ if (!hint)
+ return 0;
+
+ do {
+ val = atomic_cmpxchg(v, c, c + 1);
+ if (val == c)
+ return 1;
+ c = val;
+ } while (c);
+
+ return 0;
+}
+#endif
+
+#endif /* _LINUX_ATOMIC_H */
^ permalink raw reply related
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-05 18:06 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <4CD43C87.5040403@candelatech.com>
Le vendredi 05 novembre 2010 à 10:19 -0700, Ben Greear a écrit :
> We are testing 500 mac-vlans with IPv6 addresses on a 32-bit kernel
> (2.6.36 + ubuntu patches + our patches) We have one
> routing table per interface. It seems that some of them cannot
> add routes due to lack of memory.
>
> root@lanforge-ubuntu:/home/lanforge# ip route show table 29
> root@lanforge-ubuntu:/home/lanforge# ./local/sbin/ip -6 route add default via 2001:98::1 dev eth12#15 table 29
> RTNETLINK answers: Cannot allocate memory
>
> I see errors such as this in the logs:
>
> [507107.846864] PERCPU: allocation failed, size=2048 align=4, failed to allocate new chunk
> [507107.846867] Pid: 3246, comm: ip Tainted: P 2.6.36-1-ct #7
> [507107.846869] Call Trace:
> [507107.846874] [<c05d4996>] ? printk+0x2d/0x2f
> [507107.846878] [<c021405e>] pcpu_alloc+0x32e/0x360
> [507107.846880] [<c02140bf>] __alloc_percpu+0xf/0x20
> [507107.846883] [<c0558d6d>] snmp_mib_init+0x3d/0x70
> [507107.846885] [<c0585692>] ipv6_add_dev+0x132/0x350
> [507107.846887] [<c0557f39>] ? inetdev_init+0xb9/0x180
> [507107.846889] [<c05895ff>] addrconf_notify+0x3f/0x490
> [507107.846891] [<c055884f>] ? inetdev_event+0x20f/0x280
> [507107.846894] [<c05daef3>] notifier_call_chain+0x43/0x60
> [507107.846897] [<c016df4f>] raw_notifier_call_chain+0x1f/0x30
> [507107.846899] [<c05008ec>] call_netdevice_notifiers+0x2c/0x60
> [507107.846901] [<c0502ecc>] register_netdevice+0x23c/0x380
> [507107.846907] [<f80aecf7>] macvlan_common_newlink+0x187/0x2a0 [macvlan]
> [507107.846910] [<f80ae540>] ? macvlan_setup+0x0/0x20 [macvlan]
> [507107.846912] [<f80aee37>] macvlan_newlink+0x27/0x30 [macvlan]
> [507107.846914] [<c0503060>] ? netif_rx+0x0/0x120
> [507107.846915] [<c05033c0>] ? dev_forward_skb+0x0/0xf0
> [507107.846917] [<f80aee10>] ? macvlan_newlink+0x0/0x30 [macvlan]
> [507107.846920] [<c050ea94>] rtnl_newlink+0x464/0x590
> [507107.846921] [<c050e7e6>] ? rtnl_newlink+0x1b6/0x590
> [507107.846927] [<c050cd2d>] rtnetlink_rcv_msg+0x13d/0x230
> [507107.846929] [<c05d721f>] ? _raw_spin_lock_irqsave+0x2f/0x50
> [507107.846931] [<c050e630>] ? rtnl_newlink+0x0/0x590
> [507107.846933] [<c050cbf0>] ? rtnetlink_rcv_msg+0x0/0x230
> [507107.846935] [<c0522276>] netlink_rcv_skb+0x86/0xb0
> [507107.846936] [<c050cbdc>] rtnetlink_rcv+0x1c/0x30
> [507107.846938] [<c0521f69>] netlink_unicast+0x259/0x280
> [507107.846940] [<c0522ba8>] netlink_sendmsg+0x1f8/0x300
> [507107.846943] [<c04f0b79>] sock_sendmsg+0xd9/0x100
> [507107.846945] [<c013e0dd>] ? finish_task_switch+0x3d/0xc0
> [507107.846947] [<c04f0b79>] ? sock_sendmsg+0xd9/0x100
> [507107.846950] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
> [507107.846957] [<f88bd559>] ? h_d_revalidate+0xe9/0x240 [aufs]
> [507107.846958] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
> [507107.846962] [<c0364c7d>] ? _copy_from_user+0x3d/0x130
> [507107.846965] [<c04f947a>] ? verify_iovec+0x5a/0xa0
> [507107.846966] [<c04f112d>] sys_sendmsg+0x15d/0x290
> [507107.846972] [<f88c05f1>] ? aufs_fault+0xf1/0x110 [aufs]
> [507107.846974] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
> [507107.846977] [<c01f8726>] ? handle_mm_fault+0x146/0x400
> [507107.846979] [<c05dac0d>] ? do_page_fault+0x1cd/0x470
> [507107.846981] [<c023419d>] ? alloc_fd+0xbd/0xf0
> [507107.846983] [<c0364c7d>] ? _copy_from_user+0x3d/0x130
> [507107.846986] [<c04f183b>] sys_socketcall+0xeb/0x2a0
> [507107.846989] [<c0151d99>] ? irq_exit+0x39/0x70
> [507107.846991] [<c021bb2e>] ? sys_open+0x2e/0x40
> [507107.846993] [<c05d77a4>] syscall_call+0x7/0xb
>
>
> But, it appears to me that we have plenty of memory available.
>
> top - 10:09:13 up 6 days, 15:56, 9 users, load average: 0.37, 0.39, 0.45
> Tasks: 211 total, 2 running, 209 sleeping, 0 stopped, 0 zombie
> Cpu(s): 0.7%us, 2.1%sy, 0.0%ni, 97.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
> Mem: 3604332k total, 1510252k used, 2094080k free, 84928k buffers
> Swap: 154620k total, 0k used, 154620k free, 1045912k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>
>
> root@lanforge-ubuntu:/home/lanforge# cat /proc/meminfo
> MemTotal: 3604332 kB
> MemFree: 2094568 kB
> Buffers: 84928 kB
> Cached: 1045920 kB
> SwapCached: 0 kB
> Active: 466784 kB
> Inactive: 805632 kB
> Active(anon): 148988 kB
> Inactive(anon): 6788 kB
> Active(file): 317796 kB
> Inactive(file): 798844 kB
> Unevictable: 0 kB
> Mlocked: 0 kB
> HighTotal: 2752008 kB
> HighFree: 1512380 kB
> LowTotal: 852324 kB
> LowFree: 582188 kB
> SwapTotal: 154620 kB
> SwapFree: 154620 kB
> Dirty: 492 kB
> Writeback: 0 kB
> AnonPages: 141316 kB
> Mapped: 39428 kB
> Shmem: 14208 kB
> Slab: 170788 kB
> SReclaimable: 81904 kB
> SUnreclaim: 88884 kB
> KernelStack: 2520 kB
> PageTables: 4516 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 1956784 kB
> Committed_AS: 582604 kB
> VmallocTotal: 122880 kB
> VmallocUsed: 48592 kB
> VmallocChunk: 24280 kB
> HardwareCorrupted: 0 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> HugePages_Surp: 0
> Hugepagesize: 4096 kB
> DirectMap4k: 12280 kB
> DirectMap4M: 897024 kB
>
>
> Is there any way to tune the system so that it has more memory available
> for per-cpu data structures?
CC linux-kernel and Tejun Heo
How many possible cpus do you have ?
head -1 /proc/interrupts
and please post :
cat /proc/vmallocinfo
Thanks
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Andrew Morton @ 2010-11-05 18:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <1288980046.2882.1054.camel@edumazet-laptop>
On Fri, 05 Nov 2010 19:00:46 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 05 novembre 2010 __ 10:20 -0700, Andrew Morton a __crit :
>
> > It totally makes sense to add include/linu/atomic.h for common things.
> > Perhaps there's already code in arch/*/include/asm/atomic.h which
> > should be hoisted up there. But that can't reliably be done until a
> > million files have had their #includes switched :(
> >
>
> Maybe including <linux/atomic.h> only from the end of various
>
> arch/*/include/asm/atomic.h ?
heh, I guess that would work. It breaks the standard way of doing
these things (I think?) so let's not go there unless we have a need?
> In this case, I remove the include <asm/atomic.h> from linux/atomic.h
Oh. Why? I thought it was better the previous, standard way: thou
shalt henceforth include liunx/atomic.h, not asm/atomic.h. And the
presence of linux/atomic.h will in fact trigger the checkpatch warning
telling people to use that when they try to use asm/atomic.h.
> > > +static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
> > > +{
> > > + int val, c = hint;
> > > +
> > > + do {
> > > + val = atomic_cmpxchg(v, c, c + 1);
> > > + if (val == c)
> > > + return 1;
> > > + c = val;
> > > + } while (c);
> > > +
> > > + return 0;
> > > +}
> >
> > Should/could this have implemented a more general
> > atomic_add_not_zero_hint() and made atomic_inc_not_zero_hint() a
> > wrapper around that?
>
> Well, I see no practical use for this, but yes, this could be done.
>
> As atomic_add_not_zero() doesnt exist, I am not sure we need an
> atomic_add_not_zero_hint() yet ?
hm, OK. I was just checking ;)
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-05 18:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <1288980361.2882.1070.camel@edumazet-laptop>
On 11/05/2010 11:06 AM, Eric Dumazet wrote:
> Le vendredi 05 novembre 2010 à 10:19 -0700, Ben Greear a écrit :
>> We are testing 500 mac-vlans with IPv6 addresses on a 32-bit kernel
>> (2.6.36 + ubuntu patches + our patches) We have one
>> routing table per interface. It seems that some of them cannot
>> add routes due to lack of memory.
>>
>> root@lanforge-ubuntu:/home/lanforge# ip route show table 29
>> root@lanforge-ubuntu:/home/lanforge# ./local/sbin/ip -6 route add default via 2001:98::1 dev eth12#15 table 29
>> RTNETLINK answers: Cannot allocate memory
>>
>> I see errors such as this in the logs:
>>
>> [507107.846864] PERCPU: allocation failed, size=2048 align=4, failed to allocate new chunk
>> [507107.846867] Pid: 3246, comm: ip Tainted: P 2.6.36-1-ct #7
>> [507107.846869] Call Trace:
>> [507107.846874] [<c05d4996>] ? printk+0x2d/0x2f
>> [507107.846878] [<c021405e>] pcpu_alloc+0x32e/0x360
>> [507107.846880] [<c02140bf>] __alloc_percpu+0xf/0x20
>> [507107.846883] [<c0558d6d>] snmp_mib_init+0x3d/0x70
>> [507107.846885] [<c0585692>] ipv6_add_dev+0x132/0x350
>> [507107.846887] [<c0557f39>] ? inetdev_init+0xb9/0x180
>> [507107.846889] [<c05895ff>] addrconf_notify+0x3f/0x490
>> [507107.846891] [<c055884f>] ? inetdev_event+0x20f/0x280
>> [507107.846894] [<c05daef3>] notifier_call_chain+0x43/0x60
>> [507107.846897] [<c016df4f>] raw_notifier_call_chain+0x1f/0x30
>> [507107.846899] [<c05008ec>] call_netdevice_notifiers+0x2c/0x60
>> [507107.846901] [<c0502ecc>] register_netdevice+0x23c/0x380
>> [507107.846907] [<f80aecf7>] macvlan_common_newlink+0x187/0x2a0 [macvlan]
>> [507107.846910] [<f80ae540>] ? macvlan_setup+0x0/0x20 [macvlan]
>> [507107.846912] [<f80aee37>] macvlan_newlink+0x27/0x30 [macvlan]
>> [507107.846914] [<c0503060>] ? netif_rx+0x0/0x120
>> [507107.846915] [<c05033c0>] ? dev_forward_skb+0x0/0xf0
>> [507107.846917] [<f80aee10>] ? macvlan_newlink+0x0/0x30 [macvlan]
>> [507107.846920] [<c050ea94>] rtnl_newlink+0x464/0x590
>> [507107.846921] [<c050e7e6>] ? rtnl_newlink+0x1b6/0x590
>> [507107.846927] [<c050cd2d>] rtnetlink_rcv_msg+0x13d/0x230
>> [507107.846929] [<c05d721f>] ? _raw_spin_lock_irqsave+0x2f/0x50
>> [507107.846931] [<c050e630>] ? rtnl_newlink+0x0/0x590
>> [507107.846933] [<c050cbf0>] ? rtnetlink_rcv_msg+0x0/0x230
>> [507107.846935] [<c0522276>] netlink_rcv_skb+0x86/0xb0
>> [507107.846936] [<c050cbdc>] rtnetlink_rcv+0x1c/0x30
>> [507107.846938] [<c0521f69>] netlink_unicast+0x259/0x280
>> [507107.846940] [<c0522ba8>] netlink_sendmsg+0x1f8/0x300
>> [507107.846943] [<c04f0b79>] sock_sendmsg+0xd9/0x100
>> [507107.846945] [<c013e0dd>] ? finish_task_switch+0x3d/0xc0
>> [507107.846947] [<c04f0b79>] ? sock_sendmsg+0xd9/0x100
>> [507107.846950] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
>> [507107.846957] [<f88bd559>] ? h_d_revalidate+0xe9/0x240 [aufs]
>> [507107.846958] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
>> [507107.846962] [<c0364c7d>] ? _copy_from_user+0x3d/0x130
>> [507107.846965] [<c04f947a>] ? verify_iovec+0x5a/0xa0
>> [507107.846966] [<c04f112d>] sys_sendmsg+0x15d/0x290
>> [507107.846972] [<f88c05f1>] ? aufs_fault+0xf1/0x110 [aufs]
>> [507107.846974] [<c013361d>] ? kmap_atomic_prot+0xcd/0xf0
>> [507107.846977] [<c01f8726>] ? handle_mm_fault+0x146/0x400
>> [507107.846979] [<c05dac0d>] ? do_page_fault+0x1cd/0x470
>> [507107.846981] [<c023419d>] ? alloc_fd+0xbd/0xf0
>> [507107.846983] [<c0364c7d>] ? _copy_from_user+0x3d/0x130
>> [507107.846986] [<c04f183b>] sys_socketcall+0xeb/0x2a0
>> [507107.846989] [<c0151d99>] ? irq_exit+0x39/0x70
>> [507107.846991] [<c021bb2e>] ? sys_open+0x2e/0x40
>> [507107.846993] [<c05d77a4>] syscall_call+0x7/0xb
>>
>>
>> But, it appears to me that we have plenty of memory available.
>>
>> top - 10:09:13 up 6 days, 15:56, 9 users, load average: 0.37, 0.39, 0.45
>> Tasks: 211 total, 2 running, 209 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 0.7%us, 2.1%sy, 0.0%ni, 97.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>> Mem: 3604332k total, 1510252k used, 2094080k free, 84928k buffers
>> Swap: 154620k total, 0k used, 154620k free, 1045912k cached
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>
>>
>> root@lanforge-ubuntu:/home/lanforge# cat /proc/meminfo
>> MemTotal: 3604332 kB
>> MemFree: 2094568 kB
>> Buffers: 84928 kB
>> Cached: 1045920 kB
>> SwapCached: 0 kB
>> Active: 466784 kB
>> Inactive: 805632 kB
>> Active(anon): 148988 kB
>> Inactive(anon): 6788 kB
>> Active(file): 317796 kB
>> Inactive(file): 798844 kB
>> Unevictable: 0 kB
>> Mlocked: 0 kB
>> HighTotal: 2752008 kB
>> HighFree: 1512380 kB
>> LowTotal: 852324 kB
>> LowFree: 582188 kB
>> SwapTotal: 154620 kB
>> SwapFree: 154620 kB
>> Dirty: 492 kB
>> Writeback: 0 kB
>> AnonPages: 141316 kB
>> Mapped: 39428 kB
>> Shmem: 14208 kB
>> Slab: 170788 kB
>> SReclaimable: 81904 kB
>> SUnreclaim: 88884 kB
>> KernelStack: 2520 kB
>> PageTables: 4516 kB
>> NFS_Unstable: 0 kB
>> Bounce: 0 kB
>> WritebackTmp: 0 kB
>> CommitLimit: 1956784 kB
>> Committed_AS: 582604 kB
>> VmallocTotal: 122880 kB
>> VmallocUsed: 48592 kB
>> VmallocChunk: 24280 kB
>> HardwareCorrupted: 0 kB
>> HugePages_Total: 0
>> HugePages_Free: 0
>> HugePages_Rsvd: 0
>> HugePages_Surp: 0
>> Hugepagesize: 4096 kB
>> DirectMap4k: 12280 kB
>> DirectMap4M: 897024 kB
>>
>>
>> Is there any way to tune the system so that it has more memory available
>> for per-cpu data structures?
>
> CC linux-kernel and Tejun Heo
>
> How many possible cpus do you have ?
> head -1 /proc/interrupts
oot@lanforge-ubuntu:/home/lanforge# head -1 /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
>
> and please post :
> cat /proc/vmallocinfo
root@lanforge-ubuntu:/home/lanforge# cat /proc/vmallocinfo
0xf7ffe000-0xf8000000 8192 hpet_enable+0x2d/0x1b8 phys=fed00000 ioremap
0xf8002000-0xf8004000 8192 acpi_os_map_memory+0x16/0x1f phys=df79e000 ioremap
0xf8004000-0xf8007000 12288 acpi_os_map_memory+0x16/0x1f phys=df7a0000 ioremap
0xf8008000-0xf800a000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
0xf800b000-0xf8010000 20480 module_alloc+0x72/0x80 pages=4 vmalloc
0xf8010000-0xf8019000 36864 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
0xf801a000-0xf801c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf801d000-0xf8020000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8023000-0xf8026000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xf8026000-0xf8028000 8192 msix_capability_init+0xae/0x2b0 phys=fa4fe000 ioremap
0xf8028000-0xf802a000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf802b000-0xf802e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf802f000-0xf8032000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8033000-0xf8036000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8037000-0xf803a000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf803b000-0xf803e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf803f000-0xf8048000 36864 module_alloc+0x72/0x80 pages=8 vmalloc
0xf804b000-0xf8055000 40960 module_alloc+0x72/0x80 pages=9 vmalloc
0xf8056000-0xf8059000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf805b000-0xf8063000 32768 module_alloc+0x72/0x80 pages=7 vmalloc
0xf8066000-0xf8068000 8192 msix_capability_init+0xae/0x2b0 phys=fa4fa000 ioremap
0xf8068000-0xf8070000 32768 module_alloc+0x72/0x80 pages=7 vmalloc
0xf8072000-0xf8075000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xf8076000-0xf8083000 53248 module_alloc+0x72/0x80 pages=12 vmalloc
0xf8084000-0xf8087000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8088000-0xf808b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf808c000-0xf808f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8090000-0xf8093000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8094000-0xf8097000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8098000-0xf809b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf809c000-0xf809f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80a2000-0xf80ad000 45056 module_alloc+0x72/0x80 pages=10 vmalloc
0xf80ae000-0xf80b2000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
0xf80b3000-0xf80b6000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80b7000-0xf80ba000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80bb000-0xf80be000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80bf000-0xf80c2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80c3000-0xf80c6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80c8000-0xf80cd000 20480 pci_iomap+0x81/0x90 phys=fa4fc000 ioremap
0xf80ce000-0xf80d1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80d2000-0xf80d5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80d6000-0xf80d9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80da000-0xf80dd000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80de000-0xf80e1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80e2000-0xf80e5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80e6000-0xf80e9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80ea000-0xf80ed000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80ee000-0xf80f1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80f2000-0xf80f5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80f6000-0xf80f9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80fa000-0xf80fd000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf80fe000-0xf8101000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8102000-0xf8105000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8106000-0xf8109000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf810a000-0xf810d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf810d000-0xf8118000 45056 module_alloc+0x72/0x80 pages=10 vmalloc
0xf8119000-0xf811c000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf811d000-0xf8120000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8121000-0xf8124000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8125000-0xf8128000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8129000-0xf812c000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf812d000-0xf8130000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8130000-0xf8132000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf8133000-0xf8136000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xf8137000-0xf813a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf813e000-0xf8140000 8192 msix_capability_init+0xae/0x2b0 phys=fa4f6000 ioremap
0xf8140000-0xf8145000 20480 pci_iomap+0x81/0x90 phys=fa4f8000 ioremap
0xf8146000-0xf8148000 8192 msix_capability_init+0xae/0x2b0 phys=fa4f2000 ioremap
0xf8148000-0xf814d000 20480 pci_iomap+0x81/0x90 phys=fa4f4000 ioremap
0xf814e000-0xf8150000 8192 msix_capability_init+0xae/0x2b0 phys=fa4ee000 ioremap
0xf8150000-0xf8155000 20480 pci_iomap+0x81/0x90 phys=fa4f0000 ioremap
0xf8156000-0xf8158000 8192 msix_capability_init+0xae/0x2b0 phys=fa4ea000 ioremap
0xf8158000-0xf815d000 20480 pci_iomap+0x81/0x90 phys=fa4ec000 ioremap
0xf815e000-0xf8160000 8192 msix_capability_init+0xae/0x2b0 phys=fa4e6000 ioremap
0xf8160000-0xf8165000 20480 pci_iomap+0x81/0x90 phys=fa4e8000 ioremap
0xf8166000-0xf8168000 8192 msix_capability_init+0xae/0x2b0 phys=fa4e2000 ioremap
0xf8168000-0xf816d000 20480 pci_iomap+0x81/0x90 phys=fa4e4000 ioremap
0xf816e000-0xf8170000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf8170000-0xf8175000 20480 pci_iomap+0x81/0x90 phys=fa4e0000 ioremap
0xf8176000-0xf8179000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf817a000-0xf817d000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf817e000-0xf8181000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8182000-0xf8185000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8186000-0xf8189000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf818e000-0xf819d000 61440 module_alloc+0x72/0x80 pages=14 vmalloc
0xf819e000-0xf81a1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81a2000-0xf81a5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81a6000-0xf81a9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81aa000-0xf81ad000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81ae000-0xf81b1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81b2000-0xf81b5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81b6000-0xf81b9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81ba000-0xf81bd000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81be000-0xf81c1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81c2000-0xf81c5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf81fe000-0xf8201000 12288 e1000e_setup_tx_resources+0x27/0xb0 [e1000e] pages=2 vmalloc
0xf8202000-0xf8205000 12288 e1000e_setup_rx_resources+0x2a/0x120 [e1000e] pages=2 vmalloc
0xf8206000-0xf8209000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf820c000-0xf820f000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xf8210000-0xf8213000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8214000-0xf8217000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8218000-0xf821c000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
0xf8225000-0xf8228000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8229000-0xf822b000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf82ab000-0xf82ae000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82af000-0xf82b2000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82b3000-0xf82b6000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82b7000-0xf82ba000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82bb000-0xf82be000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82bf000-0xf82c2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82c3000-0xf82c6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82c7000-0xf82ca000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82cb000-0xf82ce000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82cf000-0xf82d2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82d3000-0xf82d6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82d7000-0xf82da000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82db000-0xf82de000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82df000-0xf82e2000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82e3000-0xf82e6000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82e7000-0xf82ea000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82eb000-0xf82ee000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf82ef000-0xf82f2000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8332000-0xf8363000 200704 module_alloc+0x72/0x80 pages=48 vmalloc
0xf8364000-0xf8367000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8368000-0xf836b000 12288 e1000e_setup_tx_resources+0x27/0xb0 [e1000e] pages=2 vmalloc
0xf836c000-0xf836f000 12288 e1000e_setup_rx_resources+0x2a/0x120 [e1000e] pages=2 vmalloc
0xf8370000-0xf8373000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8374000-0xf8377000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8378000-0xf837b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf837c000-0xf837f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf837f000-0xf83a0000 135168 module_alloc+0x72/0x80 pages=32 vmalloc
0xf83a1000-0xf83a4000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf83a5000-0xf83a8000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf83a9000-0xf83ac000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf83ad000-0xf83b0000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf83b0000-0xf83ba000 40960 module_alloc+0x72/0x80 pages=9 vmalloc
0xf83bb000-0xf83bd000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf83be000-0xf83c1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf83cc000-0xf83e5000 102400 module_alloc+0x72/0x80 pages=24 vmalloc
0xf83ec000-0xf83ee000 8192 msix_capability_init+0xae/0x2b0 phys=faedc000 ioremap
0xf83f0000-0xf83f2000 8192 msix_capability_init+0xae/0x2b0 phys=fa69c000 ioremap
0xf83fa000-0xf83fc000 8192 msix_capability_init+0xae/0x2b0 phys=fafdc000 ioremap
0xf83fe000-0xf8400000 8192 msix_capability_init+0xae/0x2b0 phys=fa698000 ioremap
0xf8400000-0xf8421000 135168 e1000_probe+0x206/0x9d0 [e1000e] phys=faee0000 ioremap
0xf8422000-0xf8424000 8192 msix_capability_init+0xae/0x2b0 phys=fa79c000 ioremap
0xf8426000-0xf8428000 8192 msix_capability_init+0xae/0x2b0 phys=fa798000 ioremap
0xf842a000-0xf842c000 8192 msix_capability_init+0xae/0x2b0 phys=fa99c000 ioremap
0xf842e000-0xf8430000 8192 msix_capability_init+0xae/0x2b0 phys=fa998000 ioremap
0xf8432000-0xf8434000 8192 msix_capability_init+0xae/0x2b0 phys=faa9c000 ioremap
0xf8436000-0xf8438000 8192 msix_capability_init+0xae/0x2b0 phys=faa98000 ioremap
0xf843a000-0xf843c000 8192 msix_capability_init+0xae/0x2b0 phys=fac9c000 ioremap
0xf843e000-0xf8440000 8192 msix_capability_init+0xae/0x2b0 phys=fac98000 ioremap
0xf8440000-0xf8461000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa6e0000 ioremap
0xf8462000-0xf8464000 8192 msix_capability_init+0xae/0x2b0 phys=fad9c000 ioremap
0xf8466000-0xf8468000 8192 msix_capability_init+0xae/0x2b0 phys=fad98000 ioremap
0xf846c000-0xf846e000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf8476000-0xf8478000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf8480000-0xf84a1000 135168 e1000_probe+0x206/0x9d0 [e1000e] phys=fafe0000 ioremap
0xf84a9000-0xf84af000 24576 module_alloc+0x72/0x80 pages=5 vmalloc
0xf84bc000-0xf84bf000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf84c0000-0xf84e1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa660000 ioremap
0xf84e2000-0xf84e5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf84e6000-0xf84e9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf84ea000-0xf84ed000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf84ee000-0xf84f1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf84f2000-0xf84f5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf84f6000-0xf84f9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf84fb000-0xf84ff000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
0xf8500000-0xf8521000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa7e0000 ioremap
0xf8522000-0xf852f000 53248 module_alloc+0x72/0x80 pages=12 vmalloc
0xf8530000-0xf8533000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8534000-0xf8537000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8538000-0xf853b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf853c000-0xf853f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8540000-0xf8561000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa760000 ioremap
0xf8562000-0xf8565000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xf8566000-0xf8569000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf856a000-0xf856c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xf856d000-0xf8570000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8571000-0xf8574000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8575000-0xf8578000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8579000-0xf857c000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf857d000-0xf857f000 8192 swap_cgroup_swapon+0x3c/0x140 pages=1 vmalloc
0xf8580000-0xf85a1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa9e0000 ioremap
0xf85a2000-0xf85a5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf85a6000-0xf85a9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf85aa000-0xf85ad000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf85af000-0xf85b7000 32768 module_alloc+0x72/0x80 pages=7 vmalloc
0xf85b8000-0xf85bb000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf85bc000-0xf85bf000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf85c0000-0xf85e1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa960000 ioremap
0xf85e2000-0xf85ed000 45056 sys_swapon+0x5a6/0xa40 pages=10 vmalloc
0xf85ee000-0xf8600000 73728 module_alloc+0x72/0x80 pages=17 vmalloc
0xf8600000-0xf8621000 135168 igb_probe+0x1f5/0x87a [igb] phys=faae0000 ioremap
0xf8622000-0xf8625000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8626000-0xf8629000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf862a000-0xf862d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf862e000-0xf8631000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8632000-0xf8635000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8636000-0xf8639000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf863a000-0xf863d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8640000-0xf8661000 135168 igb_probe+0x1f5/0x87a [igb] phys=faa60000 ioremap
0xf8662000-0xf8665000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8666000-0xf8669000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf866a000-0xf866d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf866e000-0xf8671000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8672000-0xf8675000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8676000-0xf8679000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf867a000-0xf867d000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8680000-0xf86a1000 135168 igb_probe+0x1f5/0x87a [igb] phys=face0000 ioremap
0xf86a2000-0xf86a5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf86a6000-0xf86a9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf86aa000-0xf86ad000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf86ae000-0xf86b1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf86b2000-0xf86b5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf86b6000-0xf86b9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf86ba000-0xf86bd000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf86c0000-0xf86e1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fac60000 ioremap
0xf86e2000-0xf86e5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8700000-0xf8721000 135168 igb_probe+0x1f5/0x87a [igb] phys=fade0000 ioremap
0xf8740000-0xf8761000 135168 igb_probe+0x1f5/0x87a [igb] phys=fad60000 ioremap
0xf8762000-0xf8767000 20480 module_alloc+0x72/0x80 pages=4 vmalloc
0xf8768000-0xf876b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf876c000-0xf876f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8770000-0xf8773000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8774000-0xf8777000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8778000-0xf877b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf877c000-0xf877f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8780000-0xf8783000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8784000-0xf8787000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8788000-0xf878b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf878c000-0xf878f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8790000-0xf8793000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8793000-0xf87a4000 69632 module_alloc+0x72/0x80 pages=16 vmalloc
0xf87a5000-0xf87a8000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf87aa000-0xf87e7000 249856 module_alloc+0x72/0x80 pages=60 vmalloc
0xf87f4000-0xf87f7000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf87f8000-0xf87fb000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf87fe000-0xf8877000 495616 module_alloc+0x72/0x80 pages=120 vmalloc
0xf8878000-0xf887b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf887c000-0xf887f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8880000-0xf8883000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8884000-0xf8887000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8888000-0xf888b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf888c000-0xf888f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8890000-0xf8893000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8894000-0xf8897000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf8898000-0xf889b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf889c000-0xf889f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf88a0000-0xf88a3000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf88a4000-0xf88a7000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf88a8000-0xf88ab000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf88ac000-0xf88af000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xf88af000-0xf88d5000 155648 module_alloc+0x72/0x80 pages=37 vmalloc
0xf8a65000-0xf8a67000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfa026000-0xfa028000 8192 acpi_os_map_memory+0x16/0x1f phys=df79e000 ioremap
0xfa02a000-0xfa02c000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
0xfa03a000-0xfa03c000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
0xfa03e000-0xfa040000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
0xfa042000-0xfa044000 8192 acpi_os_map_memory+0x16/0x1f phys=df79e000 ioremap
0xfa046000-0xfa048000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
0xfa04a000-0xfa04c000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
0xfa04e000-0xfa050000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
0xfa052000-0xfa054000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
0xfa056000-0xfa058000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
0xfa05e000-0xfa060000 8192 acpi_os_map_memory+0x16/0x1f phys=fed1f000 ioremap
0xfa06e000-0xfa070000 8192 usb_hcd_pci_probe+0x17b/0x350 phys=fa4de000 ioremap
0xfa072000-0xfa074000 8192 usb_hcd_pci_probe+0x17b/0x350 phys=fa4dc000 ioremap
0xfa78c000-0xfa79d000 69632 module_alloc+0x72/0x80 pages=16 vmalloc
0xfa805000-0xfa84a000 282624 module_alloc+0x72/0x80 pages=68 vmalloc
0xfc000000-0xfc400000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfc400000-0xfc800000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfc93f000-0xfc941000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfc94b000-0xfc94e000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xfc95e000-0xfc964000 24576 module_alloc+0x72/0x80 pages=5 vmalloc
0xfc96f000-0xfc972000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xfcdcc000-0xfcddf000 77824 module_alloc+0x72/0x80 pages=18 vmalloc
0xfce11000-0xfce14000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
0xfce15000-0xfce18000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
0xfce19000-0xfce1c000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
0xfce21000-0xfce23000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfce2a000-0xfce2c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfce30000-0xfce33000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
0xfce34000-0xfce37000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
0xfce38000-0xfce3b000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
0xfd0e7000-0xfd0ea000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd0eb000-0xfd0ee000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd0ef000-0xfd0f2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd0f3000-0xfd0f6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd0f7000-0xfd0fa000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd0fb000-0xfd0fe000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd0ff000-0xfd102000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd103000-0xfd106000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd107000-0xfd10a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd10b000-0xfd10e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd10f000-0xfd112000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd113000-0xfd116000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd117000-0xfd11a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd11b000-0xfd11e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd11f000-0xfd122000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd123000-0xfd126000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd127000-0xfd12a000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd12b000-0xfd12e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd12f000-0xfd132000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd133000-0xfd136000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd137000-0xfd13a000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd13b000-0xfd13e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd13f000-0xfd142000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd143000-0xfd146000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd147000-0xfd14a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd14b000-0xfd14e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd14f000-0xfd152000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd153000-0xfd156000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd157000-0xfd15a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd15b000-0xfd15e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd15f000-0xfd162000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd163000-0xfd166000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
0xfd1b2000-0xfd1b6000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
0xfd1bf000-0xfd1c1000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd1cb000-0xfd1ce000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
0xfd1d5000-0xfd1d7000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd1de000-0xfd1e0000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd1e8000-0xfd1ea000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd1f2000-0xfd1f4000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd1fb000-0xfd1fd000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd205000-0xfd207000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd20f000-0xfd211000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd219000-0xfd21b000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd223000-0xfd225000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd22d000-0xfd22f000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd23a000-0xfd23c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
0xfd248000-0xfd24c000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
0xfd400000-0xfd800000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfd800000-0xfdc00000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfdc00000-0xfe000000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfe000000-0xfe400000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfe400000-0xfe800000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfe800000-0xfec00000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xfec00000-0xff000000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
0xff000000-0xff400000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Eric Dumazet @ 2010-11-05 18:20 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <20101105110828.52f061b3.akpm@linux-foundation.org>
Le vendredi 05 novembre 2010 à 11:08 -0700, Andrew Morton a écrit :
> On Fri, 05 Nov 2010 19:00:46 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Le vendredi 05 novembre 2010 __ 10:20 -0700, Andrew Morton a __crit :
> >
> > > It totally makes sense to add include/linu/atomic.h for common things.
> > > Perhaps there's already code in arch/*/include/asm/atomic.h which
> > > should be hoisted up there. But that can't reliably be done until a
> > > million files have had their #includes switched :(
> > >
> >
> > Maybe including <linux/atomic.h> only from the end of various
> >
> > arch/*/include/asm/atomic.h ?
>
> heh, I guess that would work. It breaks the standard way of doing
> these things (I think?) so let's not go there unless we have a need?
>
> > In this case, I remove the include <asm/atomic.h> from linux/atomic.h
>
> Oh. Why? I thought it was better the previous, standard way: thou
> shalt henceforth include liunx/atomic.h, not asm/atomic.h. And the
> presence of linux/atomic.h will in fact trigger the checkpatch warning
> telling people to use that when they try to use asm/atomic.h.
Hmm, if we want to move the common stuff from
arch/*/include/asm/atomic.h to this new file (include/linux/atomic.h),
then we would have to change hundred of
#include <asm/atomic.h>
to
#include <linux/atomic.h>
This seems a big task to me ?
Or just make a whole tree replace ?
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Andrew Morton @ 2010-11-05 18:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <1288981224.2882.1105.camel@edumazet-laptop>
On Fri, 05 Nov 2010 19:20:24 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 05 novembre 2010 __ 11:08 -0700, Andrew Morton a __crit :
> > On Fri, 05 Nov 2010 19:00:46 +0100
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > > Le vendredi 05 novembre 2010 __ 10:20 -0700, Andrew Morton a __crit :
> > >
> > > > It totally makes sense to add include/linu/atomic.h for common things.
> > > > Perhaps there's already code in arch/*/include/asm/atomic.h which
> > > > should be hoisted up there. But that can't reliably be done until a
> > > > million files have had their #includes switched :(
> > > >
> > >
> > > Maybe including <linux/atomic.h> only from the end of various
> > >
> > > arch/*/include/asm/atomic.h ?
> >
> > heh, I guess that would work. It breaks the standard way of doing
> > these things (I think?) so let's not go there unless we have a need?
> >
> > > In this case, I remove the include <asm/atomic.h> from linux/atomic.h
> >
> > Oh. Why? I thought it was better the previous, standard way: thou
> > shalt henceforth include liunx/atomic.h, not asm/atomic.h. And the
> > presence of linux/atomic.h will in fact trigger the checkpatch warning
> > telling people to use that when they try to use asm/atomic.h.
>
> Hmm, if we want to move the common stuff from
> arch/*/include/asm/atomic.h to this new file (include/linux/atomic.h),
> then we would have to change hundred of
>
> #include <asm/atomic.h>
>
> to
>
> #include <linux/atomic.h>
>
> This seems a big task to me ?
>
> Or just make a whole tree replace ?
>
But we haven't established that there _is_ duplicated code which needs
that treatment.
Scanning arch/x86/include/asm/atomic.h, perhaps ATOMIC_INIT() is a
candidate. But I'm not sure that it _should_ be hoisted up - if every
architecture happens to do it the same way then that's just a fluke.
^ permalink raw reply
* Re: [PATCH] via-rhine: hardware VLAN support
From: Jesse Gross @ 2010-11-05 18:31 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev, David S. Miller
In-Reply-To: <20101105104303.GA8325@core.hellgate.ch>
On Fri, Nov 5, 2010 at 3:43 AM, Roger Luethi <rl@hellgate.ch> wrote:
> This patch adds VLAN hardware support for Rhine chips.
>
> The driver uses up to 3 additional bytes of buffer space when extracting
> 802.1Q headers; PKT_BUF_SZ should still be sufficient.
>
> The initial code was provided by David Lv. I reworked it to use standard
> kernel facilities. Coding style clean up mostly follows via-velocity.
This uses the old interfaces for vlan acceleration. We're working to
switch drivers over to use the new methods and the old ones will be
going away in the future. It would be great if we can avoid adding
more code that uses those interfaces.
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Paul E. McKenney @ 2010-11-05 18:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Morton, linux-kernel, David Miller, netdev,
Arnaldo Carvalho de Melo, Christoph Lameter, Ingo Molnar,
Andi Kleen, Nick Piggin
In-Reply-To: <1288980046.2882.1054.camel@edumazet-laptop>
On Fri, Nov 05, 2010 at 07:00:46PM +0100, Eric Dumazet wrote:
> Le vendredi 05 novembre 2010 à 10:20 -0700, Andrew Morton a écrit :
>
> > It totally makes sense to add include/linu/atomic.h for common things.
> > Perhaps there's already code in arch/*/include/asm/atomic.h which
> > should be hoisted up there. But that can't reliably be done until a
> > million files have had their #includes switched :(
> >
>
> Maybe including <linux/atomic.h> only from the end of various
>
> arch/*/include/asm/atomic.h ?
>
> In this case, I remove the include <asm/atomic.h> from linux/atomic.h
>
> > It's quite unobvious *why* `hint' cannot be zero. Can you please add
> > the reasoning to the comment? Also, the local `hint' should be
> > referred to as "@hint" in a kerneldoc comment.
>
> Well ;)
>
> We want to increment the counter if its not zero.
> Typically used for refcounts, of RCU protected structures.
>
> Giving a zero hint would be curious dont you think ?
>
> I see no usage for this, and using atomic_inc_not_zero() in this case is
> the only choice, since we dont ever want to cmpxchg(v, 0, 1) (or risk
> double free and crazy things)
>
> Hmm... maybe I can add a test (compiler should optimize it anyway, since
> all usages I can foresee will use a constant hint)
>
> >
> > > +static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
> > > +{
> > > + int val, c = hint;
> > > +
> > > + do {
> > > + val = atomic_cmpxchg(v, c, c + 1);
> > > + if (val == c)
> > > + return 1;
> > > + c = val;
> > > + } while (c);
> > > +
> > > + return 0;
> > > +}
> >
> > Should/could this have implemented a more general
> > atomic_add_not_zero_hint() and made atomic_inc_not_zero_hint() a
> > wrapper around that?
>
> Well, I see no practical use for this, but yes, this could be done.
>
> As atomic_add_not_zero() doesnt exist, I am not sure we need an
> atomic_add_not_zero_hint() yet ?
>
> >
> > Also, it might make sense to add "#ifndef atomic_inc_not_zero_hint"
> > wrappers around this function so that the arch can implement an
> > overriding custom version. And that becomes a general rule as more
> > functions are added to include/linux/atomic.h.
>
> Ah yes, thats right !
>
> Thanks !
>
> [PATCH v2] atomic: add atomic_inc_not_zero_hint()
>
> Followup of perf tools session in Netfilter WorkShop 2010
>
> In network stack we make high usage of atomic_inc_not_zero() in contexts
> we know the probable value of atomic before increment (2 for udp sockets
> for example)
>
> Using a special version of atomic_inc_not_zero() giving this hint can
> help processor to use less bus transactions.
>
> On x86 (MESI protocol) for example, this avoids entering Shared state,
> because "lock cmpxchg" issues an RFO (Read For Ownership)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Christoph Lameter <cl@linux-foundation.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
> Cc: David Miller <davem@davemloft.net>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Nick Piggin <npiggin@kernel.dk>
> ---
> V2: add #ifndef atomic_inc_not_zero_hint
> kerneldoc changes
> test that hint is not null
> Meant to be included at end of arch/*/asm/atomic.h files
>
> include/linux/atomic.h | 36 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 36 insertions(+)
>
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> new file mode 100644
> index 0000000..0897bdd
> --- /dev/null
> +++ b/include/linux/atomic.h
> @@ -0,0 +1,36 @@
> +#ifndef _LINUX_ATOMIC_H
> +#define _LINUX_ATOMIC_H
> +
> +/**
> + * atomic_inc_not_zero_hint - increment if not null
> + * @v: pointer of type atomic_t
> + * @hint: probable value of the atomic before the increment
> + *
> + * This version of atomic_inc_not_zero() gives a hint of probable
> + * value of the atomic. This helps processor to not read memory
> + * before doing the atomic read/modify/write cycle, lowering
> + * number of bus transactions on some arches.
> + * Note: @hint MUST not be 0, or increment is not done.
> + * Returns: 0 if increment was not done, 1 otherwise.
> + */
> +#ifndef atomic_inc_not_zero_hint
> +static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
> +{
> + int val, c = hint;
> +
> + /* sanity test, should be removed by compiler if hint is a constant */
> + if (!hint)
> + return 0;
OK, so I cannot resist the challenge... ;-)
Suppose that the atomic_inc_not_zero_hint() is in common code that might
be invoked from a cleanup path. On the cleanup path, perhaps within an
RCU callback, if the reference is zero, we have the only reference and
thus don't need to increment the reference count. On the other hand,
if the reference is non-zero, we want to obtain a reference in order
to safely attempt to encourage the other reference holder to let go
more quickly.
Perhaps a bit of a stretch, but why not just replace the above
"return 0" with "atomic_inc_not_zero(v)"? It will usually be
compiled out, right?
Thanx, Paul
> + do {
> + val = atomic_cmpxchg(v, c, c + 1);
> + if (val == c)
> + return 1;
> + c = val;
> + } while (c);
> +
> + return 0;
> +}
> +#endif
> +
> +#endif /* _LINUX_ATOMIC_H */
>
>
^ permalink raw reply
* [PATCH] Fix CAN info leak/minor heap overflow
From: Urs Thuermann @ 2010-11-05 18:33 UTC (permalink / raw)
To: netdev; +Cc: socketcan, oliver.hartkopp, Dan Rosenberg, security,
Linus Torvalds
In-Reply-To: <1288722503.2504.14.camel@dan>
This patch removes the leakage of kernel space addresses to userspace.
Instead, socket inode numbers are used to create unique proc file
names for CAN_BCM sockets and for referring to sockets in filter
lists. In addition, this makes debugging easier, since inode numbers
are also shown in ls -l /proc/<pid>/fd/<fd> and lsof(8) output.
BTW, if kernel space addresses are considered security critical
information one should also take a look and possibly change
/proc/net/{tcp,tcp6,udp,udp6,raw,raw6,unix}
and maybe some others.
The change of the procfs content leads to a new version string
20101105.
Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
CC: Dan Rosenberg <drosenberg@vsecurity.com>
CC: Linus Torvalds <torvalds@linux-foundation.org>
---
diff --git a/include/linux/can/core.h b/include/linux/can/core.h
index 6c507be..e20a841 100644
--- a/include/linux/can/core.h
+++ b/include/linux/can/core.h
@@ -19,7 +19,7 @@
#include <linux/skbuff.h>
#include <linux/netdevice.h>
-#define CAN_VERSION "20090105"
+#define CAN_VERSION "20101105"
/* increment this number each time you change some user-space interface */
#define CAN_ABI_VERSION "8"
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 08ffe9e..0e81e04 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -86,6 +86,12 @@ MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Oliver Hartkopp <oliver.hartkopp@volkswagen.de>");
MODULE_ALIAS("can-proto-2");
+/*
+ * Point to the sockets inode number inside the bcm ident string.
+ * We skip the string length of "bcm " (== 4) created in bcm_init().
+ */
+#define INODENUM(bo) (bo->ident + 4)
+
/* easy access to can_frame payload */
static inline u64 GET_U64(const struct can_frame *cp)
{
@@ -125,7 +131,7 @@ struct bcm_sock {
struct list_head tx_ops;
unsigned long dropped_usr_msgs;
struct proc_dir_entry *bcm_proc_read;
- char procname [9]; /* pointer printed in ASCII with \0 */
+ char ident[32];
};
static inline struct bcm_sock *bcm_sk(const struct sock *sk)
@@ -165,9 +171,7 @@ static int bcm_proc_show(struct seq_file *m, void *v)
struct bcm_sock *bo = bcm_sk(sk);
struct bcm_op *op;
- seq_printf(m, ">>> socket %p", sk->sk_socket);
- seq_printf(m, " / sk %p", sk);
- seq_printf(m, " / bo %p", bo);
+ seq_printf(m, ">>> socket inode %s", INODENUM(bo));
seq_printf(m, " / dropped %lu", bo->dropped_usr_msgs);
seq_printf(m, " / bound %s", bcm_proc_getifname(ifname, bo->ifindex));
seq_printf(m, " <<<\n");
@@ -1168,7 +1172,7 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
err = can_rx_register(dev, op->can_id,
REGMASK(op->can_id),
bcm_rx_handler, op,
- "bcm");
+ bo->ident);
op->rx_reg_dev = dev;
dev_put(dev);
@@ -1177,7 +1181,7 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
} else
err = can_rx_register(NULL, op->can_id,
REGMASK(op->can_id),
- bcm_rx_handler, op, "bcm");
+ bcm_rx_handler, op, bo->ident);
if (err) {
/* this bcm rx op is broken -> remove it */
list_del(&op->list);
@@ -1402,6 +1406,8 @@ static int bcm_init(struct sock *sk)
{
struct bcm_sock *bo = bcm_sk(sk);
+ snprintf(bo->ident, sizeof(bo->ident), "bcm %lu", sock_i_ino(sk));
+
bo->bound = 0;
bo->ifindex = 0;
bo->dropped_usr_msgs = 0;
@@ -1466,7 +1472,7 @@ static int bcm_release(struct socket *sock)
/* remove procfs entry */
if (proc_dir && bo->bcm_proc_read)
- remove_proc_entry(bo->procname, proc_dir);
+ remove_proc_entry(INODENUM(bo), proc_dir);
/* remove device reference */
if (bo->bound) {
@@ -1519,13 +1525,11 @@ static int bcm_connect(struct socket *sock, struct sockaddr *uaddr, int len,
bo->bound = 1;
- if (proc_dir) {
- /* unique socket address as filename */
- sprintf(bo->procname, "%p", sock);
- bo->bcm_proc_read = proc_create_data(bo->procname, 0644,
+ /* use unique socket inode number as filename */
+ if (proc_dir)
+ bo->bcm_proc_read = proc_create_data(INODENUM(bo), 0644,
proc_dir,
&bcm_proc_fops, sk);
- }
return 0;
}
diff --git a/net/can/proc.c b/net/can/proc.c
index f4265cc..15bed1c 100644
--- a/net/can/proc.c
+++ b/net/can/proc.c
@@ -204,23 +204,17 @@ static void can_print_rcvlist(struct seq_file *m, struct hlist_head *rx_list,
hlist_for_each_entry_rcu(r, n, rx_list, list) {
char *fmt = (r->can_id & CAN_EFF_FLAG)?
- " %-5s %08X %08x %08x %08x %8ld %s\n" :
- " %-5s %03X %08x %08lx %08lx %8ld %s\n";
+ " %-5s %08X %08x %8ld %s\n" :
+ " %-5s %03X %08x %8ld %s\n";
seq_printf(m, fmt, DNAME(dev), r->can_id, r->mask,
- (unsigned long)r->func, (unsigned long)r->data,
r->matches, r->ident);
}
}
static void can_print_recv_banner(struct seq_file *m)
{
- /*
- * can1. 00000000 00000000 00000000
- * ....... 0 tp20
- */
- seq_puts(m, " device can_id can_mask function"
- " userdata matches ident\n");
+ seq_puts(m, " device can_id can_mask matches ident\n");
}
static int can_stats_proc_show(struct seq_file *m, void *v)
diff --git a/net/can/raw.c b/net/can/raw.c
index e88f610..e057f0d 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -88,6 +88,7 @@ struct raw_sock {
struct can_filter dfilter; /* default/single filter */
struct can_filter *filter; /* pointer to filter(s) */
can_err_mask_t err_mask;
+ char ident[32];
};
/*
@@ -154,13 +155,14 @@ static void raw_rcv(struct sk_buff *oskb, void *data)
static int raw_enable_filters(struct net_device *dev, struct sock *sk,
struct can_filter *filter, int count)
{
+ struct raw_sock *ro = raw_sk(sk);
int err = 0;
int i;
for (i = 0; i < count; i++) {
err = can_rx_register(dev, filter[i].can_id,
filter[i].can_mask,
- raw_rcv, sk, "raw");
+ raw_rcv, sk, ro->ident);
if (err) {
/* clean up successfully registered filters */
while (--i >= 0)
@@ -177,11 +179,12 @@ static int raw_enable_filters(struct net_device *dev, struct sock *sk,
static int raw_enable_errfilter(struct net_device *dev, struct sock *sk,
can_err_mask_t err_mask)
{
+ struct raw_sock *ro = raw_sk(sk);
int err = 0;
if (err_mask)
err = can_rx_register(dev, 0, err_mask | CAN_ERR_FLAG,
- raw_rcv, sk, "raw");
+ raw_rcv, sk, ro->ident);
return err;
}
@@ -281,6 +284,8 @@ static int raw_init(struct sock *sk)
{
struct raw_sock *ro = raw_sk(sk);
+ snprintf(ro->ident, sizeof(ro->ident), "raw %lu", sock_i_ino(sk));
+
ro->bound = 0;
ro->ifindex = 0;
^ permalink raw reply related
* Re: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
From: Jeff Kirsher @ 2010-11-05 19:11 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Brandeburg, Jesse,
Duyck, Alexander H
In-Reply-To: <1288464591-31528-1-git-send-email-jesse@nicira.com>
[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]
On Sat, 2010-10-30 at 11:49 -0700, Jesse Gross wrote:
> On transmit, the ixgb driver will only use vlan acceleration if a
> vlan group is configured. This can lead to tags getting dropped
> when bridging because the networking core assumes that a driver
> that claims vlan acceleration support can do it at all times. This
> change should have been part of commit eab6d18d "vlan: Don't check for
> vlan group before vlan_tx_tag_present." but was missed.
>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> ---
> drivers/net/ixgb/ixgb_main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
> index caa8192..d18194e 100644
> --- a/drivers/net/ixgb/ixgb_main.c
> +++ b/drivers/net/ixgb/ixgb_main.c
> @@ -1498,7 +1498,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> DESC_NEEDED)))
> return NETDEV_TX_BUSY;
>
> - if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
> + if (vlan_tx_tag_present(skb)) {
> tx_flags |= IXGB_TX_FLAGS_VLAN;
> vlan_id = vlan_tx_tag_get(skb);
> }
After further review, NAK because this will cause a bug. With this
patch it would be possible to overrun the buffers, so the correct fix is
to increase max_frame_size by VLAN_TAG_SIZE in ixgb/igb_change_mtu.
Alex has said that he will generate the patches for the alternate fix.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Eric Dumazet @ 2010-11-05 19:12 UTC (permalink / raw)
To: paulmck
Cc: Andrew Morton, linux-kernel, David Miller, netdev,
Arnaldo Carvalho de Melo, Christoph Lameter, Ingo Molnar,
Andi Kleen, Nick Piggin
In-Reply-To: <20101105184034.GG2850@linux.vnet.ibm.com>
Le vendredi 05 novembre 2010 à 11:40 -0700, Paul E. McKenney a écrit :
> OK, so I cannot resist the challenge... ;-)
>
I knew that ;)
> Suppose that the atomic_inc_not_zero_hint() is in common code that might
> be invoked from a cleanup path. On the cleanup path, perhaps within an
> RCU callback, if the reference is zero, we have the only reference and
> thus don't need to increment the reference count. On the other hand,
> if the reference is non-zero, we want to obtain a reference in order
> to safely attempt to encourage the other reference holder to let go
> more quickly.
>
> Perhaps a bit of a stretch, but why not just replace the above
> "return 0" with "atomic_inc_not_zero(v)"? It will usually be
> compiled out, right?
Yes indeed, thanks !
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Eric Dumazet @ 2010-11-05 19:20 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <20101105112821.57f80481.akpm@linux-foundation.org>
Le vendredi 05 novembre 2010 à 11:28 -0700, Andrew Morton a écrit :
> But we haven't established that there _is_ duplicated code which needs
> that treatment.
>
> Scanning arch/x86/include/asm/atomic.h, perhaps ATOMIC_INIT() is a
> candidate. But I'm not sure that it _should_ be hoisted up - if every
> architecture happens to do it the same way then that's just a fluke.
>
>
Not sure I understand you. I was trying to avoid recursive includes, but
that should be protected anyway. I see a lot of code that could be
factorized in this new header (atomic_inc_not_zero() for example)
Thanks
[PATCH v3] atomic: add atomic_inc_not_zero_hint()
Followup of perf tools session in Netfilter WorkShop 2010
In network stack we make high usage of atomic_inc_not_zero() in contexts
we know the probable value of atomic before increment (2 for udp sockets
for example)
Using a special version of atomic_inc_not_zero() giving this hint can
help processor to use less bus transactions.
On x86 (MESI protocol) for example, this avoids entering Shared state,
because "lock cmpxchg" issues an RFO (Read For Ownership)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
---
V3: adds the include <asm/atomic.h>
if hint is null, use atomic_inc_not_zero() (Paul suggestion)
V2: add #ifndef atomic_inc_not_zero_hint
kerneldoc changes
test that hint is not null
Meant to be included at end of arch/*/asm/atomic.h files
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
new file mode 100644
index 0000000..5a7df87
--- /dev/null
+++ b/include/linux/atomic.h
@@ -0,0 +1,37 @@
+#ifndef _LINUX_ATOMIC_H
+#define _LINUX_ATOMIC_H
+#include <asm/atomic.h>
+
+/**
+ * atomic_inc_not_zero_hint - increment if not null
+ * @v: pointer of type atomic_t
+ * @hint: probable value of the atomic before the increment
+ *
+ * This version of atomic_inc_not_zero() gives a hint of probable
+ * value of the atomic. This helps processor to not read the memory
+ * before doing the atomic read/modify/write cycle, lowering
+ * number of bus transactions on some arches.
+ *
+ * Returns: 0 if increment was not done, 1 otherwise.
+ */
+#ifndef atomic_inc_not_zero_hint
+static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
+{
+ int val, c = hint;
+
+ /* sanity test, should be removed by compiler if hint is a constant */
+ if (!hint)
+ return atomic_inc_not_zero(v);
+
+ do {
+ val = atomic_cmpxchg(v, c, c + 1);
+ if (val == c)
+ return 1;
+ c = val;
+ } while (c);
+
+ return 0;
+}
+#endif
+
+#endif /* _LINUX_ATOMIC_H */
^ permalink raw reply related
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Andrew Morton @ 2010-11-05 19:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <1288984844.2665.52.camel@edumazet-laptop>
On Fri, 05 Nov 2010 20:20:44 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 05 novembre 2010 __ 11:28 -0700, Andrew Morton a __crit :
> > But we haven't established that there _is_ duplicated code which needs
> > that treatment.
> >
> > Scanning arch/x86/include/asm/atomic.h, perhaps ATOMIC_INIT() is a
> > candidate. But I'm not sure that it _should_ be hoisted up - if every
> > architecture happens to do it the same way then that's just a fluke.
> >
> >
>
> Not sure I understand you. I was trying to avoid recursive includes, but
> that should be protected anyway. I see a lot of code that could be
> factorized in this new header (atomic_inc_not_zero() for example)
Ah. I wasn't able to see much duplicated code at all, so I wasn't sure
that we needed to bother about this issue.
yup, atomic_inc_not_zero() looks like a candidate.
> [PATCH v3] atomic: add atomic_inc_not_zero_hint()
Let's go with this for now ;)
I'll assume that you intend to make use of this function soon, and it
looks safe enough to sneak it into 2.6.37-rc2, IMO. If Linus shouts at
me then we could merge it into 2.6.38-rc1 via net-next, but I think
straight-to-mainline is best.
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Eric Dumazet @ 2010-11-05 19:46 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, David Miller, netdev, Arnaldo Carvalho de Melo,
Christoph Lameter, Ingo Molnar, Andi Kleen, Paul E. McKenney,
Nick Piggin
In-Reply-To: <20101105123927.5779e464.akpm@linux-foundation.org>
Le vendredi 05 novembre 2010 à 12:39 -0700, Andrew Morton a écrit :
> Ah. I wasn't able to see much duplicated code at all, so I wasn't sure
> that we needed to bother about this issue.
>
> yup, atomic_inc_not_zero() looks like a candidate.
yes, and atomic_add_unless()...
>
> > [PATCH v3] atomic: add atomic_inc_not_zero_hint()
>
> Let's go with this for now ;)
>
> I'll assume that you intend to make use of this function soon, and it
> looks safe enough to sneak it into 2.6.37-rc2, IMO. If Linus shouts at
> me then we could merge it into 2.6.38-rc1 via net-next, but I think
> straight-to-mainline is best.
>
Well, I dont expect using it before 2.6.38, no hurry Andrew, but it
probably can be merged before, since it has no user yet. It'll help our
job for sure.
Thanks
^ permalink raw reply
* [PATCH] iputils build fix
From: Lucas C. Villa Real @ 2010-11-05 19:49 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 144 bytes --]
Hi,
Please find attached a patch which fixes the build of
iputils-s20101006 on platforms that don't have the SO_MARK operation.
Thanks,
Lucas
[-- Attachment #2: 01-iputils-SO_MARK.patch --]
[-- Type: application/octet-stream, Size: 857 bytes --]
Fixes build on platforms where SO_MARK is not defined.
Signed-off-by: Lucas C. Villa Real <lucasvr@us.ibm.com>
diff -urp iputils-s20101006.orig/ping_common.c iputils-s20101006/ping_common.c
--- iputils-s20101006.orig/ping_common.c 2010-10-06 08:59:20.000000000 -0300
+++ iputils-s20101006/ping_common.c 2010-11-05 16:08:06.000000000 -0200
@@ -475,6 +475,7 @@ void setup(int icmp_sock)
fprintf(stderr, "Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP\n");
}
#endif
+#ifdef SO_MARK
if (options & F_MARK) {
if (setsockopt(icmp_sock, SOL_SOCKET, SO_MARK,
&mark, sizeof(mark)) == -1) {
@@ -484,6 +485,7 @@ void setup(int icmp_sock)
fprintf(stderr, "Warning: Failed to set mark %d\n", mark);
}
}
+#endif
/* Set some SNDTIMEO to prevent blocking forever
* on sends, when device is too slow or stalls. Just put limit
^ permalink raw reply
* Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
From: Paul E. McKenney @ 2010-11-05 19:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Morton, linux-kernel, David Miller, netdev,
Arnaldo Carvalho de Melo, Christoph Lameter, Ingo Molnar,
Andi Kleen, Nick Piggin
In-Reply-To: <1288984844.2665.52.camel@edumazet-laptop>
On Fri, Nov 05, 2010 at 08:20:44PM +0100, Eric Dumazet wrote:
> Le vendredi 05 novembre 2010 à 11:28 -0700, Andrew Morton a écrit :
> > But we haven't established that there _is_ duplicated code which needs
> > that treatment.
> >
> > Scanning arch/x86/include/asm/atomic.h, perhaps ATOMIC_INIT() is a
> > candidate. But I'm not sure that it _should_ be hoisted up - if every
> > architecture happens to do it the same way then that's just a fluke.
> >
> >
>
> Not sure I understand you. I was trying to avoid recursive includes, but
> that should be protected anyway. I see a lot of code that could be
> factorized in this new header (atomic_inc_not_zero() for example)
>
> Thanks
>
> [PATCH v3] atomic: add atomic_inc_not_zero_hint()
>
> Followup of perf tools session in Netfilter WorkShop 2010
>
> In network stack we make high usage of atomic_inc_not_zero() in contexts
> we know the probable value of atomic before increment (2 for udp sockets
> for example)
>
> Using a special version of atomic_inc_not_zero() giving this hint can
> help processor to use less bus transactions.
>
> On x86 (MESI protocol) for example, this avoids entering Shared state,
> because "lock cmpxchg" issues an RFO (Read For Ownership)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Christoph Lameter <cl@linux-foundation.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
> Cc: David Miller <davem@davemloft.net>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Looks quite good to me!
Reviewed-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Nick Piggin <npiggin@kernel.dk>
> ---
> V3: adds the include <asm/atomic.h>
> if hint is null, use atomic_inc_not_zero() (Paul suggestion)
> V2: add #ifndef atomic_inc_not_zero_hint
> kerneldoc changes
> test that hint is not null
> Meant to be included at end of arch/*/asm/atomic.h files
>
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> new file mode 100644
> index 0000000..5a7df87
> --- /dev/null
> +++ b/include/linux/atomic.h
> @@ -0,0 +1,37 @@
> +#ifndef _LINUX_ATOMIC_H
> +#define _LINUX_ATOMIC_H
> +#include <asm/atomic.h>
> +
> +/**
> + * atomic_inc_not_zero_hint - increment if not null
> + * @v: pointer of type atomic_t
> + * @hint: probable value of the atomic before the increment
> + *
> + * This version of atomic_inc_not_zero() gives a hint of probable
> + * value of the atomic. This helps processor to not read the memory
> + * before doing the atomic read/modify/write cycle, lowering
> + * number of bus transactions on some arches.
> + *
> + * Returns: 0 if increment was not done, 1 otherwise.
> + */
> +#ifndef atomic_inc_not_zero_hint
> +static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
> +{
> + int val, c = hint;
> +
> + /* sanity test, should be removed by compiler if hint is a constant */
> + if (!hint)
> + return atomic_inc_not_zero(v);
> +
> + do {
> + val = atomic_cmpxchg(v, c, c + 1);
> + if (val == c)
> + return 1;
> + c = val;
> + } while (c);
> +
> + return 0;
> +}
> +#endif
> +
> +#endif /* _LINUX_ATOMIC_H */
>
>
^ permalink raw reply
* [PATCH] iputils signal mask issue
From: Lucas C. Villa Real @ 2010-11-05 19:56 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Hi,
Today we found an issue where arping would get stuck in an endless
loop. The problem was found to be related to the parent process (a
shell script) having had SIGALRM blocked, which is used by arping to
update "count" and to check the "timeout" global.
Since we cannot make assumptions on the signal masks of the
environment it's better to explicitly unblock the signals that the
utility needs before the main loop executes. It's worth noting that
although sigaction() is called to associate a handler to a given
signal, that function doesn't automatically unblock that signal.
A similar problem was noticed on rdisc, so the attached patch also
ensures to unblock the signals that it relies on.
Thanks,
Lucas
[-- Attachment #2: 02-iputils-SIG_UNBLOCK.patch --]
[-- Type: application/octet-stream, Size: 1499 bytes --]
Don't rely on the parent signal mask. If that process has blocked SIGALRM
then chances are high that arping and rdisc will execute forever, as that
signal will never be delivered and the globals, such as 'count' and 'timeout',
won't be updated or checked.
Signed-off-by: Lucas C. Villa Real <lucasvr@us.ibm.com>
diff -urp iputils-s20101006.orig/arping.c iputils-s20101006/arping.c
--- iputils-s20101006.orig/arping.c 2010-10-06 08:59:20.000000000 -0300
+++ iputils-s20101006/arping.c 2010-11-05 16:12:42.000000000 -0200
@@ -346,6 +346,7 @@ main(int argc, char **argv)
{
int socket_errno;
int ch;
+ sigset_t sset, osset;
uid_t uid = getuid();
s = socket(PF_PACKET, SOCK_DGRAM, 0);
@@ -544,13 +545,17 @@ main(int argc, char **argv)
exit(2);
}
+ sigemptyset(&sset);
+ sigaddset(&sset, SIGALRM);
+ sigaddset(&sset, SIGINT);
+ sigprocmask(SIG_UNBLOCK, &sset, NULL);
+
set_signal(SIGINT, finish);
set_signal(SIGALRM, catcher);
catcher();
while(1) {
- sigset_t sset, osset;
unsigned char packet[4096];
struct sockaddr_storage from;
socklen_t alen = sizeof(from);
diff -urp iputils-s20101006.orig/rdisc.c iputils-s20101006/rdisc.c
--- iputils-s20101006.orig/rdisc.c 2010-10-06 08:59:20.000000000 -0300
+++ iputils-s20101006/rdisc.c 2010-11-05 16:14:33.000000000 -0200
@@ -449,6 +449,7 @@ next:
sigaddset(&sset, SIGHUP);
sigaddset(&sset, SIGTERM);
sigaddset(&sset, SIGINT);
+ sigprocmask(SIG_UNBLOCK, &sset, NULL);
init();
if (join(s, &joinaddr) < 0) {
^ permalink raw reply
* Re: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
From: Jesse Gross @ 2010-11-05 19:56 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: David Miller, netdev@vger.kernel.org, Brandeburg, Jesse,
Duyck, Alexander H
In-Reply-To: <1288984304.3091.11.camel@jtkirshe-MOBL1>
On Fri, Nov 5, 2010 at 12:11 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> On Sat, 2010-10-30 at 11:49 -0700, Jesse Gross wrote:
>> On transmit, the ixgb driver will only use vlan acceleration if a
>> vlan group is configured. This can lead to tags getting dropped
>> when bridging because the networking core assumes that a driver
>> that claims vlan acceleration support can do it at all times. This
>> change should have been part of commit eab6d18d "vlan: Don't check for
>> vlan group before vlan_tx_tag_present." but was missed.
>>
>> Signed-off-by: Jesse Gross <jesse@nicira.com>
>> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>> ---
>> drivers/net/ixgb/ixgb_main.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
>> index caa8192..d18194e 100644
>> --- a/drivers/net/ixgb/ixgb_main.c
>> +++ b/drivers/net/ixgb/ixgb_main.c
>> @@ -1498,7 +1498,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
>> DESC_NEEDED)))
>> return NETDEV_TX_BUSY;
>>
>> - if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
>> + if (vlan_tx_tag_present(skb)) {
>> tx_flags |= IXGB_TX_FLAGS_VLAN;
>> vlan_id = vlan_tx_tag_get(skb);
>> }
>
> After further review, NAK because this will cause a bug. With this
> patch it would be possible to overrun the buffers, so the correct fix is
> to increase max_frame_size by VLAN_TAG_SIZE in ixgb/igb_change_mtu.
Hmm, I didn't see any other place where it made changes to the
handling of packets on transmit if a vlan group is configured. Maybe
the buffer is extended when a group is registered and stripping is
enabled?
In any case, you might want to check the other Intel drivers for
similar problems. I did a pass and made a mass conversion of this
type a little while ago. Those changes have already been merged, I
just missed this one by accident.
^ permalink raw reply
* Re: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
From: Jeff Kirsher @ 2010-11-05 20:06 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Brandeburg, Jesse,
Duyck, Alexander H
In-Reply-To: <AANLkTin62WWL+cnLVNaOYmcvL28rfkUDVCVqiimSPZ=e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]
On Fri, 2010-11-05 at 12:56 -0700, Jesse Gross wrote:
> On Fri, Nov 5, 2010 at 12:11 PM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > On Sat, 2010-10-30 at 11:49 -0700, Jesse Gross wrote:
> >> On transmit, the ixgb driver will only use vlan acceleration if a
> >> vlan group is configured. This can lead to tags getting dropped
> >> when bridging because the networking core assumes that a driver
> >> that claims vlan acceleration support can do it at all times. This
> >> change should have been part of commit eab6d18d "vlan: Don't check for
> >> vlan group before vlan_tx_tag_present." but was missed.
> >>
> >> Signed-off-by: Jesse Gross <jesse@nicira.com>
> >> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> >> CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> >> ---
> >> drivers/net/ixgb/ixgb_main.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
> >> index caa8192..d18194e 100644
> >> --- a/drivers/net/ixgb/ixgb_main.c
> >> +++ b/drivers/net/ixgb/ixgb_main.c
> >> @@ -1498,7 +1498,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> >> DESC_NEEDED)))
> >> return NETDEV_TX_BUSY;
> >>
> >> - if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
> >> + if (vlan_tx_tag_present(skb)) {
> >> tx_flags |= IXGB_TX_FLAGS_VLAN;
> >> vlan_id = vlan_tx_tag_get(skb);
> >> }
> >
> > After further review, NAK because this will cause a bug. With this
> > patch it would be possible to overrun the buffers, so the correct fix is
> > to increase max_frame_size by VLAN_TAG_SIZE in ixgb/igb_change_mtu.
>
> Hmm, I didn't see any other place where it made changes to the
> handling of packets on transmit if a vlan group is configured. Maybe
> the buffer is extended when a group is registered and stripping is
> enabled?
>
> In any case, you might want to check the other Intel drivers for
> similar problems. I did a pass and made a mass conversion of this
> type a little while ago. Those changes have already been merged, I
> just missed this one by accident.
I will get with Alex and review the other Intel drivers, thanks Jesse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-05 20:20 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, linux-kernel, Tejun Heo
In-Reply-To: <4CD449A5.5070305@candelatech.com>
Le vendredi 05 novembre 2010 à 11:15 -0700, Ben Greear a écrit :
> root@lanforge-ubuntu:/home/lanforge# cat /proc/vmallocinfo
> 0xf7ffe000-0xf8000000 8192 hpet_enable+0x2d/0x1b8 phys=fed00000 ioremap
> 0xf8002000-0xf8004000 8192 acpi_os_map_memory+0x16/0x1f phys=df79e000 ioremap
> 0xf8004000-0xf8007000 12288 acpi_os_map_memory+0x16/0x1f phys=df7a0000 ioremap
> 0xf8008000-0xf800a000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
> 0xf800b000-0xf8010000 20480 module_alloc+0x72/0x80 pages=4 vmalloc
> 0xf8010000-0xf8019000 36864 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
> 0xf801a000-0xf801c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf801d000-0xf8020000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8023000-0xf8026000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xf8026000-0xf8028000 8192 msix_capability_init+0xae/0x2b0 phys=fa4fe000 ioremap
> 0xf8028000-0xf802a000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf802b000-0xf802e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf802f000-0xf8032000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8033000-0xf8036000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8037000-0xf803a000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf803b000-0xf803e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf803f000-0xf8048000 36864 module_alloc+0x72/0x80 pages=8 vmalloc
> 0xf804b000-0xf8055000 40960 module_alloc+0x72/0x80 pages=9 vmalloc
> 0xf8056000-0xf8059000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf805b000-0xf8063000 32768 module_alloc+0x72/0x80 pages=7 vmalloc
> 0xf8066000-0xf8068000 8192 msix_capability_init+0xae/0x2b0 phys=fa4fa000 ioremap
> 0xf8068000-0xf8070000 32768 module_alloc+0x72/0x80 pages=7 vmalloc
> 0xf8072000-0xf8075000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xf8076000-0xf8083000 53248 module_alloc+0x72/0x80 pages=12 vmalloc
> 0xf8084000-0xf8087000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8088000-0xf808b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf808c000-0xf808f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8090000-0xf8093000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8094000-0xf8097000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8098000-0xf809b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf809c000-0xf809f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80a2000-0xf80ad000 45056 module_alloc+0x72/0x80 pages=10 vmalloc
> 0xf80ae000-0xf80b2000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
> 0xf80b3000-0xf80b6000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80b7000-0xf80ba000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80bb000-0xf80be000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80bf000-0xf80c2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80c3000-0xf80c6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80c8000-0xf80cd000 20480 pci_iomap+0x81/0x90 phys=fa4fc000 ioremap
> 0xf80ce000-0xf80d1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80d2000-0xf80d5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80d6000-0xf80d9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80da000-0xf80dd000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80de000-0xf80e1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80e2000-0xf80e5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80e6000-0xf80e9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80ea000-0xf80ed000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80ee000-0xf80f1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80f2000-0xf80f5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80f6000-0xf80f9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80fa000-0xf80fd000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf80fe000-0xf8101000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8102000-0xf8105000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8106000-0xf8109000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf810a000-0xf810d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf810d000-0xf8118000 45056 module_alloc+0x72/0x80 pages=10 vmalloc
> 0xf8119000-0xf811c000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf811d000-0xf8120000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8121000-0xf8124000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8125000-0xf8128000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8129000-0xf812c000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf812d000-0xf8130000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8130000-0xf8132000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf8133000-0xf8136000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xf8137000-0xf813a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf813e000-0xf8140000 8192 msix_capability_init+0xae/0x2b0 phys=fa4f6000 ioremap
> 0xf8140000-0xf8145000 20480 pci_iomap+0x81/0x90 phys=fa4f8000 ioremap
> 0xf8146000-0xf8148000 8192 msix_capability_init+0xae/0x2b0 phys=fa4f2000 ioremap
> 0xf8148000-0xf814d000 20480 pci_iomap+0x81/0x90 phys=fa4f4000 ioremap
> 0xf814e000-0xf8150000 8192 msix_capability_init+0xae/0x2b0 phys=fa4ee000 ioremap
> 0xf8150000-0xf8155000 20480 pci_iomap+0x81/0x90 phys=fa4f0000 ioremap
> 0xf8156000-0xf8158000 8192 msix_capability_init+0xae/0x2b0 phys=fa4ea000 ioremap
> 0xf8158000-0xf815d000 20480 pci_iomap+0x81/0x90 phys=fa4ec000 ioremap
> 0xf815e000-0xf8160000 8192 msix_capability_init+0xae/0x2b0 phys=fa4e6000 ioremap
> 0xf8160000-0xf8165000 20480 pci_iomap+0x81/0x90 phys=fa4e8000 ioremap
> 0xf8166000-0xf8168000 8192 msix_capability_init+0xae/0x2b0 phys=fa4e2000 ioremap
> 0xf8168000-0xf816d000 20480 pci_iomap+0x81/0x90 phys=fa4e4000 ioremap
> 0xf816e000-0xf8170000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf8170000-0xf8175000 20480 pci_iomap+0x81/0x90 phys=fa4e0000 ioremap
> 0xf8176000-0xf8179000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf817a000-0xf817d000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf817e000-0xf8181000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8182000-0xf8185000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8186000-0xf8189000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf818e000-0xf819d000 61440 module_alloc+0x72/0x80 pages=14 vmalloc
> 0xf819e000-0xf81a1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81a2000-0xf81a5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81a6000-0xf81a9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81aa000-0xf81ad000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81ae000-0xf81b1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81b2000-0xf81b5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81b6000-0xf81b9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81ba000-0xf81bd000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81be000-0xf81c1000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81c2000-0xf81c5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf81fe000-0xf8201000 12288 e1000e_setup_tx_resources+0x27/0xb0 [e1000e] pages=2 vmalloc
> 0xf8202000-0xf8205000 12288 e1000e_setup_rx_resources+0x2a/0x120 [e1000e] pages=2 vmalloc
> 0xf8206000-0xf8209000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf820c000-0xf820f000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xf8210000-0xf8213000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8214000-0xf8217000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8218000-0xf821c000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
> 0xf8225000-0xf8228000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8229000-0xf822b000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf82ab000-0xf82ae000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82af000-0xf82b2000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82b3000-0xf82b6000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82b7000-0xf82ba000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82bb000-0xf82be000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82bf000-0xf82c2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82c3000-0xf82c6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82c7000-0xf82ca000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82cb000-0xf82ce000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82cf000-0xf82d2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82d3000-0xf82d6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82d7000-0xf82da000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82db000-0xf82de000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82df000-0xf82e2000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82e3000-0xf82e6000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82e7000-0xf82ea000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82eb000-0xf82ee000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf82ef000-0xf82f2000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8332000-0xf8363000 200704 module_alloc+0x72/0x80 pages=48 vmalloc
> 0xf8364000-0xf8367000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8368000-0xf836b000 12288 e1000e_setup_tx_resources+0x27/0xb0 [e1000e] pages=2 vmalloc
> 0xf836c000-0xf836f000 12288 e1000e_setup_rx_resources+0x2a/0x120 [e1000e] pages=2 vmalloc
> 0xf8370000-0xf8373000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8374000-0xf8377000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8378000-0xf837b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf837c000-0xf837f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf837f000-0xf83a0000 135168 module_alloc+0x72/0x80 pages=32 vmalloc
> 0xf83a1000-0xf83a4000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf83a5000-0xf83a8000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf83a9000-0xf83ac000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf83ad000-0xf83b0000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf83b0000-0xf83ba000 40960 module_alloc+0x72/0x80 pages=9 vmalloc
> 0xf83bb000-0xf83bd000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf83be000-0xf83c1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf83cc000-0xf83e5000 102400 module_alloc+0x72/0x80 pages=24 vmalloc
> 0xf83ec000-0xf83ee000 8192 msix_capability_init+0xae/0x2b0 phys=faedc000 ioremap
> 0xf83f0000-0xf83f2000 8192 msix_capability_init+0xae/0x2b0 phys=fa69c000 ioremap
> 0xf83fa000-0xf83fc000 8192 msix_capability_init+0xae/0x2b0 phys=fafdc000 ioremap
> 0xf83fe000-0xf8400000 8192 msix_capability_init+0xae/0x2b0 phys=fa698000 ioremap
> 0xf8400000-0xf8421000 135168 e1000_probe+0x206/0x9d0 [e1000e] phys=faee0000 ioremap
> 0xf8422000-0xf8424000 8192 msix_capability_init+0xae/0x2b0 phys=fa79c000 ioremap
> 0xf8426000-0xf8428000 8192 msix_capability_init+0xae/0x2b0 phys=fa798000 ioremap
> 0xf842a000-0xf842c000 8192 msix_capability_init+0xae/0x2b0 phys=fa99c000 ioremap
> 0xf842e000-0xf8430000 8192 msix_capability_init+0xae/0x2b0 phys=fa998000 ioremap
> 0xf8432000-0xf8434000 8192 msix_capability_init+0xae/0x2b0 phys=faa9c000 ioremap
> 0xf8436000-0xf8438000 8192 msix_capability_init+0xae/0x2b0 phys=faa98000 ioremap
> 0xf843a000-0xf843c000 8192 msix_capability_init+0xae/0x2b0 phys=fac9c000 ioremap
> 0xf843e000-0xf8440000 8192 msix_capability_init+0xae/0x2b0 phys=fac98000 ioremap
> 0xf8440000-0xf8461000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa6e0000 ioremap
> 0xf8462000-0xf8464000 8192 msix_capability_init+0xae/0x2b0 phys=fad9c000 ioremap
> 0xf8466000-0xf8468000 8192 msix_capability_init+0xae/0x2b0 phys=fad98000 ioremap
> 0xf846c000-0xf846e000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf8476000-0xf8478000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf8480000-0xf84a1000 135168 e1000_probe+0x206/0x9d0 [e1000e] phys=fafe0000 ioremap
> 0xf84a9000-0xf84af000 24576 module_alloc+0x72/0x80 pages=5 vmalloc
> 0xf84bc000-0xf84bf000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf84c0000-0xf84e1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa660000 ioremap
> 0xf84e2000-0xf84e5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf84e6000-0xf84e9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf84ea000-0xf84ed000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf84ee000-0xf84f1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf84f2000-0xf84f5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf84f6000-0xf84f9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf84fb000-0xf84ff000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
> 0xf8500000-0xf8521000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa7e0000 ioremap
> 0xf8522000-0xf852f000 53248 module_alloc+0x72/0x80 pages=12 vmalloc
> 0xf8530000-0xf8533000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8534000-0xf8537000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8538000-0xf853b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf853c000-0xf853f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8540000-0xf8561000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa760000 ioremap
> 0xf8562000-0xf8565000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xf8566000-0xf8569000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf856a000-0xf856c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xf856d000-0xf8570000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8571000-0xf8574000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8575000-0xf8578000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8579000-0xf857c000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf857d000-0xf857f000 8192 swap_cgroup_swapon+0x3c/0x140 pages=1 vmalloc
> 0xf8580000-0xf85a1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa9e0000 ioremap
> 0xf85a2000-0xf85a5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf85a6000-0xf85a9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf85aa000-0xf85ad000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf85af000-0xf85b7000 32768 module_alloc+0x72/0x80 pages=7 vmalloc
> 0xf85b8000-0xf85bb000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf85bc000-0xf85bf000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf85c0000-0xf85e1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fa960000 ioremap
> 0xf85e2000-0xf85ed000 45056 sys_swapon+0x5a6/0xa40 pages=10 vmalloc
> 0xf85ee000-0xf8600000 73728 module_alloc+0x72/0x80 pages=17 vmalloc
> 0xf8600000-0xf8621000 135168 igb_probe+0x1f5/0x87a [igb] phys=faae0000 ioremap
> 0xf8622000-0xf8625000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8626000-0xf8629000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf862a000-0xf862d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf862e000-0xf8631000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8632000-0xf8635000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8636000-0xf8639000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf863a000-0xf863d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8640000-0xf8661000 135168 igb_probe+0x1f5/0x87a [igb] phys=faa60000 ioremap
> 0xf8662000-0xf8665000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8666000-0xf8669000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf866a000-0xf866d000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf866e000-0xf8671000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8672000-0xf8675000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8676000-0xf8679000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf867a000-0xf867d000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8680000-0xf86a1000 135168 igb_probe+0x1f5/0x87a [igb] phys=face0000 ioremap
> 0xf86a2000-0xf86a5000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf86a6000-0xf86a9000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf86aa000-0xf86ad000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf86ae000-0xf86b1000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf86b2000-0xf86b5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf86b6000-0xf86b9000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf86ba000-0xf86bd000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf86c0000-0xf86e1000 135168 igb_probe+0x1f5/0x87a [igb] phys=fac60000 ioremap
> 0xf86e2000-0xf86e5000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8700000-0xf8721000 135168 igb_probe+0x1f5/0x87a [igb] phys=fade0000 ioremap
> 0xf8740000-0xf8761000 135168 igb_probe+0x1f5/0x87a [igb] phys=fad60000 ioremap
> 0xf8762000-0xf8767000 20480 module_alloc+0x72/0x80 pages=4 vmalloc
> 0xf8768000-0xf876b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf876c000-0xf876f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8770000-0xf8773000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8774000-0xf8777000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8778000-0xf877b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf877c000-0xf877f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8780000-0xf8783000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8784000-0xf8787000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8788000-0xf878b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf878c000-0xf878f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8790000-0xf8793000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8793000-0xf87a4000 69632 module_alloc+0x72/0x80 pages=16 vmalloc
> 0xf87a5000-0xf87a8000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf87aa000-0xf87e7000 249856 module_alloc+0x72/0x80 pages=60 vmalloc
> 0xf87f4000-0xf87f7000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf87f8000-0xf87fb000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf87fe000-0xf8877000 495616 module_alloc+0x72/0x80 pages=120 vmalloc
> 0xf8878000-0xf887b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf887c000-0xf887f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8880000-0xf8883000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8884000-0xf8887000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8888000-0xf888b000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf888c000-0xf888f000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8890000-0xf8893000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8894000-0xf8897000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf8898000-0xf889b000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf889c000-0xf889f000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf88a0000-0xf88a3000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf88a4000-0xf88a7000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf88a8000-0xf88ab000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf88ac000-0xf88af000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xf88af000-0xf88d5000 155648 module_alloc+0x72/0x80 pages=37 vmalloc
> 0xf8a65000-0xf8a67000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfa026000-0xfa028000 8192 acpi_os_map_memory+0x16/0x1f phys=df79e000 ioremap
> 0xfa02a000-0xfa02c000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
> 0xfa03a000-0xfa03c000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
> 0xfa03e000-0xfa040000 8192 acpi_os_map_memory+0x16/0x1f phys=df790000 ioremap
> 0xfa042000-0xfa044000 8192 acpi_os_map_memory+0x16/0x1f phys=df79e000 ioremap
> 0xfa046000-0xfa048000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
> 0xfa04a000-0xfa04c000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
> 0xfa04e000-0xfa050000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
> 0xfa052000-0xfa054000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
> 0xfa056000-0xfa058000 8192 acpi_os_map_memory+0x16/0x1f phys=df79a000 ioremap
> 0xfa05e000-0xfa060000 8192 acpi_os_map_memory+0x16/0x1f phys=fed1f000 ioremap
> 0xfa06e000-0xfa070000 8192 usb_hcd_pci_probe+0x17b/0x350 phys=fa4de000 ioremap
> 0xfa072000-0xfa074000 8192 usb_hcd_pci_probe+0x17b/0x350 phys=fa4dc000 ioremap
> 0xfa78c000-0xfa79d000 69632 module_alloc+0x72/0x80 pages=16 vmalloc
> 0xfa805000-0xfa84a000 282624 module_alloc+0x72/0x80 pages=68 vmalloc
> 0xfc000000-0xfc400000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfc400000-0xfc800000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfc93f000-0xfc941000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfc94b000-0xfc94e000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xfc95e000-0xfc964000 24576 module_alloc+0x72/0x80 pages=5 vmalloc
> 0xfc96f000-0xfc972000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xfcdcc000-0xfcddf000 77824 module_alloc+0x72/0x80 pages=18 vmalloc
> 0xfce11000-0xfce14000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
> 0xfce15000-0xfce18000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
> 0xfce19000-0xfce1c000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
> 0xfce21000-0xfce23000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfce2a000-0xfce2c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfce30000-0xfce33000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
> 0xfce34000-0xfce37000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
> 0xfce38000-0xfce3b000 12288 reqsk_queue_alloc+0x54/0xd0 pages=2 vmalloc
> 0xfd0e7000-0xfd0ea000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd0eb000-0xfd0ee000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd0ef000-0xfd0f2000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd0f3000-0xfd0f6000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd0f7000-0xfd0fa000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd0fb000-0xfd0fe000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd0ff000-0xfd102000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd103000-0xfd106000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd107000-0xfd10a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd10b000-0xfd10e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd10f000-0xfd112000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd113000-0xfd116000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd117000-0xfd11a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd11b000-0xfd11e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd11f000-0xfd122000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd123000-0xfd126000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd127000-0xfd12a000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd12b000-0xfd12e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd12f000-0xfd132000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd133000-0xfd136000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd137000-0xfd13a000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd13b000-0xfd13e000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd13f000-0xfd142000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd143000-0xfd146000 12288 igb_setup_tx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd147000-0xfd14a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd14b000-0xfd14e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd14f000-0xfd152000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd153000-0xfd156000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd157000-0xfd15a000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd15b000-0xfd15e000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd15f000-0xfd162000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd163000-0xfd166000 12288 igb_setup_rx_resources+0x27/0x140 [igb] pages=2 vmalloc
> 0xfd1b2000-0xfd1b6000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
> 0xfd1bf000-0xfd1c1000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd1cb000-0xfd1ce000 12288 module_alloc+0x72/0x80 pages=2 vmalloc
> 0xfd1d5000-0xfd1d7000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd1de000-0xfd1e0000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd1e8000-0xfd1ea000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd1f2000-0xfd1f4000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd1fb000-0xfd1fd000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd205000-0xfd207000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd20f000-0xfd211000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd219000-0xfd21b000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd223000-0xfd225000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd22d000-0xfd22f000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd23a000-0xfd23c000 8192 module_alloc+0x72/0x80 pages=1 vmalloc
> 0xfd248000-0xfd24c000 16384 module_alloc+0x72/0x80 pages=3 vmalloc
> 0xfd400000-0xfd800000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfd800000-0xfdc00000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfdc00000-0xfe000000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfe000000-0xfe400000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfe400000-0xfe800000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfe800000-0xfec00000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xfec00000-0xff000000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
> 0xff000000-0xff400000 4194304 pcpu_get_vm_areas+0x0/0x610 vmalloc
>
Thanks
Your vmalloc space is very fragmented. pcpu_get_vm_areas() want
hugepages (4MB on your machine, 2MB on mine because I have
CONFIG_HIGHMEM64G=y)
You could :
1) Use a 64 bit kernel ( :) )
or
2) boot parameter vmalloc=256M to get more room
(default is 128 Mbytes)
and eventually
select a 2G/2G User/Kernel split to get more LOWMEM, because big vmalloc
windows shrinks the LOWMEM zone. (CONFIG_VMSPLIT_2G=y)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox