* Re: [iproute2 1/1] man: tc-ife.8: man page for ife action
From: Phil Sutter @ 2016-04-30 11:35 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: stephen, netdev, lucasb
In-Reply-To: <1462013884-4971-1-git-send-email-jhs@emojatatu.com>
On Sat, Apr 30, 2016 at 06:58:04AM -0400, Jamal Hadi Salim wrote:
> From: Lucas Bates <lucasb@mojatatu.com>
>
> Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Phil Sutter <phil@nwl.cc>
Nit-picking on two things below, but merely as a hint - I don't think
they need to be fixed before applying this.
[...]
> +.SH NAME
> +IFE - encapsulate/decapsulate metadata
> +.SH SYNOPSIS
> +.in +8
> +.ti -8
> +.BR tc " ... " "action"
> +.B "ife"
The quotes around 'action' and 'ife' are not necessary. Furthermore,
the two lines can be combined:
> +.I DIRECTION ACTION
> +.RB "[ " dst
> +.IR DMAC " ] "
> +.RB "[ " src
> +.IR SMAC " ] "
> +.RB "[ " type
> +.IR TYPE " ] "
> +.R "[ "
This adds a trailing whitespace. Checkpatch.pl finds these things. ;)
Thanks, Phil
^ permalink raw reply
* Re: [PATCHv3] netem: Segment GSO packets on enqueue
From: Neil Horman @ 2016-04-30 13:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Jamal Hadi Salim, David S. Miller, netem, eric.dumazet
In-Reply-To: <20160429111905.09b4b2e2@xeon-e3>
On Fri, Apr 29, 2016 at 11:19:05AM -0700, Stephen Hemminger wrote:
> On Fri, 29 Apr 2016 13:35:48 -0400
> Neil Horman <nhorman@tuxdriver.com> wrote:
>
> > This was recently reported to me, and reproduced on the latest net kernel, when
> > attempting to run netperf from a host that had a netem qdisc attached to the
> > egress interface:
> >
> > [ 788.073771] ------------[ cut here ]------------
> > [ 788.096716] WARNING: at net/core/dev.c:2253 skb_warn_bad_offload+0xcd/0xda()
> > [ 788.129521] bnx2: caps=(0x00000001801949b3, 0x0000000000000000) len=2962
> > data_len=0 gso_size=1448 gso_type=1 ip_summed=3
> > [ 788.182150] Modules linked in: sch_netem kvm_amd kvm crc32_pclmul ipmi_ssif
> > ghash_clmulni_intel sp5100_tco amd64_edac_mod aesni_intel lrw gf128mul
> > glue_helper ablk_helper edac_mce_amd cryptd pcspkr sg edac_core hpilo ipmi_si
> > i2c_piix4 k10temp fam15h_power hpwdt ipmi_msghandler shpchp acpi_power_meter
> > pcc_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c
> > sd_mod crc_t10dif crct10dif_generic mgag200 syscopyarea sysfillrect sysimgblt
> > i2c_algo_bit drm_kms_helper ahci ata_generic pata_acpi ttm libahci
> > crct10dif_pclmul pata_atiixp tg3 libata crct10dif_common drm crc32c_intel ptp
> > serio_raw bnx2 r8169 hpsa pps_core i2c_core mii dm_mirror dm_region_hash dm_log
> > dm_mod
> > [ 788.465294] CPU: 16 PID: 0 Comm: swapper/16 Tainted: G W
> > ------------ 3.10.0-327.el7.x86_64 #1
> > [ 788.511521] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/17/2012
> > [ 788.542260] ffff880437c036b8 f7afc56532a53db9 ffff880437c03670
> > ffffffff816351f1
> > [ 788.576332] ffff880437c036a8 ffffffff8107b200 ffff880633e74200
> > ffff880231674000
> > [ 788.611943] 0000000000000001 0000000000000003 0000000000000000
> > ffff880437c03710
> > [ 788.647241] Call Trace:
> > [ 788.658817] <IRQ> [<ffffffff816351f1>] dump_stack+0x19/0x1b
> > [ 788.686193] [<ffffffff8107b200>] warn_slowpath_common+0x70/0xb0
> > [ 788.713803] [<ffffffff8107b29c>] warn_slowpath_fmt+0x5c/0x80
> > [ 788.741314] [<ffffffff812f92f3>] ? ___ratelimit+0x93/0x100
> > [ 788.767018] [<ffffffff81637f49>] skb_warn_bad_offload+0xcd/0xda
> > [ 788.796117] [<ffffffff8152950c>] skb_checksum_help+0x17c/0x190
> > [ 788.823392] [<ffffffffa01463a1>] netem_enqueue+0x741/0x7c0 [sch_netem]
> > [ 788.854487] [<ffffffff8152cb58>] dev_queue_xmit+0x2a8/0x570
> > [ 788.880870] [<ffffffff8156ae1d>] ip_finish_output+0x53d/0x7d0
> > ...
> >
> > The problem occurs because netem is not prepared to handle GSO packets (as it
> > uses skb_checksum_help in its enqueue path, which cannot manipulate these
> > frames).
> >
> > The solution I think is to simply segment the skb in a simmilar fashion to the
> > way we do in __dev_queue_xmit (via validate_xmit_skb), with some minor changes.
> > When we decide to corrupt an skb, if the frame is GSO, we segment it, corrupt
> > the first segment, and enqueue the remaining ones.
> >
> > tested successfully by myself on the latest net kernel, to whcih this applies
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: Jamal Hadi Salim <jhs@mojatatu.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > CC: netem@lists.linux-foundation.org
> > CC: eric.dumazet@gmail.com
> >
>
> This looks like a good idea.
>
> Please cleanup the formatting issues:
>
> This was recently reported to me, and reproduced on the latest net kernel, when
>
> WARNING: 'whcih' may be misspelled - perhaps 'which'?
> #93:
> tested successfully by myself on the latest net kernel, to whcih this applies
>
> ERROR: "foo* bar" should be "foo *bar"
> #130: FILE: net/sched/sch_netem.c:402:
> +static struct sk_buff* netem_segment(struct sk_buff *skb, struct Qdisc *sch)
>
>
> CHECK: braces {} should be used on all arms of this statement
> #164: FILE: net/sched/sch_netem.c:479:
> + if (skb_is_gso(skb)) {
> [...]
> + } else
> [...]
>
> CHECK: braces {} should be used on all arms of this statement
> #198: FILE: net/sched/sch_netem.c:562:
> + if (rc != NET_XMIT_SUCCESS) {
> [...]
> + } else
> [...]
>
>
>
>
>
>
Will, do when I get back to the office monday
Thanks!
Neil
^ permalink raw reply
* Re: [PATCH iproute2 net-next] ifstat: move to new RTM_GETSTATS api
From: Roopa Prabhu @ 2016-04-30 15:15 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: stephen, netdev, davem, edumazet, tgraf, nicolas.dichtel, nikolay
In-Reply-To: <57248720.8060001@mojatatu.com>
On 4/30/16, 3:21 AM, Jamal Hadi Salim wrote:
> On 16-04-30 02:41 AM, Roopa Prabhu wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This patch modifies ifstat to use the new RTM_GETSTATS api
>> to query stats from the kernel. In the process this also
>> moves ifstat to use 64 bit stats.
>
> Breaks old kernels? May need to keep backward compat of
> RTM_NEWLINK and even new main struct for GETSTATS.
yes, i was wondering about that. v2 coming. If GETSTATS fails, I will fallback to RTM_NEWLINK.
thanks!
^ permalink raw reply
* Unauthorized attempt
From: PayPal @ 2016-04-30 15:09 UTC (permalink / raw)
^ permalink raw reply
* pull request [net]: batman-adv 20160430
From: Antonio Quartulli @ 2016-04-30 17:05 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
this is another pull request intended for net.
I know that I sent another batch a few days ago, but after having gone
through my queue I thought that merging these last 4 patches would still
be worth it (there won't be any other pull request for linux-4.6 :)).
The description of the changes follows below.
Please pull or let me know of any issue!
Thanks a lot,
Antonio
The following changes since commit 1dfcd832b1a9ed45edac15b31d079b805fa0ae2a:
Merge branch 'bpf-fixes' (2016-04-28 17:29:46 -0400)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to abe59c65225ccd63a5964e2f2a73dd2995b948e7:
batman-adv: Fix reference counting of hardif_neigh_node object for neigh_node (2016-04-29 19:46:11 +0800)
----------------------------------------------------------------
In this small batch of patches you have:
- a fix for our Distributed ARP Table that makes sure that the input
provided to the hash function during a query is the same as the one
provided during an insert (so to prevent false negatives), by Antonio
Quartulli
- a fix for our new protocol implementation B.A.T.M.A.N. V that ensures
that a hard interface is properly re-activated when it is brought down
and then up again, by Antonio Quartulli
- two fixes respectively to the reference counting of the tt_local_entry
and neigh_node objects, by Sven Eckelmann. Such bug is rather severe
as it would prevent the netdev objects references by batman-adv from
being released after shutdown.
----------------------------------------------------------------
Antonio Quartulli (2):
batman-adv: fix DAT candidate selection (must use vid)
batman-adv: B.A.T.M.A.N V - make sure iface is reactivated upon NETDEV_UP event
Sven Eckelmann (2):
batman-adv: Fix reference counting of vlan object for tt_local_entry
batman-adv: Fix reference counting of hardif_neigh_node object for neigh_node
net/batman-adv/bat_v.c | 12 ++++++++++
net/batman-adv/distributed-arp-table.c | 17 ++++++++------
net/batman-adv/hard-interface.c | 3 +++
net/batman-adv/originator.c | 16 ++++---------
net/batman-adv/translation-table.c | 42 ++++------------------------------
net/batman-adv/types.h | 7 ++++++
6 files changed, 41 insertions(+), 56 deletions(-)
^ permalink raw reply
* [PATCH 2/4] batman-adv: B.A.T.M.A.N V - make sure iface is reactivated upon NETDEV_UP event
From: Antonio Quartulli @ 2016-04-30 17:06 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1462035963-28970-1-git-send-email-a@unstable.cc>
At the moment there is no explicit reactivation of an hard-interface
upon NETDEV_UP event. In case of B.A.T.M.A.N. IV the interface is
reactivated as soon as the next OGM is scheduled for sending, but this
mechanism does not work with B.A.T.M.A.N. V. The latter does not rely
on the same scheduling mechanism as its predecessor and for this reason
the hard-interface remains deactivated forever after being brought down
once.
This patch fixes the reactivation mechanism by adding a new routing API
which explicitly allows each algorithm to perform any needed operation
upon interface re-activation.
Such API is optional and is implemented by B.A.T.M.A.N. V only and it
just takes care of setting the iface status to ACTIVE
Signed-off-by: Antonio Quartulli <a@unstable.cc>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
---
net/batman-adv/bat_v.c | 12 ++++++++++++
net/batman-adv/hard-interface.c | 3 +++
net/batman-adv/types.h | 3 +++
3 files changed, 18 insertions(+)
diff --git a/net/batman-adv/bat_v.c b/net/batman-adv/bat_v.c
index 3315b9a598af..4026f198a734 100644
--- a/net/batman-adv/bat_v.c
+++ b/net/batman-adv/bat_v.c
@@ -32,10 +32,21 @@
#include "bat_v_elp.h"
#include "bat_v_ogm.h"
+#include "hard-interface.h"
#include "hash.h"
#include "originator.h"
#include "packet.h"
+static void batadv_v_iface_activate(struct batadv_hard_iface *hard_iface)
+{
+ /* B.A.T.M.A.N. V does not use any queuing mechanism, therefore it can
+ * set the interface as ACTIVE right away, without any risk of race
+ * condition
+ */
+ if (hard_iface->if_status == BATADV_IF_TO_BE_ACTIVATED)
+ hard_iface->if_status = BATADV_IF_ACTIVE;
+}
+
static int batadv_v_iface_enable(struct batadv_hard_iface *hard_iface)
{
int ret;
@@ -274,6 +285,7 @@ static bool batadv_v_neigh_is_sob(struct batadv_neigh_node *neigh1,
static struct batadv_algo_ops batadv_batman_v __read_mostly = {
.name = "BATMAN_V",
+ .bat_iface_activate = batadv_v_iface_activate,
.bat_iface_enable = batadv_v_iface_enable,
.bat_iface_disable = batadv_v_iface_disable,
.bat_iface_update_mac = batadv_v_iface_update_mac,
diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index c61d5b0b24d2..0a7deaf2670a 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -407,6 +407,9 @@ batadv_hardif_activate_interface(struct batadv_hard_iface *hard_iface)
batadv_update_min_mtu(hard_iface->soft_iface);
+ if (bat_priv->bat_algo_ops->bat_iface_activate)
+ bat_priv->bat_algo_ops->bat_iface_activate(hard_iface);
+
out:
if (primary_if)
batadv_hardif_put(primary_if);
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index 9abfb3e73c34..443e9b84e07d 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -1250,6 +1250,8 @@ struct batadv_forw_packet {
* struct batadv_algo_ops - mesh algorithm callbacks
* @list: list node for the batadv_algo_list
* @name: name of the algorithm
+ * @bat_iface_activate: start routing mechanisms when hard-interface is brought
+ * up
* @bat_iface_enable: init routing info when hard-interface is enabled
* @bat_iface_disable: de-init routing info when hard-interface is disabled
* @bat_iface_update_mac: (re-)init mac addresses of the protocol information
@@ -1277,6 +1279,7 @@ struct batadv_forw_packet {
struct batadv_algo_ops {
struct hlist_node list;
char *name;
+ void (*bat_iface_activate)(struct batadv_hard_iface *hard_iface);
int (*bat_iface_enable)(struct batadv_hard_iface *hard_iface);
void (*bat_iface_disable)(struct batadv_hard_iface *hard_iface);
void (*bat_iface_update_mac)(struct batadv_hard_iface *hard_iface);
--
2.8.1
^ permalink raw reply related
* [PATCH 3/4] batman-adv: Fix reference counting of vlan object for tt_local_entry
From: Antonio Quartulli @ 2016-04-30 17:06 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Sven Eckelmann, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1462035963-28970-1-git-send-email-a@unstable.cc>
From: Sven Eckelmann <sven@narfation.org>
The batadv_tt_local_entry was specific to a batadv_softif_vlan and held an
implicit reference to it. But this reference was never stored in form of a
pointer in the tt_local_entry itself. Instead batadv_tt_local_remove,
batadv_tt_local_table_free and batadv_tt_local_purge_pending_clients depend
on a consistent state of bat_priv->softif_vlan_list and that
batadv_softif_vlan_get always returns the batadv_softif_vlan object which
it has a reference for. But batadv_softif_vlan_get cannot guarantee that
because it is working only with rcu_read_lock on this list. It can
therefore happen that an vid is in this list twice or that
batadv_softif_vlan_get cannot find the batadv_softif_vlan for an vid due to
some other list operations taking place at the same time.
Instead add a batadv_softif_vlan pointer directly in batadv_tt_local_entry
which will be used for the reference counter decremented on release of
batadv_tt_local_entry.
Fixes: 35df3b298fc8 ("batman-adv: fix TT VLAN inconsistency on VLAN re-add")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Acked-by: Antonio Quartulli <a@unstable.cc>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
---
net/batman-adv/translation-table.c | 42 ++++----------------------------------
net/batman-adv/types.h | 2 ++
2 files changed, 6 insertions(+), 38 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 0b43e86328a5..9b4551a86535 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -215,6 +215,8 @@ static void batadv_tt_local_entry_release(struct kref *ref)
tt_local_entry = container_of(ref, struct batadv_tt_local_entry,
common.refcount);
+ batadv_softif_vlan_put(tt_local_entry->vlan);
+
kfree_rcu(tt_local_entry, common.rcu);
}
@@ -673,6 +675,7 @@ bool batadv_tt_local_add(struct net_device *soft_iface, const u8 *addr,
kref_get(&tt_local->common.refcount);
tt_local->last_seen = jiffies;
tt_local->common.added_at = tt_local->last_seen;
+ tt_local->vlan = vlan;
/* the batman interface mac and multicast addresses should never be
* purged
@@ -991,7 +994,6 @@ int batadv_tt_local_seq_print_text(struct seq_file *seq, void *offset)
struct batadv_tt_common_entry *tt_common_entry;
struct batadv_tt_local_entry *tt_local;
struct batadv_hard_iface *primary_if;
- struct batadv_softif_vlan *vlan;
struct hlist_head *head;
unsigned short vid;
u32 i;
@@ -1027,14 +1029,6 @@ int batadv_tt_local_seq_print_text(struct seq_file *seq, void *offset)
last_seen_msecs = last_seen_msecs % 1000;
no_purge = tt_common_entry->flags & np_flag;
-
- vlan = batadv_softif_vlan_get(bat_priv, vid);
- if (!vlan) {
- seq_printf(seq, "Cannot retrieve VLAN %d\n",
- BATADV_PRINT_VID(vid));
- continue;
- }
-
seq_printf(seq,
" * %pM %4i [%c%c%c%c%c%c] %3u.%03u (%#.8x)\n",
tt_common_entry->addr,
@@ -1052,9 +1046,7 @@ int batadv_tt_local_seq_print_text(struct seq_file *seq, void *offset)
BATADV_TT_CLIENT_ISOLA) ? 'I' : '.'),
no_purge ? 0 : last_seen_secs,
no_purge ? 0 : last_seen_msecs,
- vlan->tt.crc);
-
- batadv_softif_vlan_put(vlan);
+ tt_local->vlan->tt.crc);
}
rcu_read_unlock();
}
@@ -1099,7 +1091,6 @@ u16 batadv_tt_local_remove(struct batadv_priv *bat_priv, const u8 *addr,
{
struct batadv_tt_local_entry *tt_local_entry;
u16 flags, curr_flags = BATADV_NO_FLAGS;
- struct batadv_softif_vlan *vlan;
void *tt_entry_exists;
tt_local_entry = batadv_tt_local_hash_find(bat_priv, addr, vid);
@@ -1139,14 +1130,6 @@ u16 batadv_tt_local_remove(struct batadv_priv *bat_priv, const u8 *addr,
/* extra call to free the local tt entry */
batadv_tt_local_entry_put(tt_local_entry);
- /* decrease the reference held for this vlan */
- vlan = batadv_softif_vlan_get(bat_priv, vid);
- if (!vlan)
- goto out;
-
- batadv_softif_vlan_put(vlan);
- batadv_softif_vlan_put(vlan);
-
out:
if (tt_local_entry)
batadv_tt_local_entry_put(tt_local_entry);
@@ -1219,7 +1202,6 @@ static void batadv_tt_local_table_free(struct batadv_priv *bat_priv)
spinlock_t *list_lock; /* protects write access to the hash lists */
struct batadv_tt_common_entry *tt_common_entry;
struct batadv_tt_local_entry *tt_local;
- struct batadv_softif_vlan *vlan;
struct hlist_node *node_tmp;
struct hlist_head *head;
u32 i;
@@ -1241,14 +1223,6 @@ static void batadv_tt_local_table_free(struct batadv_priv *bat_priv)
struct batadv_tt_local_entry,
common);
- /* decrease the reference held for this vlan */
- vlan = batadv_softif_vlan_get(bat_priv,
- tt_common_entry->vid);
- if (vlan) {
- batadv_softif_vlan_put(vlan);
- batadv_softif_vlan_put(vlan);
- }
-
batadv_tt_local_entry_put(tt_local);
}
spin_unlock_bh(list_lock);
@@ -3309,7 +3283,6 @@ static void batadv_tt_local_purge_pending_clients(struct batadv_priv *bat_priv)
struct batadv_hashtable *hash = bat_priv->tt.local_hash;
struct batadv_tt_common_entry *tt_common;
struct batadv_tt_local_entry *tt_local;
- struct batadv_softif_vlan *vlan;
struct hlist_node *node_tmp;
struct hlist_head *head;
spinlock_t *list_lock; /* protects write access to the hash lists */
@@ -3339,13 +3312,6 @@ static void batadv_tt_local_purge_pending_clients(struct batadv_priv *bat_priv)
struct batadv_tt_local_entry,
common);
- /* decrease the reference held for this vlan */
- vlan = batadv_softif_vlan_get(bat_priv, tt_common->vid);
- if (vlan) {
- batadv_softif_vlan_put(vlan);
- batadv_softif_vlan_put(vlan);
- }
-
batadv_tt_local_entry_put(tt_local);
}
spin_unlock_bh(list_lock);
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index 443e9b84e07d..65afd090ab3e 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -1073,10 +1073,12 @@ struct batadv_tt_common_entry {
* struct batadv_tt_local_entry - translation table local entry data
* @common: general translation table data
* @last_seen: timestamp used for purging stale tt local entries
+ * @vlan: soft-interface vlan of the entry
*/
struct batadv_tt_local_entry {
struct batadv_tt_common_entry common;
unsigned long last_seen;
+ struct batadv_softif_vlan *vlan;
};
/**
--
2.8.1
^ permalink raw reply related
* [PATCH 1/4] batman-adv: fix DAT candidate selection (must use vid)
From: Antonio Quartulli @ 2016-04-30 17:06 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Sven Eckelmann,
Marek Lindner
In-Reply-To: <1462035963-28970-1-git-send-email-a@unstable.cc>
Now that DAT is VLAN aware, it must use the VID when
computing the DHT address of the candidate nodes where
an entry is going to be stored/retrieved.
Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware")
Signed-off-by: Antonio Quartulli <a@unstable.cc>
[sven@narfation.org: fix conflicts with current version]
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
---
net/batman-adv/distributed-arp-table.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c
index e96d7c745b4a..3e6b2624f980 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -568,6 +568,7 @@ static void batadv_choose_next_candidate(struct batadv_priv *bat_priv,
* be sent to
* @bat_priv: the bat priv with all the soft interface information
* @ip_dst: ipv4 to look up in the DHT
+ * @vid: VLAN identifier
*
* An originator O is selected if and only if its DHT_ID value is one of three
* closest values (from the LEFT, with wrap around if needed) then the hash
@@ -576,7 +577,8 @@ static void batadv_choose_next_candidate(struct batadv_priv *bat_priv,
* Return: the candidate array of size BATADV_DAT_CANDIDATE_NUM.
*/
static struct batadv_dat_candidate *
-batadv_dat_select_candidates(struct batadv_priv *bat_priv, __be32 ip_dst)
+batadv_dat_select_candidates(struct batadv_priv *bat_priv, __be32 ip_dst,
+ unsigned short vid)
{
int select;
batadv_dat_addr_t last_max = BATADV_DAT_ADDR_MAX, ip_key;
@@ -592,7 +594,7 @@ batadv_dat_select_candidates(struct batadv_priv *bat_priv, __be32 ip_dst)
return NULL;
dat.ip = ip_dst;
- dat.vid = 0;
+ dat.vid = vid;
ip_key = (batadv_dat_addr_t)batadv_hash_dat(&dat,
BATADV_DAT_ADDR_MAX);
@@ -612,6 +614,7 @@ batadv_dat_select_candidates(struct batadv_priv *bat_priv, __be32 ip_dst)
* @bat_priv: the bat priv with all the soft interface information
* @skb: payload to send
* @ip: the DHT key
+ * @vid: VLAN identifier
* @packet_subtype: unicast4addr packet subtype to use
*
* This function copies the skb with pskb_copy() and is sent as unicast packet
@@ -622,7 +625,7 @@ batadv_dat_select_candidates(struct batadv_priv *bat_priv, __be32 ip_dst)
*/
static bool batadv_dat_send_data(struct batadv_priv *bat_priv,
struct sk_buff *skb, __be32 ip,
- int packet_subtype)
+ unsigned short vid, int packet_subtype)
{
int i;
bool ret = false;
@@ -631,7 +634,7 @@ static bool batadv_dat_send_data(struct batadv_priv *bat_priv,
struct sk_buff *tmp_skb;
struct batadv_dat_candidate *cand;
- cand = batadv_dat_select_candidates(bat_priv, ip);
+ cand = batadv_dat_select_candidates(bat_priv, ip, vid);
if (!cand)
goto out;
@@ -1022,7 +1025,7 @@ bool batadv_dat_snoop_outgoing_arp_request(struct batadv_priv *bat_priv,
ret = true;
} else {
/* Send the request to the DHT */
- ret = batadv_dat_send_data(bat_priv, skb, ip_dst,
+ ret = batadv_dat_send_data(bat_priv, skb, ip_dst, vid,
BATADV_P_DAT_DHT_GET);
}
out:
@@ -1150,8 +1153,8 @@ void batadv_dat_snoop_outgoing_arp_reply(struct batadv_priv *bat_priv,
/* Send the ARP reply to the candidates for both the IP addresses that
* the node obtained from the ARP reply
*/
- batadv_dat_send_data(bat_priv, skb, ip_src, BATADV_P_DAT_DHT_PUT);
- batadv_dat_send_data(bat_priv, skb, ip_dst, BATADV_P_DAT_DHT_PUT);
+ batadv_dat_send_data(bat_priv, skb, ip_src, vid, BATADV_P_DAT_DHT_PUT);
+ batadv_dat_send_data(bat_priv, skb, ip_dst, vid, BATADV_P_DAT_DHT_PUT);
}
/**
--
2.8.1
^ permalink raw reply related
* [PATCH 4/4] batman-adv: Fix reference counting of hardif_neigh_node object for neigh_node
From: Antonio Quartulli @ 2016-04-30 17:06 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Sven Eckelmann, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1462035963-28970-1-git-send-email-a@unstable.cc>
From: Sven Eckelmann <sven@narfation.org>
The batadv_neigh_node was specific to a batadv_hardif_neigh_node and held
an implicit reference to it. But this reference was never stored in form of
a pointer in the batadv_neigh_node itself. Instead
batadv_neigh_node_release depends on a consistent state of
hard_iface->neigh_list and that batadv_hardif_neigh_get always returns the
batadv_hardif_neigh_node object which it has a reference for. But
batadv_hardif_neigh_get cannot guarantee that because it is working only
with rcu_read_lock on this list. It can therefore happen that a neigh_addr
is in this list twice or that batadv_hardif_neigh_get cannot find the
batadv_hardif_neigh_node for an neigh_addr due to some other list
operations taking place at the same time.
Instead add a batadv_hardif_neigh_node pointer directly in
batadv_neigh_node which will be used for the reference counter decremented
on release of batadv_neigh_node.
Fixes: cef63419f7db ("batman-adv: add list of unique single hop neighbors per hard-interface")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
---
net/batman-adv/originator.c | 16 +++++-----------
net/batman-adv/types.h | 2 ++
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c
index d52f67a0c057..c355a824713c 100644
--- a/net/batman-adv/originator.c
+++ b/net/batman-adv/originator.c
@@ -250,7 +250,6 @@ static void batadv_neigh_node_release(struct kref *ref)
{
struct hlist_node *node_tmp;
struct batadv_neigh_node *neigh_node;
- struct batadv_hardif_neigh_node *hardif_neigh;
struct batadv_neigh_ifinfo *neigh_ifinfo;
struct batadv_algo_ops *bao;
@@ -262,13 +261,7 @@ static void batadv_neigh_node_release(struct kref *ref)
batadv_neigh_ifinfo_put(neigh_ifinfo);
}
- hardif_neigh = batadv_hardif_neigh_get(neigh_node->if_incoming,
- neigh_node->addr);
- if (hardif_neigh) {
- /* batadv_hardif_neigh_get() increases refcount too */
- batadv_hardif_neigh_put(hardif_neigh);
- batadv_hardif_neigh_put(hardif_neigh);
- }
+ batadv_hardif_neigh_put(neigh_node->hardif_neigh);
if (bao->bat_neigh_free)
bao->bat_neigh_free(neigh_node);
@@ -665,6 +658,10 @@ batadv_neigh_node_new(struct batadv_orig_node *orig_node,
neigh_node->orig_node = orig_node;
neigh_node->last_seen = jiffies;
+ /* increment unique neighbor refcount */
+ kref_get(&hardif_neigh->refcount);
+ neigh_node->hardif_neigh = hardif_neigh;
+
/* extra reference for return */
kref_init(&neigh_node->refcount);
kref_get(&neigh_node->refcount);
@@ -673,9 +670,6 @@ batadv_neigh_node_new(struct batadv_orig_node *orig_node,
hlist_add_head_rcu(&neigh_node->list, &orig_node->neigh_list);
spin_unlock_bh(&orig_node->neigh_list_lock);
- /* increment unique neighbor refcount */
- kref_get(&hardif_neigh->refcount);
-
batadv_dbg(BATADV_DBG_BATMAN, orig_node->bat_priv,
"Creating new neighbor %pM for orig_node %pM on interface %s\n",
neigh_addr, orig_node->orig, hard_iface->net_dev->name);
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index 65afd090ab3e..1e47fbe8bb7b 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -433,6 +433,7 @@ struct batadv_hardif_neigh_node {
* @ifinfo_lock: lock protecting private ifinfo members and list
* @if_incoming: pointer to incoming hard-interface
* @last_seen: when last packet via this neighbor was received
+ * @hardif_neigh: hardif_neigh of this neighbor
* @refcount: number of contexts the object is used
* @rcu: struct used for freeing in an RCU-safe manner
*/
@@ -444,6 +445,7 @@ struct batadv_neigh_node {
spinlock_t ifinfo_lock; /* protects ifinfo_list and its members */
struct batadv_hard_iface *if_incoming;
unsigned long last_seen;
+ struct batadv_hardif_neigh_node *hardif_neigh;
struct kref refcount;
struct rcu_head rcu;
};
--
2.8.1
^ permalink raw reply related
* [PATCH net-next] net: relax expensive skb_unclone() in iptunnel_handle_offloads()
From: Eric Dumazet @ 2016-04-30 17:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Locally generated TCP GSO packets having to go through a GRE/SIT/IPIP
tunnel have to go through an expensive skb_unclone()
Reallocating skb->head is a lot of work.
Test should really check if a 'real clone' of the packet was done.
TCP does not care if the original gso_type is changed while the packet
travels in the stack.
This adds skb_header_unclone() which is a variant of skb_clone()
using skb_header_cloned() check instead of skb_cloned().
This variant can probably be used from other points.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/skbuff.h | 10 ++++++++++
net/ipv4/ip_tunnel_core.c | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c84a5a1078c5528bf6fc84573f63f3c6f470ce8f..c413c588a24f854be9e4df78d8a6872b6b1ff9f3 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1325,6 +1325,16 @@ static inline int skb_header_cloned(const struct sk_buff *skb)
return dataref != 1;
}
+static inline int skb_header_unclone(struct sk_buff *skb, gfp_t pri)
+{
+ might_sleep_if(gfpflags_allow_blocking(pri));
+
+ if (skb_header_cloned(skb))
+ return pskb_expand_head(skb, 0, 0, pri);
+
+ return 0;
+}
+
/**
* skb_header_release - release reference to header
* @skb: buffer to operate on
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 786fa7ca28e0db00865cdf9fab472836866b7d6d..9118b0e640ba3a96850cf28aa8caab4e615254d9 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -157,7 +157,7 @@ int iptunnel_handle_offloads(struct sk_buff *skb,
}
if (skb_is_gso(skb)) {
- err = skb_unclone(skb, GFP_ATOMIC);
+ err = skb_header_unclone(skb, GFP_ATOMIC);
if (unlikely(err))
return err;
skb_shinfo(skb)->gso_type |= gso_type_mask;
^ permalink raw reply related
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Ben Hutchings @ 2016-04-30 18:33 UTC (permalink / raw)
To: Sabrina Dubroca, Ben Greear
Cc: Hannes Frederic Sowa, linux-kernel, stable, akpm, David S. Miller,
Vijay Pandurangan, Cong Wang, netdev, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, xiyou.wangcong
In-Reply-To: <20160428102953.GA7656@bistromath.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]
On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
> Hello,
>
> 2016-04-27, 17:14:44 -0700, Ben Greear wrote:
> >
> > On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote:
> > >
> > > Hi Ben,
> > >
> > > On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote:
> > > >
> > > > On Wed, 2016-04-27 at 08:59 -0700, Ben Greear wrote:
> > > > >
> > > > > On 04/26/2016 04:02 PM, Ben Hutchings wrote:
> > > > > >
> > > > > >
> > > > > > 3.2.80-rc1 review patch. If anyone has any objections, please let me know.
> > > > > I would be careful about this. It causes regressions when sending
> > > > > PACKET_SOCKET buffers from user-space to veth devices.
> > > > >
> > > > > There was a proposed upstream fix for the regression, but it has not gone
> > > > > into the tree as far as I know.
> > > > >
> > > > > http://www.spinics.net/lists/netdev/msg370436.html
> > > > [...]
> > > >
> > > > OK, I'll drop this for now.
> > > The fall out from not having this patch is in my opinion a bigger
> > > fallout than not having this patch. This patch fixes silent data
> > > corruption vs. the problem Ben Greear is talking about, which might not
> > > be that a common usage.
> > >
> > > What do others think?
> > >
> > > Bye,
> > > Hannes
> > >
> > This patch from Cong Wang seems to fix the regression for me, I think it should be added and
> > tested in the main tree, and then apply them to stable as a pair.
> >
> > http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
> Actually, no, this is not really a regression.
[...]
It really is. Even though the old behaviour was a bug (raw packets
should not be changed), if there are real applications that depend on
that then we have to keep those applications working somehow.
Ben.
--
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Ben Hutchings @ 2016-04-30 19:18 UTC (permalink / raw)
To: Ben Greear, Sabrina Dubroca
Cc: Hannes Frederic Sowa, linux-kernel, stable, akpm, David S. Miller,
Vijay Pandurangan, Cong Wang, netdev, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, xiyou.wangcong
In-Reply-To: <5722140E.80702@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Thu, 2016-04-28 at 06:45 -0700, Ben Greear wrote:
>
> On 04/28/2016 03:29 AM, Sabrina Dubroca wrote:
[...]
> > Your use case is invalid, it just happened to work because of a
> > bug. If you want the stack to fill checksums so that you want capture
> > and reinject packets, you have to disable checksum offloading (or
> > compute the checksum yourself in userspace).
> Disabling checksum offloading or computing in user-space (and then
> recomputing in veth to verify the checksum?) is a huge performance loss.
>
> Maybe we could add a socket option to enable Cong's patch on a per-socket
> basis? That way my use-case can still work and you can have this new
> behaviour by default?
It does sound like a useful option to have. If there are other
applications that depend on veth's checksum-fixing behaviour and are
being distributed in binary form, then a per-device option might be
necessary so users can keep those applications working before they're
updated.
Ben.
--
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* __napi_alloc_skb failures locking up the box
From: Aaro Koskinen @ 2016-04-30 19:24 UTC (permalink / raw)
To: David S. Miller, netdev, linux-mm; +Cc: linux-kernel
Hi,
I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS ->
disk reliably results in temporary out-of-memory conditions.
When this happens the dmesg gets flooded with below logs. If the serial
console logging is enabled, this will lock up the box completely and
the backup is not making any progress.
Shouldn't these allocation failures be ratelimited somehow (or even made
silent)? It doesn't sound right if I can lock up the system simply by
copying files...
...
[ 1706.105842] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.105904] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.105917] Hardware name: Thecus N2100
[ 1706.105973] Workqueue: rpciod rpc_async_schedule
[ 1706.105993] Backtrace:
[ 1706.106037] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.106068] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.106142] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.106185] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.106216] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.106233] r3:02200020 r2:00000000
[ 1706.106269] r5:00000000 r4:c0524c40
[ 1706.106336] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.106352] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.106422] r4:df401d00
[ 1706.106460] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.106477] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.106547] r4:00000000
[ 1706.106581] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.106597] r10:00167e93 r9:340285ee r8:e11e1920 r7:60000013 r6:02080020 r5:df401d00
[ 1706.106668] r4:00000000
[ 1706.106707] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.106723] r7:cc592240 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.106784] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.106801] r9:340285ee r8:e11e1920 r7:cc592240 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.106903] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.106920] r7:de364000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.106986] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.107002] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.107073] r4:de3523f0
[ 1706.107131] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.107147] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.107218] r4:00000000
[ 1706.107255] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.107271] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.107341] r4:20000013
[ 1706.107380] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.107396] r5:00000000 r4:00000200
[ 1706.107459] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.107477] r5:00000000 r4:00000000
[ 1706.107538] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.107557] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.107629] r4:0000007c r3:00000001
[ 1706.107678] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.107695] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.107766] r4:deae8a80
[ 1706.107800] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.107816] r4:df471d74
[ 1706.107849] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.107873] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.107891] r5:00000000 r4:df02c780
[ 1706.107934] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.107950] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.108026] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.108043] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.108114] r4:df7eb600
[ 1706.108172] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.108192] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.108265] r4:de8e8000
[ 1706.108303] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.108321] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.108388] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.108404] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.108475] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.108493] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.108564] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.108587] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.108604] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.108675] r4:c0508940
[ 1706.108718] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.108734] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.108804] r4:de385880
[ 1706.108844] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.108861] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.108909] Mem-Info:
[ 1706.108950] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.108950] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.108950] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.108950] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.108950] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.108950] free:290 free_pcp:56 free_cma:0
[ 1706.109041] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:224kB local_pcp:224kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.109059] lowmem_reserve[]: 0 0
[ 1706.109075] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.109137] 114997 total pagecache pages
[ 1706.109154] 0 pages in swap cache
[ 1706.109168] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.109179] Free swap = 1048572kB
[ 1706.109189] Total swap = 1048572kB
[ 1706.109199] 131072 pages RAM
[ 1706.109208] 0 pages HighMem/MovableOnly
[ 1706.109218] 2469 pages reserved
[ 1706.109238] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.109255] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.109272] node 0: slabs: 12, objs: 252, free: 0
[ 1706.109320] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.109341] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.109354] Hardware name: Thecus N2100
[ 1706.109371] Workqueue: rpciod rpc_async_schedule
[ 1706.109381] Backtrace:
[ 1706.109412] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.109429] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.109500] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.109547] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.109578] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.109595] r3:02200020 r2:00000000
[ 1706.109631] r5:00000000 r4:c0524c40
[ 1706.109696] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.109715] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.109786] r4:df401d00
[ 1706.109823] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.109839] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.109909] r4:00000000
[ 1706.109943] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.109959] r10:00167e94 r9:340285ee r8:e11e1930 r7:60000013 r6:02080020 r5:df401d00
[ 1706.110030] r4:00000000
[ 1706.110069] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.110086] r7:cc593920 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.110147] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.110163] r9:340285ee r8:e11e1930 r7:cc593920 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.110267] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.110286] r7:de368000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.110352] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.110369] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.110438] r4:de3523f0
[ 1706.110499] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.110518] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.110589] r4:00000000
[ 1706.110628] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.110644] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.110714] r4:20000013
[ 1706.110754] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.110770] r5:00000000 r4:00000200
[ 1706.110833] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.110849] r5:00000000 r4:00000000
[ 1706.110906] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.110922] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.110993] r4:0000007c r3:00000001
[ 1706.111040] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.111058] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.111127] r4:deae8a80
[ 1706.111161] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.111177] r4:df471d74
[ 1706.111210] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.111236] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.111253] r5:00000000 r4:df02c780
[ 1706.111295] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.111311] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.111387] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.111403] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.111473] r4:df7eb600
[ 1706.111527] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.111549] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.111619] r4:de8e8000
[ 1706.111656] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.111672] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.111740] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.111757] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.111828] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.111844] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.111912] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.111936] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.111953] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.112023] r4:c0508940
[ 1706.112069] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.112087] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.112157] r4:de385880
[ 1706.112196] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.112212] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.112261] Mem-Info:
[ 1706.112299] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.112299] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.112299] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.112299] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.112299] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.112299] free:290 free_pcp:55 free_cma:0
[ 1706.112387] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.112406] lowmem_reserve[]: 0 0
[ 1706.112420] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.112481] 114997 total pagecache pages
[ 1706.112499] 0 pages in swap cache
[ 1706.112512] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.112522] Free swap = 1048572kB
[ 1706.112532] Total swap = 1048572kB
[ 1706.112543] 131072 pages RAM
[ 1706.112552] 0 pages HighMem/MovableOnly
[ 1706.112561] 2469 pages reserved
[ 1706.112582] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.112601] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.112617] node 0: slabs: 12, objs: 252, free: 0
[ 1706.112656] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.112677] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.112689] Hardware name: Thecus N2100
[ 1706.112707] Workqueue: rpciod rpc_async_schedule
[ 1706.112717] Backtrace:
[ 1706.112750] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.112769] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.112843] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.112884] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.112914] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.112932] r3:02200020 r2:00000000
[ 1706.112967] r5:00000000 r4:c0524c40
[ 1706.113034] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.113052] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.113122] r4:df401d00
[ 1706.113160] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.113176] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.113246] r4:00000000
[ 1706.113279] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.113297] r10:00167e95 r9:340285ee r8:e11e1940 r7:60000013 r6:02080020 r5:df401d00
[ 1706.113367] r4:00000000
[ 1706.113407] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.113425] r7:cc593240 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.113485] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.113502] r9:340285ee r8:e11e1940 r7:cc593240 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.113603] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.113623] r7:de36c000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.113689] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.113706] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.113776] r4:de3523f0
[ 1706.113832] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.113849] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.113920] r4:00000000
[ 1706.113957] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.113974] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.114044] r4:20000013
[ 1706.114083] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.114100] r5:00000000 r4:00000200
[ 1706.114160] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.114176] r5:00000000 r4:00000000
[ 1706.114236] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.114255] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.114325] r4:0000007c r3:00000001
[ 1706.114371] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.114389] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.114460] r4:deae8a80
[ 1706.114493] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.114510] r4:df471d74
[ 1706.114544] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.114569] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.114585] r5:00000000 r4:df02c780
[ 1706.114626] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.114642] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.114718] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.114734] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.114805] r4:df7eb600
[ 1706.114860] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.114880] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.114951] r4:de8e8000
[ 1706.114990] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.115006] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.115072] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.115089] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.115160] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.115176] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.115246] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.115271] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.115288] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.115359] r4:c0508940
[ 1706.115404] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.115422] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.115492] r4:de385880
[ 1706.115532] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.115548] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.115596] Mem-Info:
[ 1706.115635] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.115635] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.115635] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.115635] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.115635] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.115635] free:290 free_pcp:55 free_cma:0
[ 1706.115725] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.115744] lowmem_reserve[]: 0 0
[ 1706.115758] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.115819] 114997 total pagecache pages
[ 1706.115836] 0 pages in swap cache
[ 1706.115849] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.115859] Free swap = 1048572kB
[ 1706.115869] Total swap = 1048572kB
[ 1706.115879] 131072 pages RAM
[ 1706.115888] 0 pages HighMem/MovableOnly
[ 1706.115898] 2469 pages reserved
[ 1706.115917] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.115935] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.115950] node 0: slabs: 12, objs: 252, free: 0
[ 1706.116178] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.116220] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.116234] Hardware name: Thecus N2100
[ 1706.116269] Workqueue: rpciod rpc_async_schedule
[ 1706.116285] Backtrace:
[ 1706.116320] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.116348] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.116422] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.116462] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.116494] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.116512] r3:02200020 r2:00000000
[ 1706.116547] r5:00000000 r4:c0524c40
[ 1706.116611] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.116630] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.116701] r4:df401d00
[ 1706.116739] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.116755] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.116825] r4:00000000
[ 1706.116859] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.116876] r10:00167e96 r9:340285ee r8:e11e1950 r7:60000013 r6:02080020 r5:df401d00
[ 1706.116946] r4:00000000
[ 1706.116986] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.117003] r7:cc593920 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.117063] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.117079] r9:340285ee r8:e11e1950 r7:cc593920 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.117182] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.117203] r7:de370000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.117270] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.117287] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.117356] r4:de3523f0
[ 1706.117413] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.117430] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.117500] r4:00000000
[ 1706.117537] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.117554] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.117623] r4:20000013
[ 1706.117662] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.117678] r5:00000000 r4:00000200
[ 1706.117740] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.117757] r5:00000000 r4:00000000
[ 1706.117813] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.117831] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.117901] r4:0000007c r3:00000001
[ 1706.117947] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.117965] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.118035] r4:deae8a80
[ 1706.118070] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.118086] r4:df471d74
[ 1706.118119] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.118144] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.118161] r5:00000000 r4:df02c780
[ 1706.118202] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.118218] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.118293] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.118309] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.118380] r4:df7eb600
[ 1706.118436] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.118455] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.118528] r4:de8e8000
[ 1706.118567] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.118583] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.118649] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.118667] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.118736] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.118751] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.118821] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.118847] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.118864] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.118935] r4:c0508940
[ 1706.118980] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.118997] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.119067] r4:de385880
[ 1706.119106] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.119123] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.119171] Mem-Info:
[ 1706.119213] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.119213] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.119213] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.119213] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.119213] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.119213] free:290 free_pcp:55 free_cma:0
[ 1706.119304] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.119325] lowmem_reserve[]: 0 0
[ 1706.119341] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.119402] 114997 total pagecache pages
[ 1706.119420] 0 pages in swap cache
[ 1706.119434] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.119444] Free swap = 1048572kB
[ 1706.119454] Total swap = 1048572kB
[ 1706.119463] 131072 pages RAM
[ 1706.119473] 0 pages HighMem/MovableOnly
[ 1706.119483] 2469 pages reserved
[ 1706.119507] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.119525] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.119541] node 0: slabs: 12, objs: 252, free: 0
[ 1706.119581] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.119603] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.119616] Hardware name: Thecus N2100
[ 1706.119636] Workqueue: rpciod rpc_async_schedule
[ 1706.119646] Backtrace:
[ 1706.119678] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.119697] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.119768] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.119808] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.119839] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.119857] r3:02200020 r2:00000000
[ 1706.119893] r5:00000000 r4:c0524c40
[ 1706.119959] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.119976] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.120047] r4:df401d00
[ 1706.120084] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.120100] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.120170] r4:00000000
[ 1706.120203] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.120219] r10:00167e97 r9:340285ee r8:e11e1960 r7:60000013 r6:02080020 r5:df401d00
[ 1706.120290] r4:00000000
[ 1706.120328] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.120345] r7:cc593240 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.120405] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.120421] r9:340285ee r8:e11e1960 r7:cc593240 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.120523] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.120541] r7:de374000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.120607] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.120624] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.120694] r4:de3523f0
[ 1706.120751] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.120771] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.120842] r4:00000000
[ 1706.120879] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.120895] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.120966] r4:20000013
[ 1706.121006] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.121023] r5:00000000 r4:00000200
[ 1706.121086] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.121104] r5:00000000 r4:00000000
[ 1706.121162] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.121178] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.121249] r4:0000007c r3:00000001
[ 1706.121295] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.121313] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.121382] r4:deae8a80
[ 1706.121416] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.121432] r4:df471d74
[ 1706.121466] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.121491] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.121508] r5:00000000 r4:df02c780
[ 1706.121549] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.121566] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.121641] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.121657] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.121727] r4:df7eb600
[ 1706.121782] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.121802] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.121873] r4:de8e8000
[ 1706.121912] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.121928] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.121994] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.122011] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.122081] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.122098] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.122167] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.122192] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.122209] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.122279] r4:c0508940
[ 1706.122324] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.122341] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.122412] r4:de385880
[ 1706.122449] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.122465] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.122513] Mem-Info:
[ 1706.122553] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.122553] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.122553] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.122553] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.122553] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.122553] free:290 free_pcp:55 free_cma:0
[ 1706.122638] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.122658] lowmem_reserve[]: 0 0
[ 1706.122674] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.122734] 114997 total pagecache pages
[ 1706.122752] 0 pages in swap cache
[ 1706.122767] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.122777] Free swap = 1048572kB
[ 1706.122787] Total swap = 1048572kB
[ 1706.122796] 131072 pages RAM
[ 1706.122805] 0 pages HighMem/MovableOnly
[ 1706.122815] 2469 pages reserved
[ 1706.122835] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.122851] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.122868] node 0: slabs: 12, objs: 252, free: 0
[ 1706.122903] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.122927] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.122939] Hardware name: Thecus N2100
[ 1706.122959] Workqueue: rpciod rpc_async_schedule
[ 1706.122968] Backtrace:
[ 1706.123001] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.123019] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.123091] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.123131] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.123161] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.123177] r3:02200020 r2:00000000
[ 1706.123213] r5:00000000 r4:c0524c40
[ 1706.123279] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.123296] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.123367] r4:df401d00
[ 1706.123405] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.123421] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.123491] r4:00000000
[ 1706.123524] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.123541] r10:00167e98 r9:340285ee r8:e11e1970 r7:60000013 r6:02080020 r5:df401d00
[ 1706.123611] r4:00000000
[ 1706.123650] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.123668] r7:cc593920 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.123729] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.123745] r9:340285ee r8:e11e1970 r7:cc593920 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.123848] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.123868] r7:de378000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.123936] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.123953] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.124023] r4:de3523f0
[ 1706.124077] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.124095] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.124165] r4:00000000
[ 1706.124203] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.124218] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.124288] r4:20000013
[ 1706.124327] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.124343] r5:00000000 r4:00000200
[ 1706.124406] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.124421] r5:00000000 r4:00000000
[ 1706.124480] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.124497] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.124568] r4:0000007c r3:00000001
[ 1706.124615] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.124633] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.124704] r4:deae8a80
[ 1706.124738] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.124754] r4:df471d74
[ 1706.124787] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.124813] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.124828] r5:00000000 r4:df02c780
[ 1706.124870] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.124887] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.124963] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.124980] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.125050] r4:df7eb600
[ 1706.125106] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.125126] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.125197] r4:de8e8000
[ 1706.125234] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.125251] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.125316] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.125333] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.125402] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.125419] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.125487] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.125511] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.125528] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.125597] r4:c0508940
[ 1706.125643] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.125660] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.125730] r4:de385880
[ 1706.125767] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.125784] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.125832] Mem-Info:
[ 1706.125871] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.125871] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.125871] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.125871] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.125871] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.125871] free:290 free_pcp:55 free_cma:0
[ 1706.125956] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.125976] lowmem_reserve[]: 0 0
[ 1706.125990] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.126051] 114997 total pagecache pages
[ 1706.126068] 0 pages in swap cache
[ 1706.126081] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.126091] Free swap = 1048572kB
[ 1706.126100] Total swap = 1048572kB
[ 1706.126110] 131072 pages RAM
[ 1706.126119] 0 pages HighMem/MovableOnly
[ 1706.126128] 2469 pages reserved
[ 1706.126149] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.126168] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.126183] node 0: slabs: 12, objs: 252, free: 0
[ 1706.126360] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.126399] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.126411] Hardware name: Thecus N2100
[ 1706.126441] Workqueue: rpciod rpc_async_schedule
[ 1706.126456] Backtrace:
[ 1706.126493] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.126519] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.126594] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.126638] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.126669] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.126686] r3:02200020 r2:00000000
[ 1706.126721] r5:00000000 r4:c0524c40
[ 1706.126789] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.126807] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.126878] r4:df401d00
[ 1706.126916] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.126934] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.127003] r4:00000000
[ 1706.127037] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.127054] r10:00167e99 r9:340285ee r8:e11e1980 r7:60000013 r6:02080020 r5:df401d00
[ 1706.127124] r4:00000000
[ 1706.127162] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.127178] r7:cc593240 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.127238] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.127254] r9:340285ee r8:e11e1980 r7:cc593240 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.127354] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.127373] r7:de37c000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.127438] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.127454] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.127524] r4:de3523f0
[ 1706.127581] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.127598] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.127668] r4:00000000
[ 1706.127705] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.127722] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.127793] r4:20000013
[ 1706.127831] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.127848] r5:00000000 r4:00000200
[ 1706.127910] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.127926] r5:00000000 r4:00000000
[ 1706.127981] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.127998] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.128068] r4:0000007c r3:00000001
[ 1706.128114] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.128134] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.128204] r4:deae8a80
[ 1706.128238] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.128254] r4:df471d74
[ 1706.128287] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.128312] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.128329] r5:00000000 r4:df02c780
[ 1706.128371] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.128388] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.128463] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.128479] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.128548] r4:df7eb600
[ 1706.128607] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.128626] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.128697] r4:de8e8000
[ 1706.128737] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.128753] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.128821] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.128838] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.128909] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.128926] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.128996] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.129024] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.129041] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.129112] r4:c0508940
[ 1706.129158] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.129174] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.129243] r4:de385880
[ 1706.129281] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.129296] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.129344] Mem-Info:
[ 1706.129386] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.129386] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.129386] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.129386] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.129386] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.129386] free:290 free_pcp:55 free_cma:0
[ 1706.129475] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.129499] lowmem_reserve[]: 0 0
[ 1706.129513] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.129577] 114997 total pagecache pages
[ 1706.129595] 0 pages in swap cache
[ 1706.129607] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.129617] Free swap = 1048572kB
[ 1706.129627] Total swap = 1048572kB
[ 1706.129636] 131072 pages RAM
[ 1706.129646] 0 pages HighMem/MovableOnly
[ 1706.129655] 2469 pages reserved
[ 1706.129676] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.129694] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.129709] node 0: slabs: 12, objs: 252, free: 0
[ 1706.129748] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.129769] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.129780] Hardware name: Thecus N2100
[ 1706.129799] Workqueue: rpciod rpc_async_schedule
[ 1706.129808] Backtrace:
[ 1706.129840] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.129857] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.129927] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.129968] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.129997] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.130016] r3:02200020 r2:00000000
[ 1706.130052] r5:00000000 r4:c0524c40
[ 1706.130119] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.130137] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.130209] r4:df401d00
[ 1706.130246] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.130262] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.130333] r4:00000000
[ 1706.130367] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.130384] r10:00167e9a r9:340285ee r8:e11e1990 r7:60000013 r6:02080020 r5:df401d00
[ 1706.130454] r4:00000000
[ 1706.130495] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.130512] r7:cc593920 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.130572] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.130589] r9:340285ee r8:e11e1990 r7:cc593920 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.130687] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.130707] r7:de860000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.130777] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.130794] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.130865] r4:de3523f0
[ 1706.130922] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.130939] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.131010] r4:00000000
[ 1706.131048] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.131064] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.131134] r4:20000013
[ 1706.131173] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.131189] r5:00000000 r4:00000200
[ 1706.131251] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.131268] r5:00000000 r4:00000000
[ 1706.131324] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.131342] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.131413] r4:0000007c r3:00000001
[ 1706.131459] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.131477] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.131546] r4:deae8a80
[ 1706.131581] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.131597] r4:df471d74
[ 1706.131630] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.131655] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.131670] r5:00000000 r4:df02c780
[ 1706.131713] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.131728] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.131805] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.131821] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.131891] r4:df7eb600
[ 1706.131945] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.131963] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.132035] r4:de8e8000
[ 1706.132072] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.132088] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.132153] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.132169] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.132239] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.132256] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.132327] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.132351] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.132368] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.132439] r4:c0508940
[ 1706.132483] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.132500] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.132570] r4:de385880
[ 1706.132608] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.132625] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.132673] Mem-Info:
[ 1706.132714] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.132714] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.132714] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.132714] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.132714] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.132714] free:290 free_pcp:55 free_cma:0
[ 1706.132799] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.132820] lowmem_reserve[]: 0 0
[ 1706.132835] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.132896] 114997 total pagecache pages
[ 1706.132914] 0 pages in swap cache
[ 1706.132927] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.132937] Free swap = 1048572kB
[ 1706.132947] Total swap = 1048572kB
[ 1706.132957] 131072 pages RAM
[ 1706.132966] 0 pages HighMem/MovableOnly
[ 1706.132976] 2469 pages reserved
[ 1706.132996] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.133014] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.133029] node 0: slabs: 12, objs: 252, free: 0
[ 1706.133064] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.133087] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.133099] Hardware name: Thecus N2100
[ 1706.133118] Workqueue: rpciod rpc_async_schedule
[ 1706.133130] Backtrace:
[ 1706.133162] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.133179] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.133251] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.133292] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.133324] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.133341] r3:02200020 r2:00000000
[ 1706.133377] r5:00000000 r4:c0524c40
[ 1706.133444] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.133460] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.133531] r4:df401d00
[ 1706.133569] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.133585] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.133655] r4:00000000
[ 1706.133688] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.133705] r10:00167e9b r9:340285ee r8:e11e19a0 r7:60000013 r6:02080020 r5:df401d00
[ 1706.133775] r4:00000000
[ 1706.133816] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.133833] r7:cc593240 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.133893] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.133910] r9:340285ee r8:e11e19a0 r7:cc593240 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.134009] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.134028] r7:de864000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.134094] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.134111] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.134181] r4:de3523f0
[ 1706.134239] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.134257] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.134327] r4:00000000
[ 1706.134364] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.134380] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.134451] r4:20000013
[ 1706.134489] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.134506] r5:00000000 r4:00000200
[ 1706.134566] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.134582] r5:00000000 r4:00000000
[ 1706.134639] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.134657] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.134727] r4:0000007c r3:00000001
[ 1706.134774] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.134790] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.134860] r4:deae8a80
[ 1706.134893] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.134909] r4:df471d74
[ 1706.134943] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.134968] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.134985] r5:00000000 r4:df02c780
[ 1706.135027] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.135043] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.135118] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.135134] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.135203] r4:df7eb600
[ 1706.135260] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.135280] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.135350] r4:de8e8000
[ 1706.135388] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.135407] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.135472] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.135489] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.135560] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.135577] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.135648] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.135673] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.135690] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.135760] r4:c0508940
[ 1706.135805] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.135820] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.135890] r4:de385880
[ 1706.135928] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.135943] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.135991] Mem-Info:
[ 1706.136030] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.136030] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.136030] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.136030] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.136030] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.136030] free:290 free_pcp:55 free_cma:0
[ 1706.136116] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.136136] lowmem_reserve[]: 0 0
[ 1706.136151] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.136215] 114997 total pagecache pages
[ 1706.136232] 0 pages in swap cache
[ 1706.136245] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.136256] Free swap = 1048572kB
[ 1706.136265] Total swap = 1048572kB
[ 1706.136274] 131072 pages RAM
[ 1706.136284] 0 pages HighMem/MovableOnly
[ 1706.136293] 2469 pages reserved
[ 1706.136312] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.136331] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.136347] node 0: slabs: 12, objs: 252, free: 0
[ 1706.136517] kworker/0:1H: page allocation failure: order:0, mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.136556] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.136569] Hardware name: Thecus N2100
[ 1706.136599] Workqueue: rpciod rpc_async_schedule
[ 1706.136613] Backtrace:
[ 1706.136648] [<c000d460>] (dump_backtrace) from [<c000d658>] (show_stack+0x18/0x1c)
[ 1706.136673] r7:00000000 r6:00000060 r5:00000000 r4:00000000
[ 1706.136748] [<c000d640>] (show_stack) from [<c01c1e84>] (dump_stack+0x20/0x28)
[ 1706.136790] [<c01c1e64>] (dump_stack) from [<c007b9b0>] (warn_alloc_failed+0xf0/0x134)
[ 1706.136820] [<c007b8c4>] (warn_alloc_failed) from [<c007df78>] (__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.136837] r3:02200020 r2:00000000
[ 1706.136872] r5:00000000 r4:c0524c40
[ 1706.136937] [<c007dcf4>] (__alloc_pages_nodemask) from [<c00b1948>] (new_slab+0x3c4/0x430)
[ 1706.136955] r10:00000000 r9:c0321fdc r8:00000000 r7:df401d00 r6:00000015 r5:02000020
[ 1706.137025] r4:df401d00
[ 1706.137064] [<c00b1584>] (new_slab) from [<c00b2bd8>] (___slab_alloc.constprop.8+0x238/0x298)
[ 1706.137081] r10:00000000 r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 r5:00000000
[ 1706.137151] r4:00000000
[ 1706.137184] [<c00b29a0>] (___slab_alloc.constprop.8) from [<c00b2f68>] (kmem_cache_alloc+0xbc/0xf8)
[ 1706.137200] r10:00167e9c r9:340285ee r8:e11e19b0 r7:60000013 r6:02080020 r5:df401d00
[ 1706.137271] r4:00000000
[ 1706.137312] [<c00b2eac>] (kmem_cache_alloc) from [<c0321fdc>] (__build_skb+0x2c/0x98)
[ 1706.137329] r7:cc593920 r6:000006e0 r5:de3523f0 r4:000006e0
[ 1706.137389] [<c0321fb0>] (__build_skb) from [<c032226c>] (__napi_alloc_skb+0xb0/0xfc)
[ 1706.137405] r9:340285ee r8:e11e19b0 r7:cc593920 r6:c0520ab8 r5:de3523f0 r4:000006e0
[ 1706.137509] [<c03221bc>] (__napi_alloc_skb) from [<c028a2fc>] (rtl8169_poll+0x3a0/0x588)
[ 1706.137531] r7:de868000 r6:c000fd08 r5:000005ea r4:de3523f0
[ 1706.137598] [<c0289f5c>] (rtl8169_poll) from [<c032d098>] (net_rx_action+0x1cc/0x2ec)
[ 1706.137616] r10:00022548 r9:df471ba8 r8:c05257e0 r7:0000012c r6:00000040 r5:00000001
[ 1706.137686] r4:de3523f0
[ 1706.137744] [<c032cecc>] (net_rx_action) from [<c001bd68>] (__do_softirq+0xf4/0x254)
[ 1706.137762] r10:00000101 r9:c052618c r8:40000001 r7:c0526188 r6:df470000 r5:00000003
[ 1706.137832] r4:00000000
[ 1706.137869] [<c001bc74>] (__do_softirq) from [<c001bf58>] (do_softirq.part.2+0x34/0x40)
[ 1706.137886] r10:00000001 r9:c0525a26 r8:c05555c0 r7:00000000 r6:deae8a80 r5:00000000
[ 1706.137955] r4:20000013
[ 1706.137994] [<c001bf24>] (do_softirq.part.2) from [<c001c010>] (__local_bh_enable_ip+0xac/0xcc)
[ 1706.138009] r5:00000000 r4:00000200
[ 1706.138070] [<c001bf64>] (__local_bh_enable_ip) from [<c0319538>] (release_sock+0x12c/0x158)
[ 1706.138087] r5:00000000 r4:00000000
[ 1706.138143] [<c031940c>] (release_sock) from [<c03671b4>] (tcp_sendmsg+0xf8/0xa90)
[ 1706.138161] r10:00004040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:0000059c r5:de8ccb00
[ 1706.138231] r4:0000007c r3:00000001
[ 1706.138278] [<c03670bc>] (tcp_sendmsg) from [<c038d7f0>] (inet_sendmsg+0x3c/0x74)
[ 1706.138296] r10:df471e2c r9:00000000 r8:df7eb604 r7:00000000 r6:00000000 r5:df02c780
[ 1706.138366] r4:deae8a80
[ 1706.138400] [<c038d7b4>] (inet_sendmsg) from [<c03157f0>] (sock_sendmsg+0x1c/0x30)
[ 1706.138417] r4:df471d74
[ 1706.138451] [<c03157d4>] (sock_sendmsg) from [<c03158f4>] (kernel_sendmsg+0x38/0x40)
[ 1706.138476] [<c03158bc>] (kernel_sendmsg) from [<c03afa2c>] (xs_send_kvec+0x94/0x9c)
[ 1706.138492] r5:00000000 r4:df02c780
[ 1706.138534] [<c03af998>] (xs_send_kvec) from [<c03afaa0>] (xs_sendpages+0x6c/0x244)
[ 1706.138550] r9:00000000 r8:df02c780 r7:0000007c r6:df7eb604 r5:00000001 r4:00000000
[ 1706.138625] [<c03afa34>] (xs_sendpages) from [<c03afd7c>] (xs_tcp_send_request+0x80/0x134)
[ 1706.138641] r10:00000000 r9:00000000 r8:de8e8000 r7:de0d7258 r6:df7eb604 r5:00000001
[ 1706.138711] r4:df7eb600
[ 1706.138767] [<c03afcfc>] (xs_tcp_send_request) from [<c03ad670>] (xprt_transmit+0x58/0x214)
[ 1706.138785] r10:de92cc60 r9:00000000 r8:d3697fdd r7:df7eb674 r6:de0d7258 r5:df7eb600
[ 1706.138855] r4:de8e8000
[ 1706.138895] [<c03ad618>] (xprt_transmit) from [<c03aac74>] (call_transmit+0x18c/0x230)
[ 1706.138911] r7:df7eb600 r6:00000001 r5:df7eb600 r4:de0d7258
[ 1706.138978] [<c03aaae8>] (call_transmit) from [<c03b1ed8>] (__rpc_execute+0x54/0x2c4)
[ 1706.138994] r8:c0508940 r7:00000000 r6:c03b1f08 r5:00000001 r4:de0d7258
[ 1706.139064] [<c03b1e84>] (__rpc_execute) from [<c03b215c>] (rpc_async_schedule+0x14/0x18)
[ 1706.139080] r7:00000000 r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.139152] [<c03b2148>] (rpc_async_schedule) from [<c002c79c>] (process_one_work+0x130/0x3ec)
[ 1706.139176] [<c002c66c>] (process_one_work) from [<c002caa8>] (worker_thread+0x50/0x5ac)
[ 1706.139193] r10:de92cc60 r9:c0508940 r8:00000008 r7:c050b220 r6:c0508954 r5:de92cc78
[ 1706.139265] r4:c0508940
[ 1706.139310] [<c002ca58>] (worker_thread) from [<c00319cc>] (kthread+0xc8/0xe4)
[ 1706.139326] r10:00000000 r9:00000000 r8:00000000 r7:c002ca58 r6:de92cc60 r5:00000000
[ 1706.139396] r4:de385880
[ 1706.139434] [<c0031904>] (kthread) from [<c000a390>] (ret_from_fork+0x14/0x24)
[ 1706.139450] r7:00000000 r6:00000000 r5:c0031904 r4:de385880
[ 1706.139498] Mem-Info:
[ 1706.139539] active_anon:2694 inactive_anon:2799 isolated_anon:0
[ 1706.139539] active_file:43728 inactive_file:71243 isolated_file:0
[ 1706.139539] unevictable:0 dirty:1486 writeback:0 unstable:0
[ 1706.139539] slab_reclaimable:3099 slab_unreclaimable:710
[ 1706.139539] mapped:1763 shmem:19 pagetables:186 bounce:0
[ 1706.139539] free:290 free_pcp:55 free_cma:0
[ 1706.139630] Normal free:1160kB min:2868kB low:3584kB high:4300kB active_anon:10776kB inactive_anon:11196kB active_file:174912kB inactive_file:284972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:514412kB mlocked:0kB dirty:5944kB writeback:0kB mapped:7052kB shmem:76kB slab_reclaimable:12396kB slab_unreclaimable:2840kB kernel_stack:584kB pagetables:744kB unstable:0kB bounce:0kB free_pcp:220kB local_pcp:220kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 1706.139649] lowmem_reserve[]: 0 0
[ 1706.139664] Normal: 80*4kB (UME) 105*8kB (UE) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1160kB
[ 1706.139727] 114997 total pagecache pages
[ 1706.139745] 0 pages in swap cache
[ 1706.139758] Swap cache stats: add 0, delete 0, find 0/0
[ 1706.139768] Free swap = 1048572kB
[ 1706.139778] Total swap = 1048572kB
[ 1706.139787] 131072 pages RAM
[ 1706.139797] 0 pages HighMem/MovableOnly
[ 1706.139806] 2469 pages reserved
[ 1706.139829] SLUB: Unable to allocate memory on node -1, gfp=0x2080020(GFP_ATOMIC)
[ 1706.139847] cache: kmalloc-192, object size: 192, buffer size: 192, default order: 0, min order: 0
[ 1706.139862] node 0: slabs: 12, objs: 252, free: 0
A.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Ben Greear @ 2016-04-30 19:40 UTC (permalink / raw)
To: Ben Hutchings, Sabrina Dubroca
Cc: Hannes Frederic Sowa, linux-kernel, stable, akpm, David S. Miller,
Vijay Pandurangan, Cong Wang, netdev, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, xiyou.wangcong
In-Reply-To: <1462041181.17662.3.camel@decadent.org.uk>
On 04/30/2016 11:33 AM, Ben Hutchings wrote:
> On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
>> Hello,
>>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>> Actually, no, this is not really a regression.
> [...]
>
> It really is. Even though the old behaviour was a bug (raw packets
> should not be changed), if there are real applications that depend on
> that then we have to keep those applications working somehow.
To be honest, I fail to see why the old behaviour is a bug when sending
raw packets from user-space. If raw packets should not be changed, then
we need some way to specify what the checksum setting is to begin with,
otherwise, user-space has not enough control.
A socket option for new programs, and sysctl configurable defaults for raw sockets
for old binary programs would be sufficient I think.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: __napi_alloc_skb failures locking up the box
From: Eric Dumazet @ 2016-04-30 19:54 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: David S. Miller, netdev, linux-mm, linux-kernel
In-Reply-To: <20160430192402.GA8366@raspberrypi.musicnaut.iki.fi>
On Sat, 2016-04-30 at 22:24 +0300, Aaro Koskinen wrote:
> Hi,
>
> I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS ->
> disk reliably results in temporary out-of-memory conditions.
>
> When this happens the dmesg gets flooded with below logs. If the serial
> console logging is enabled, this will lock up the box completely and
> the backup is not making any progress.
>
> Shouldn't these allocation failures be ratelimited somehow (or even made
> silent)? It doesn't sound right if I can lock up the system simply by
> copying files...
Agreed.
All napi_alloc_skb() callers handle failure just fine.
If they did not, a NULL deref would produce a proper stack dump.
When memory gets this tight, other traces will be dumped anyway.
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 15d0df943466..0652709fe81a 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2423,7 +2423,7 @@ struct sk_buff *__napi_alloc_skb(struct napi_struct *napi,
static inline struct sk_buff *napi_alloc_skb(struct napi_struct *napi,
unsigned int length)
{
- return __napi_alloc_skb(napi, length, GFP_ATOMIC);
+ return __napi_alloc_skb(napi, length, GFP_ATOMIC | __GFP_NOWARN);
}
void napi_consume_skb(struct sk_buff *skb, int budget);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Tom Herbert @ 2016-04-30 19:54 UTC (permalink / raw)
To: Ben Greear
Cc: Ben Hutchings, Sabrina Dubroca, Hannes Frederic Sowa, LKML,
stable, akpm, David S. Miller, Vijay Pandurangan, Cong Wang,
Linux Kernel Network Developers, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, Cong Wang
In-Reply-To: <57250A17.5090804@candelatech.com>
We've put considerable effort into cleaning up the checksum interface
to make it as unambiguous as possible, please be very careful to
follow it. Broken checksum processing is really hard to detect and
debug.
CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
(indicated by csum_level) have been verified to be correct in a
packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
checksum it would refer to has not been verified and is incorrect this
is a major bug.
Tom
On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear <greearb@candelatech.com> wrote:
>
>
> On 04/30/2016 11:33 AM, Ben Hutchings wrote:
>>
>> On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
>>>
>>> Hello,
>
>
>>>>
>>>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>>>
>>> Actually, no, this is not really a regression.
>>
>> [...]
>>
>> It really is. Even though the old behaviour was a bug (raw packets
>> should not be changed), if there are real applications that depend on
>> that then we have to keep those applications working somehow.
>
>
> To be honest, I fail to see why the old behaviour is a bug when sending
> raw packets from user-space. If raw packets should not be changed, then
> we need some way to specify what the checksum setting is to begin with,
> otherwise, user-space has not enough control.
>
> A socket option for new programs, and sysctl configurable defaults for raw
> sockets
> for old binary programs would be sufficient I think.
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Vijay Pandurangan @ 2016-04-30 20:15 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: Ben Greear, Hannes Frederic Sowa, Ben Hutchings, LKML, stable,
akpm, David S. Miller, Cong Wang, Linux Kernel Network Developers,
Evan Jones, Nicolas Dichtel, Phil Sutter, Toshiaki Makita,
Cong Wang
In-Reply-To: <20160428102953.GA7656@bistromath.localdomain>
[oops – resending this because I was using gmail in HTML mode before
by accident]
There was a discussion on a separate thread about this. I agree with
Sabrina fully. I believe veth should provide an abstraction layer that
correctly emulates a physical network in all ways.
Consider an environment where we have multiple physical computers.
Each computer runs one or more containers, each of which has a
publicly routable ip address. When adding a new app to the cluster, a
scheduler might decide to run this container on any physical machine
of its choice, assuming that apps have a way of routing traffic to
their backends (we did something similar Google >10 years ago). This
is something we might imagine happening with docker and ipv6 for
instance.
If you have an app, A, which sends raw ethernet frames (the simplest
case I could imagine) with TCP data that has invalid checksums to app
B, which is receiving it, the behaviour of the system _will be
different_ depending upon whether app B is scheduled to run on the
same machine as app A or not. This seems like a clear bug and a broken
abstraction (especially as the default case), and something we should
endeavour to avoid.
I do see Ben's point about enabling sw checksum verification as
potentially incurring a huge performance penalty (I haven't had a
chance to measure it) that is completely wasteful in the vast majority
of cases.
Unfortunately I just don't see how we can solve this problem in a way
that preserves a correct abstraction layer while also avoiding excess
work. I guess the first piece of data that would be helpful is to
determine just how big of a performance penalty this is. If it's
small, then maybe it doesn't matter.
On Thu, Apr 28, 2016 at 6:29 AM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> Hello,
>
> 2016-04-27, 17:14:44 -0700, Ben Greear wrote:
>> On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote:
>> > Hi Ben,
>> >
>> > On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote:
>> > > On Wed, 2016-04-27 at 08:59 -0700, Ben Greear wrote:
>> > > > On 04/26/2016 04:02 PM, Ben Hutchings wrote:
>> > > > >
>> > > > > 3.2.80-rc1 review patch. If anyone has any objections, please let me know.
>> > > > I would be careful about this. It causes regressions when sending
>> > > > PACKET_SOCKET buffers from user-space to veth devices.
>> > > >
>> > > > There was a proposed upstream fix for the regression, but it has not gone
>> > > > into the tree as far as I know.
>> > > >
>> > > > http://www.spinics.net/lists/netdev/msg370436.html
>> > > [...]
>> > >
>> > > OK, I'll drop this for now.
>> >
>> > The fall out from not having this patch is in my opinion a bigger
>> > fallout than not having this patch. This patch fixes silent data
>> > corruption vs. the problem Ben Greear is talking about, which might not
>> > be that a common usage.
>> >
>> > What do others think?
>> >
>> > Bye,
>> > Hannes
>> >
>>
>> This patch from Cong Wang seems to fix the regression for me, I think it should be added and
>> tested in the main tree, and then apply them to stable as a pair.
>>
>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>
> Actually, no, this is not really a regression.
>
> If you capture packets on a device with checksum offloading enabled,
> the TCP/UDP checksum isn't filled. veth also behaves that way. What
> the "veth: don't modify ip_summed" patch does is enable proper
> checksum validation on veth. This really was a bug in veth.
>
> Cong's patch would also break cases where we choose to inject packets
> with invalid checksums, and they would now be accepted as correct.
>
> Your use case is invalid, it just happened to work because of a
> bug. If you want the stack to fill checksums so that you want capture
> and reinject packets, you have to disable checksum offloading (or
> compute the checksum yourself in userspace).
>
> Thanks.
>
> --
> Sabrina
^ permalink raw reply
* [PATCH] pxa168_eth: fix mdiobus_scan() error check
From: Sergei Shtylyov @ 2016-04-30 20:35 UTC (permalink / raw)
To: netdev; +Cc: arnd
In-Reply-To: <19240252.825Vlx6L0H@wasted.cogentembedded.com>
Since mdiobus_scan() returns either an error code or NULL on error, the
driver should check for both, not only for NULL, otherwise a crash is
imminent...
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net.git' repo.
drivers/net/ethernet/marvell/pxa168_eth.c | 2 ++
1 file changed, 2 insertions(+)
Index: net/drivers/net/ethernet/marvell/pxa168_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/marvell/pxa168_eth.c
+++ net/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -979,6 +979,8 @@ static int pxa168_init_phy(struct net_de
return 0;
pep->phy = mdiobus_scan(pep->smi_bus, pep->phy_addr);
+ if (IS_ERR(pep->phy))
+ return PTR_ERR(pep->phy);
if (!pep->phy)
return -ENODEV;
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Ben Greear @ 2016-04-30 20:59 UTC (permalink / raw)
To: Tom Herbert
Cc: Ben Hutchings, Sabrina Dubroca, Hannes Frederic Sowa, LKML,
stable, akpm, David S. Miller, Vijay Pandurangan, Cong Wang,
Linux Kernel Network Developers, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, Cong Wang
In-Reply-To: <CALx6S36cqecPH+Zd8pGVdFHRi7bmWgAwm2UgFVprt5JOuO47UA@mail.gmail.com>
On 04/30/2016 12:54 PM, Tom Herbert wrote:
> We've put considerable effort into cleaning up the checksum interface
> to make it as unambiguous as possible, please be very careful to
> follow it. Broken checksum processing is really hard to detect and
> debug.
>
> CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
> (indicated by csum_level) have been verified to be correct in a
> packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
> never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
> checksum it would refer to has not been verified and is incorrect this
> is a major bug.
Suppose I know that the packet received on a packet-socket has
already been verified by a NIC that supports hardware checksumming.
Then, I want to transmit it on a veth interface using a second
packet socket. I do not want veth to recalculate the checksum on
transmit, nor to validate it on the peer veth on receive, because I do
not want to waste the CPU cycles. I am assuming that my app is not
accidentally corrupting frames, so the checksum can never be bad.
How should the checksumming be configured for the packets going into
the packet-socket from user-space?
Also, I might want to send raw frames that do have
broken checksums (lets assume a real NIC, not veth), and I want them
to hit the wire with those bad checksums.
How do I configure the checksumming in this case?
Thanks,
Ben
>
> Tom
>
> On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 04/30/2016 11:33 AM, Ben Hutchings wrote:
>>>
>>> On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
>>>>
>>>> Hello,
>>
>>
>>>>>
>>>>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>>>>
>>>> Actually, no, this is not really a regression.
>>>
>>> [...]
>>>
>>> It really is. Even though the old behaviour was a bug (raw packets
>>> should not be changed), if there are real applications that depend on
>>> that then we have to keep those applications working somehow.
>>
>>
>> To be honest, I fail to see why the old behaviour is a bug when sending
>> raw packets from user-space. If raw packets should not be changed, then
>> we need some way to specify what the checksum setting is to begin with,
>> otherwise, user-space has not enough control.
>>
>> A socket option for new programs, and sysctl configurable defaults for raw
>> sockets
>> for old binary programs would be sufficient I think.
>>
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Vijay Pandurangan @ 2016-04-30 21:13 UTC (permalink / raw)
To: Ben Greear
Cc: Tom Herbert, Ben Hutchings, Sabrina Dubroca, Hannes Frederic Sowa,
LKML, stable, akpm, David S. Miller, Cong Wang,
Linux Kernel Network Developers, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, Cong Wang
In-Reply-To: <57251CB3.1040504@candelatech.com>
On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear <greearb@candelatech.com> wrote:
>
>
> On 04/30/2016 12:54 PM, Tom Herbert wrote:
>>
>> We've put considerable effort into cleaning up the checksum interface
>> to make it as unambiguous as possible, please be very careful to
>> follow it. Broken checksum processing is really hard to detect and
>> debug.
>>
>> CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
>> (indicated by csum_level) have been verified to be correct in a
>> packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
>> never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
>> checksum it would refer to has not been verified and is incorrect this
>> is a major bug.
>
>
> Suppose I know that the packet received on a packet-socket has
> already been verified by a NIC that supports hardware checksumming.
>
> Then, I want to transmit it on a veth interface using a second
> packet socket. I do not want veth to recalculate the checksum on
> transmit, nor to validate it on the peer veth on receive, because I do
> not want to waste the CPU cycles. I am assuming that my app is not
> accidentally corrupting frames, so the checksum can never be bad.
>
> How should the checksumming be configured for the packets going into
> the packet-socket from user-space?
It seems like that only the receiver should decide whether or not to
checksum packets on the veth, not the sender.
How about:
We could add a receiving socket option for "don't checksum packets
received from a veth when the other side has marked them as
elide-checksum-suggested" (similar to UDP_NOCHECKSUM), and a sending
socket option for "mark all data sent via this socket to a veth as
elide-checksum-suggested".
So the process would be:
Writer:
1. open read socket
2. open write socket, with option elide-checksum-for-veth-suggested
3. write data
Reader:
1. open read socket with "follow-elide-checksum-suggestions-on-veth"
2. read data
The kernel / module would then need to persist the flag on all packets
that traverse a veth, and drop these data when they leave the veth
module.
>
>
> Also, I might want to send raw frames that do have
> broken checksums (lets assume a real NIC, not veth), and I want them
> to hit the wire with those bad checksums.
>
>
> How do I configure the checksumming in this case?
Correct me if I'm wrong but I think this is already possible now. You
can have packets with incorrect checksum hitting the wire as is. What
you cannot do is instruct the receiving end to ignore the checksum
from the sending end when using a physical device (and something I
think we should mimic on the sending device).
>
>
>
> Thanks,
> Ben
>
>
>
>>
>> Tom
>>
>> On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear <greearb@candelatech.com> wrote:
>>>
>>>
>>>
>>> On 04/30/2016 11:33 AM, Ben Hutchings wrote:
>>>>
>>>>
>>>> On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>
>>>
>>>
>>>>>>
>>>>>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>>>>>
>>>>>
>>>>> Actually, no, this is not really a regression.
>>>>
>>>>
>>>> [...]
>>>>
>>>> It really is. Even though the old behaviour was a bug (raw packets
>>>> should not be changed), if there are real applications that depend on
>>>> that then we have to keep those applications working somehow.
>>>
>>>
>>>
>>> To be honest, I fail to see why the old behaviour is a bug when sending
>>> raw packets from user-space. If raw packets should not be changed, then
>>> we need some way to specify what the checksum setting is to begin with,
>>> otherwise, user-space has not enough control.
>>>
>>> A socket option for new programs, and sysctl configurable defaults for raw
>>> sockets
>>> for old binary programs would be sufficient I think.
>>>
>>>
>>> Thanks,
>>> Ben
>>>
>>> --
>>> Ben Greear <greearb@candelatech.com>
>>> Candela Technologies Inc http://www.candelatech.com
>>
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Ben Greear @ 2016-04-30 21:29 UTC (permalink / raw)
To: Vijay Pandurangan
Cc: Tom Herbert, Ben Hutchings, Sabrina Dubroca, Hannes Frederic Sowa,
LKML, stable, akpm, David S. Miller, Cong Wang,
Linux Kernel Network Developers, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, Cong Wang
In-Reply-To: <CAKUBDd-_5RouHduHvjOqgOpyAArEBd80BEy4KBDPLRQoTtWb2Q@mail.gmail.com>
On 04/30/2016 02:13 PM, Vijay Pandurangan wrote:
> On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 04/30/2016 12:54 PM, Tom Herbert wrote:
>>>
>>> We've put considerable effort into cleaning up the checksum interface
>>> to make it as unambiguous as possible, please be very careful to
>>> follow it. Broken checksum processing is really hard to detect and
>>> debug.
>>>
>>> CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
>>> (indicated by csum_level) have been verified to be correct in a
>>> packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
>>> never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
>>> checksum it would refer to has not been verified and is incorrect this
>>> is a major bug.
>>
>>
>> Suppose I know that the packet received on a packet-socket has
>> already been verified by a NIC that supports hardware checksumming.
>>
>> Then, I want to transmit it on a veth interface using a second
>> packet socket. I do not want veth to recalculate the checksum on
>> transmit, nor to validate it on the peer veth on receive, because I do
>> not want to waste the CPU cycles. I am assuming that my app is not
>> accidentally corrupting frames, so the checksum can never be bad.
>>
>> How should the checksumming be configured for the packets going into
>> the packet-socket from user-space?
>
>
> It seems like that only the receiver should decide whether or not to
> checksum packets on the veth, not the sender.
>
> How about:
>
> We could add a receiving socket option for "don't checksum packets
> received from a veth when the other side has marked them as
> elide-checksum-suggested" (similar to UDP_NOCHECKSUM), and a sending
> socket option for "mark all data sent via this socket to a veth as
> elide-checksum-suggested".
>
> So the process would be:
>
> Writer:
> 1. open read socket
> 2. open write socket, with option elide-checksum-for-veth-suggested
> 3. write data
>
> Reader:
> 1. open read socket with "follow-elide-checksum-suggestions-on-veth"
> 2. read data
>
> The kernel / module would then need to persist the flag on all packets
> that traverse a veth, and drop these data when they leave the veth
> module.
I'm not sure this works completely. In my app, the packet flow might be:
eth0 <-> raw-socket <-> user-space-bridge <-> raw-socket <-> vethA <-> vethB <-> [kernel router/bridge logic ...] <-> eth1
There may be no sockets on the vethB port. And reader/writer is not
a good way to look at it since I am implementing a bi-directional bridge in
user-space and each packet-socket is for both rx and tx.
>> Also, I might want to send raw frames that do have
>> broken checksums (lets assume a real NIC, not veth), and I want them
>> to hit the wire with those bad checksums.
>>
>>
>> How do I configure the checksumming in this case?
>
>
> Correct me if I'm wrong but I think this is already possible now. You
> can have packets with incorrect checksum hitting the wire as is. What
> you cannot do is instruct the receiving end to ignore the checksum
> from the sending end when using a physical device (and something I
> think we should mimic on the sending device).
Yes, it does work currently (or, last I checked)...I just want to make sure it keeps working.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Vijay Pandurangan @ 2016-04-30 21:36 UTC (permalink / raw)
To: Ben Greear
Cc: Tom Herbert, Ben Hutchings, Sabrina Dubroca, Hannes Frederic Sowa,
LKML, stable, akpm, David S. Miller, Cong Wang,
Linux Kernel Network Developers, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, Cong Wang
In-Reply-To: <572523C4.4080307@candelatech.com>
On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear <greearb@candelatech.com> wrote:
>
>
> On 04/30/2016 02:13 PM, Vijay Pandurangan wrote:
>>
>> On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear <greearb@candelatech.com>
>> wrote:
>>>
>>>
>>>
>>> On 04/30/2016 12:54 PM, Tom Herbert wrote:
>>>>
>>>>
>>>> We've put considerable effort into cleaning up the checksum interface
>>>> to make it as unambiguous as possible, please be very careful to
>>>> follow it. Broken checksum processing is really hard to detect and
>>>> debug.
>>>>
>>>> CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
>>>> (indicated by csum_level) have been verified to be correct in a
>>>> packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
>>>> never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
>>>> checksum it would refer to has not been verified and is incorrect this
>>>> is a major bug.
>>>
>>>
>>>
>>> Suppose I know that the packet received on a packet-socket has
>>> already been verified by a NIC that supports hardware checksumming.
>>>
>>> Then, I want to transmit it on a veth interface using a second
>>> packet socket. I do not want veth to recalculate the checksum on
>>> transmit, nor to validate it on the peer veth on receive, because I do
>>> not want to waste the CPU cycles. I am assuming that my app is not
>>> accidentally corrupting frames, so the checksum can never be bad.
>>>
>>> How should the checksumming be configured for the packets going into
>>> the packet-socket from user-space?
>>
>>
>>
>> It seems like that only the receiver should decide whether or not to
>> checksum packets on the veth, not the sender.
>>
>> How about:
>>
>> We could add a receiving socket option for "don't checksum packets
>> received from a veth when the other side has marked them as
>> elide-checksum-suggested" (similar to UDP_NOCHECKSUM), and a sending
>> socket option for "mark all data sent via this socket to a veth as
>> elide-checksum-suggested".
>>
>> So the process would be:
>>
>> Writer:
>> 1. open read socket
>> 2. open write socket, with option elide-checksum-for-veth-suggested
>> 3. write data
>>
>> Reader:
>> 1. open read socket with "follow-elide-checksum-suggestions-on-veth"
>> 2. read data
>>
>> The kernel / module would then need to persist the flag on all packets
>> that traverse a veth, and drop these data when they leave the veth
>> module.
>
>
> I'm not sure this works completely. In my app, the packet flow might be:
>
> eth0 <-> raw-socket <-> user-space-bridge <-> raw-socket <-> vethA <-> vethB
> <-> [kernel router/bridge logic ...] <-> eth1
Good point, so if you had:
eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
userspace-stub <->eth1
and user-space hub enabled this elide flag, things would work, right?
Then, it seems like what we need is a way to tell the kernel
router/bridge logic to follow elide signals in packets coming from
veth. I'm not sure what the best way to do this is because I'm less
familiar with conventions in that part of the kernel, but assuming
there's a way to do this, would it be acceptable?
>
> There may be no sockets on the vethB port. And reader/writer is not
> a good way to look at it since I am implementing a bi-directional bridge in
> user-space and each packet-socket is for both rx and tx.
Sure, but we could model a bidrectional connection as two
unidirectional sockets for our discussions here, right?
>
>>> Also, I might want to send raw frames that do have
>>> broken checksums (lets assume a real NIC, not veth), and I want them
>>> to hit the wire with those bad checksums.
>>>
>>>
>>> How do I configure the checksumming in this case?
>>
>>
>>
>> Correct me if I'm wrong but I think this is already possible now. You
>> can have packets with incorrect checksum hitting the wire as is. What
>> you cannot do is instruct the receiving end to ignore the checksum
>> from the sending end when using a physical device (and something I
>> think we should mimic on the sending device).
>
>
> Yes, it does work currently (or, last I checked)...I just want to make sure
> it keeps working.
Yeah, good point. It would be great if we could write a test, or at
the very least, a list of invariants about what kinds of things should
work somewhere.
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: New DSA design for cross-chip operations
From: Andrew Lunn @ 2016-04-30 21:38 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, Florian Fainelli, David S. Miller, Jiri Pirko, kernel
In-Reply-To: <1570407369.390644.1461965624673.JavaMail.zimbra@savoirfairelinux.com>
On Fri, Apr 29, 2016 at 05:33:44PM -0400, Vivien Didelot wrote:
> Hi,
>
> Here's a proposal for a new design of DSA. It is meant to discuss the
> actual state and future implementation of the D (for distributed) in
> DSA, which consists of supporting several interconnected switch chips,
> exposed to the user as one big switch unit.
>
> There's still a lot of work to finish in DSA before running into
> cross-chip operations, but it'll help to start thinking about it now.
Hi Vivien
One thing we should keep in mind. Very few switch chips actually
support D in DSA. In fact, at the moment, i don't know of any other
than Marvell. The Broadcom SF2 does not. The Microchip LAN935X
don't. The Micrel KS8995 does not. Do any of the switches supported by
OpenWRT via swconfig?
We should try to limit adding complexity to the DSA core and the API
to the drivers which the majority of drivers will never need. I would
make use of the layering we already have. For the Marvell devices, add
a cross chip layer between the Marvell drivers and the DSA core. And
even then, we might want to keep this layer optional for Marvell
devices. There are only a few niche boards with multiple switch
chips. There are many more WiFi access points and cable modems, etc,
with just a single switch.
Andrew
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Ben Greear @ 2016-04-30 21:52 UTC (permalink / raw)
To: Vijay Pandurangan
Cc: Tom Herbert, Ben Hutchings, Sabrina Dubroca, Hannes Frederic Sowa,
LKML, stable, akpm, David S. Miller, Cong Wang,
Linux Kernel Network Developers, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, Cong Wang
In-Reply-To: <CAKUBDd8fksttZOW3T5zdKD4rzbcZzZer-DCMMsA2zKF4A_hXQw@mail.gmail.com>
On 04/30/2016 02:36 PM, Vijay Pandurangan wrote:
> On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 04/30/2016 02:13 PM, Vijay Pandurangan wrote:
>>>
>>> On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear <greearb@candelatech.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 04/30/2016 12:54 PM, Tom Herbert wrote:
>>>>>
>>>>>
>>>>> We've put considerable effort into cleaning up the checksum interface
>>>>> to make it as unambiguous as possible, please be very careful to
>>>>> follow it. Broken checksum processing is really hard to detect and
>>>>> debug.
>>>>>
>>>>> CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
>>>>> (indicated by csum_level) have been verified to be correct in a
>>>>> packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
>>>>> never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
>>>>> checksum it would refer to has not been verified and is incorrect this
>>>>> is a major bug.
>>>>
>>>>
>>>>
>>>> Suppose I know that the packet received on a packet-socket has
>>>> already been verified by a NIC that supports hardware checksumming.
>>>>
>>>> Then, I want to transmit it on a veth interface using a second
>>>> packet socket. I do not want veth to recalculate the checksum on
>>>> transmit, nor to validate it on the peer veth on receive, because I do
>>>> not want to waste the CPU cycles. I am assuming that my app is not
>>>> accidentally corrupting frames, so the checksum can never be bad.
>>>>
>>>> How should the checksumming be configured for the packets going into
>>>> the packet-socket from user-space?
>>>
>>>
>>>
>>> It seems like that only the receiver should decide whether or not to
>>> checksum packets on the veth, not the sender.
>>>
>>> How about:
>>>
>>> We could add a receiving socket option for "don't checksum packets
>>> received from a veth when the other side has marked them as
>>> elide-checksum-suggested" (similar to UDP_NOCHECKSUM), and a sending
>>> socket option for "mark all data sent via this socket to a veth as
>>> elide-checksum-suggested".
>>>
>>> So the process would be:
>>>
>>> Writer:
>>> 1. open read socket
>>> 2. open write socket, with option elide-checksum-for-veth-suggested
>>> 3. write data
>>>
>>> Reader:
>>> 1. open read socket with "follow-elide-checksum-suggestions-on-veth"
>>> 2. read data
>>>
>>> The kernel / module would then need to persist the flag on all packets
>>> that traverse a veth, and drop these data when they leave the veth
>>> module.
>>
>>
>> I'm not sure this works completely. In my app, the packet flow might be:
>>
>> eth0 <-> raw-socket <-> user-space-bridge <-> raw-socket <-> vethA <-> vethB
>> <-> [kernel router/bridge logic ...] <-> eth1
>
> Good point, so if you had:
>
> eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
> userspace-stub <->eth1
>
> and user-space hub enabled this elide flag, things would work, right?
> Then, it seems like what we need is a way to tell the kernel
> router/bridge logic to follow elide signals in packets coming from
> veth. I'm not sure what the best way to do this is because I'm less
> familiar with conventions in that part of the kernel, but assuming
> there's a way to do this, would it be acceptable?
You cannot receive on one veth without transmitting on the other, so
I think the elide csum logic can go on the raw-socket, and apply to packets
in the transmit-from-user-space direction. Just allowing the socket to make
the veth behave like it used to before this patch in question should be good
enough, since that worked for us for years. So, just an option to modify the
ip_summed for pkts sent on a socket is probably sufficient.
>> There may be no sockets on the vethB port. And reader/writer is not
>> a good way to look at it since I am implementing a bi-directional bridge in
>> user-space and each packet-socket is for both rx and tx.
>
> Sure, but we could model a bidrectional connection as two
> unidirectional sockets for our discussions here, right?
Best not to I think, you want to make sure that one socket can
correctly handle tx and rx. As long as that works, then using
uni-directional sockets should work too.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
From: Vijay Pandurangan @ 2016-04-30 22:01 UTC (permalink / raw)
To: Ben Greear
Cc: Tom Herbert, Ben Hutchings, Sabrina Dubroca, Hannes Frederic Sowa,
LKML, stable, akpm, David S. Miller, Cong Wang,
Linux Kernel Network Developers, Evan Jones, Nicolas Dichtel,
Phil Sutter, Toshiaki Makita, Cong Wang
In-Reply-To: <57252918.7070302@candelatech.com>
On Sat, Apr 30, 2016 at 5:52 PM, Ben Greear <greearb@candelatech.com> wrote:
>>
>> Good point, so if you had:
>>
>> eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
>> userspace-stub <->eth1
>>
>> and user-space hub enabled this elide flag, things would work, right?
>> Then, it seems like what we need is a way to tell the kernel
>> router/bridge logic to follow elide signals in packets coming from
>> veth. I'm not sure what the best way to do this is because I'm less
>> familiar with conventions in that part of the kernel, but assuming
>> there's a way to do this, would it be acceptable?
>
>
> You cannot receive on one veth without transmitting on the other, so
> I think the elide csum logic can go on the raw-socket, and apply to packets
> in the transmit-from-user-space direction. Just allowing the socket to make
> the veth behave like it used to before this patch in question should be good
> enough, since that worked for us for years. So, just an option to modify
> the
> ip_summed for pkts sent on a socket is probably sufficient.
I don't think this is right. Consider:
- App A sends out corrupt packets 50% of the time and discards inbound data.
- App B doesn't care about corrupt packets and is happy to receive
them and has some way of dealing with them (special case)
- App C is a regular app, say nc or something.
In your world, where A decides what happens to data it transmits,
then
A<--veth-->B and A<---wire-->B will have the same behaviour
but
A<-- veth --> C and A<-- wire --> C will have _different_ behaviour: C
will behave incorrectly if it's connected over veth but correctly if
connected with a wire. That is a bug.
Since A cannot know what the app it's talking to will desire, I argue
that both sides of a message must be opted in to this optimization.
>
>>> There may be no sockets on the vethB port. And reader/writer is not
>>> a good way to look at it since I am implementing a bi-directional bridge
>>> in
>>> user-space and each packet-socket is for both rx and tx.
>>
>>
>> Sure, but we could model a bidrectional connection as two
>> unidirectional sockets for our discussions here, right?
>
>
> Best not to I think, you want to make sure that one socket can
> correctly handle tx and rx. As long as that works, then using
> uni-directional sockets should work too.
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ 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