* 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
* [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] 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
* 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: 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] 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: 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: 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: 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: 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: [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
* 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 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
* [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: 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
* Re: ping -I eth1 ....
From: Eric Dumazet @ 2010-11-05 15:06 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev, Thomas Graf
In-Reply-To: <OF6C6C2970.245A64ED-ONC12577D2.00518CF6-C12577D2.00522AAD@transmode.se>
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 :)
^ permalink raw reply
* Re: ping -I eth1 ....
From: Joakim Tjernlund @ 2010-11-05 15:45 UTC (permalink / raw)
To: Thomas Graf; +Cc: Eric Dumazet, netdev, Thomas Graf
In-Reply-To: <20101105145321.GB14986@canuck.infradead.org>
Thomas Graf <tgr@infradead.org> wrote on 2010/11/05 15:53:21:
>
> On Fri, Nov 05, 2010 at 03:34:25PM +0100, Eric Dumazet wrote:
> > Le vendredi 05 novembre 2010 à 10:25 -0400, Thomas Graf a écrit :
> > > On Fri, Nov 05, 2010 at 03:01:57PM +0100, Joakim Tjernlund wrote:
> > > > 1) I think you should include IFF_RUNNING too
> > >
> > > Probably even better to base it on the operational state of the link
> > >
> > > netif_running() && netif_oper_up() && netif_carrier_ok() && !netif_dormant()
> >
> > At this point we setup a route.
> >
> > Is a change of any of this status going to flush/cancel a previously
> > setup route ?
>
> No it won't.
>
> > There must 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)
>
> The reason is that while the device is not operational we queue all
> packets in the qdisc and hope for the link to become operational in the
> near future. This does make sense, especially if the link was once
> operational.
Hmm, perhaps one needs to treat user space differently from
internal kernel calls?
User space should always get an error if the link isn't functional.
^ permalink raw reply
* Re: [PATCH 46/49] net/netfilter: Use vzalloc
From: Joe Perches @ 2010-11-05 15:25 UTC (permalink / raw)
To: Jiri Kosina
Cc: Eric Dumazet, Jesper Juhl, Patrick McHardy, David S. Miller,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1011051108270.15851@pobox.suse.cz>
On Fri, 2010-11-05 at 11:10 -0400, Jiri Kosina wrote:
> On Thu, 4 Nov 2010, Joe Perches wrote:
> > I also think a single rolled-up single patch is good.
> > I believe Jiri Kosina can easily apply all these individual patches as a
> > single patch if he chooses.
> I will, after this settles a little bit (the same for the WARN series).
> I prefer waiting a bit before applying your patches usually.
> First to see what lands in linux-next through maintainer's trees, second
> to gather Acks.
I think that's the right way to do these
sorts of trivial changes too.
Individual patches cc'd to maintainers for
feedback, improvement, acks or to be directly
applied to their trees, followed by a longish
delay before any unapplied patches are taken
up as a single patch by your trivial queue.
Thanks for doing that work Jiri.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: don't remove address state on ifdown if the address is being kept
From: David Miller @ 2010-11-05 15:12 UTC (permalink / raw)
To: lorenzo; +Cc: maze, brian.haley, netdev
In-Reply-To: <AANLkTine2qXg7MTFyh=Ka=tB8fuzB18-NVRryTyc=LKp@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 5 Nov 2010 14:45:28 +0800
> On Thu, Oct 28, 2010 at 2:45 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
>>> Fix it so that none of this state is updated if the address is being kept on the interface.
>
> David, any feedback on this? The existing code clearly has the
> intention of keeping the addresses around, except they don't actually
> work, and this just fixes the bug.
I'm travelling and busy at Kernel Summit and Linux Plumbers Conference,
so I'm only processing the most easiest patches this week.
I'll look into this when I get back.
^ permalink raw reply
* Re: [PATCH 46/49] net/netfilter: Use vzalloc
From: Jiri Kosina @ 2010-11-05 15:10 UTC (permalink / raw)
To: Joe Perches
Cc: Eric Dumazet, Jesper Juhl, Patrick McHardy, David S. Miller,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <1288940146.18440.55.camel@Joe-Laptop>
On Thu, 4 Nov 2010, Joe Perches wrote:
> I also think a single rolled-up single patch is good.
>
> I believe Jiri Kosina can easily apply all these individual patches as a
> single patch if he chooses.
I will, after this settles a little bit (the same for the WARN series).
I prefer waiting a bit before applying your patches usually.
First to see what lands in linux-next through maintainer's trees, second
to gather Acks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: 2.6.36 vlans & bridge crash - status?
From: Jesse Gross @ 2010-11-05 15:05 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: netdev list, nikola.ciprich
In-Reply-To: <20101105103520.GA3577@pcnci.linuxbox.cz>
On Fri, Nov 5, 2010 at 3:35 AM, Nikola Ciprich <extmaillist@linuxbox.cz> wrote:
> Hello,
> I would like to ask if somebody is trying to solve
> https://bugzilla.kernel.org/show_bug.cgi?id=20462
> and if needed, could I provide some help, testing etc?
I sent out a patch for something related:
http://permalink.gmane.org/gmane.linux.network/176566
My guess is that it will also fix your issue. Can you test it?
^ permalink raw reply
* Re: ping -I eth1 ....
From: Joakim Tjernlund @ 2010-11-05 15:04 UTC (permalink / raw)
To: Thomas Graf; +Cc: Eric Dumazet, netdev, Thomas Graf
In-Reply-To: <20101105145321.GB14986@canuck.infradead.org>
Thomas Graf <tgr@infradead.org> wrote on 2010/11/05 15:53:21:
>
> On Fri, Nov 05, 2010 at 03:34:25PM +0100, Eric Dumazet wrote:
> > Le vendredi 05 novembre 2010 à 10:25 -0400, Thomas Graf a écrit :
> > > On Fri, Nov 05, 2010 at 03:01:57PM +0100, Joakim Tjernlund wrote:
> > > > 1) I think you should include IFF_RUNNING too
> > >
> > > Probably even better to base it on the operational state of the link
> > >
> > > netif_running() && netif_oper_up() && netif_carrier_ok() && !netif_dormant()
> >
> > At this point we setup a route.
> >
> > Is a change of any of this status going to flush/cancel a previously
> > setup route ?
>
> No it won't.
>
> > There must 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)
>
> The reason is that while the device is not operational we queue all
> packets in the qdisc and hope for the link to become operational in the
> near future. This does make sense, especially if the link was once
> operational.
That feels wrong. There is now way to know if it ever will be operational
again, let alone in the near future. Is there a timeout so that
if the link doesn't become operational, it will fail?
^ permalink raw reply
* Re: ping -I eth1 ....
From: Joakim Tjernlund @ 2010-11-05 14:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Thomas Graf
In-Reply-To: <1288967665.2882.522.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/11/05 15:34:25:
>
> Le vendredi 05 novembre 2010 à 10:25 -0400, Thomas Graf a écrit :
> > On Fri, Nov 05, 2010 at 03:01:57PM +0100, Joakim Tjernlund wrote:
> > > > > Then I do ifconfig eth1 down
> > > > > and I still see the same. Should not
> > > > > sendto and/or revcfrom return some error as
> > > > > the interface is down?
> > > >
> > > > Hmm, this reminds me one patch, yes...
> > > >
> > > > Search for " ipv4: remove all rt cache entries on UNREGISTER event"
> > > >
> > > > http://permalink.gmane.org/gmane.linux.network/173391
> > >
> > > Ah, that does the trick. A few comments though:
> > >
> > > 1) I think you should include IFF_RUNNING too
> >
> > Probably even better to base it on the operational state of the link
> >
> > netif_running() && netif_oper_up() && netif_carrier_ok() && !netif_dormant()
>
> At this point we setup a route.
It fixes my problem too so it is not only about setting up routes.
The ping -I eth1 I did didn't even have an IP address on eth1
Perhaps there is a better place to test the interface status?
Especially as the RX path should be considered too.
>
> Is a change of any of this status going to flush/cancel a previously
> setup route ?
>
> There must 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.
^ permalink raw reply
* Re: ping -I eth1 ....
From: Thomas Graf @ 2010-11-05 14:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Joakim Tjernlund, netdev
In-Reply-To: <1288967665.2882.522.camel@edumazet-laptop>
On Fri, Nov 05, 2010 at 03:34:25PM +0100, Eric Dumazet wrote:
> Le vendredi 05 novembre 2010 à 10:25 -0400, Thomas Graf a écrit :
> > On Fri, Nov 05, 2010 at 03:01:57PM +0100, Joakim Tjernlund wrote:
> > > 1) I think you should include IFF_RUNNING too
> >
> > Probably even better to base it on the operational state of the link
> >
> > netif_running() && netif_oper_up() && netif_carrier_ok() && !netif_dormant()
>
> At this point we setup a route.
>
> Is a change of any of this status going to flush/cancel a previously
> setup route ?
No it won't.
> There must 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)
The reason is that while the device is not operational we queue all
packets in the qdisc and hope for the link to become operational in the
near future. This does make sense, especially if the link was once
operational.
This case is special however, the interface is specified explicitely
and expectes to be notified immediately if that is not possible.
^ permalink raw reply
* Re: ping -I eth1 ....
From: Eric Dumazet @ 2010-11-05 14:34 UTC (permalink / raw)
To: Thomas Graf; +Cc: Joakim Tjernlund, netdev
In-Reply-To: <20101105142510.GA14986@canuck.infradead.org>
Le vendredi 05 novembre 2010 à 10:25 -0400, Thomas Graf a écrit :
> On Fri, Nov 05, 2010 at 03:01:57PM +0100, Joakim Tjernlund wrote:
> > > > Then I do ifconfig eth1 down
> > > > and I still see the same. Should not
> > > > sendto and/or revcfrom return some error as
> > > > the interface is down?
> > >
> > > Hmm, this reminds me one patch, yes...
> > >
> > > Search for " ipv4: remove all rt cache entries on UNREGISTER event"
> > >
> > > http://permalink.gmane.org/gmane.linux.network/173391
> >
> > Ah, that does the trick. A few comments though:
> >
> > 1) I think you should include IFF_RUNNING too
>
> Probably even better to base it on the operational state of the link
>
> netif_running() && netif_oper_up() && netif_carrier_ok() && !netif_dormant()
At this point we setup a route.
Is a change of any of this status going to flush/cancel a previously
setup route ?
There must 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)
^ 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