* [PATCH] net: core: Fix race by protecting process_queues at CPU hotplug
From: subashab @ 2015-01-15 3:13 UTC (permalink / raw)
To: netdev
I am seeing frequent crashes in high throughput conditions in a
multiprocessor system with kernel version 3.10 where cores are getting hot
plugged. I have pinned the network stack to a particular core using
receive packet steering (RPS). At the time of crash, it looks like a
contention of the process_queue between dev_cpu_callback and
process_backlog.
The following is the log at the moment of the crash
75241.598056: <6> Unable to handle kernel NULL pointer dereference at
virtual address 00000004
75241.598064: <6> pgd = c0004000
75241.598072: <2> [00000004] *pgd=00000000
75241.598082: <6> Internal error: Oops: 817 [#1] PREEMPT SMP ARM
75241.598096: <2> Modules linked in: wlan(O) [last unloaded: wlan]
75241.598106: <6> CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W
O 3.10.49-g0b78c2e-00003-g2eab3e3 #1
75241.598113: <6> task: ee870a80 ti: ee888000 task.ti: ee888000
75241.598133: <2> PC is at process_backlog+0x78/0x140
75241.598142: <2> LR is at __netif_receive_skb_core+0x6fc/0x724
Here is the call stack involved in the crash
-006|__skb_unlink
-006|__skb_dequeue
-006|dev_cpu_callback
-007|notifier_call_chain
-008|__raw_notifier_call_chain
-009|notifier_to_errno
-009|__cpu_notify
-010|cpu_notify_nofail
-011|check_for_tasks
-011|cpu_down
-012|disable_nonboot_cpus()
-013|suspend_enter
-013|suspend_devices_and_enter
-014|enter_state
-014|pm_suspend
-015|state_store
-016|kobj_attr_store
-017|flush_write_buffer
-017|sysfs_write_file
-018|vfs_write
-019|SYSC_write
-019|sys_write
-020|ret_fast_syscall
I have a fix in mind in which the process queues are protected using spin
locks. I do not observe the crash with this patch. Since this patch is in
the hot path for incoming packet processing, I would like some reviews of
this patch. I would also like to know if there are any potential
performance bottlenecks due to this change.
net: core: Protect process_queues at CPU hotplug
When a CPU is hotplugged while processing incoming packets,
dev_cpu_callback() will copy the poll list from the offline
CPU and raise the softIRQ. In the same context, it will also
process process_queue of the offline CPU by de-queueing and
calling netif_rx. Due to this there is a potential for race
condition between process_backlog() and dev_cpu_callback()
accessing the same process_queue resource. This patch
protects this concurrent access by locking.
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
diff --git a/net/core/dev.c b/net/core/dev.c
index df0b522..aa8f503 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3640,6 +3640,7 @@ static void flush_backlog(void *arg)
struct net_device *dev = arg;
struct softnet_data *sd = &__get_cpu_var(softnet_data);
struct sk_buff *skb, *tmp;
+ unsigned long flags;
rps_lock(sd);
skb_queue_walk_safe(&sd->input_pkt_queue, skb, tmp) {
@@ -3651,6 +3652,7 @@ static void flush_backlog(void *arg)
}
rps_unlock(sd);
+ spin_lock_irqsave(&sd->process_queue.lock, flags);
skb_queue_walk_safe(&sd->process_queue, skb, tmp) {
if (skb->dev == dev) {
__skb_unlink(skb, &sd->process_queue);
@@ -3658,6 +3660,7 @@ static void flush_backlog(void *arg)
input_queue_head_incr(sd);
}
}
+ spin_unlock_irqrestore(&sd->process_queue.lock, flags);
}
static int napi_gro_complete(struct sk_buff *skb)
@@ -4021,7 +4024,7 @@ static int process_backlog(struct napi_struct *napi,
int quota)
{
int work = 0;
struct softnet_data *sd = container_of(napi, struct softnet_data,
backlog);
-
+ unsigned long flags;
#ifdef CONFIG_RPS
/* Check if we have pending ipi, its better to send them now,
* not waiting net_rx_action() end.
@@ -4032,18 +4035,19 @@ static int process_backlog(struct napi_struct
*napi, int quota)
}
#endif
napi->weight = weight_p;
- local_irq_disable();
+ spin_lock_irqsave(&sd->process_queue.lock, flags);
while (work < quota) {
struct sk_buff *skb;
unsigned int qlen;
while ((skb = __skb_dequeue(&sd->process_queue))) {
- local_irq_enable();
+ spin_unlock_irqrestore(&sd->process_queue.lock,
flags);
__netif_receive_skb(skb);
- local_irq_disable();
+ spin_lock_irqsave(&sd->process_queue.lock, flags);
input_queue_head_incr(sd);
if (++work >= quota) {
- local_irq_enable();
+
spin_unlock_irqrestore(&sd->process_queue.lock,
+ flags);
return work;
}
}
@@ -4054,6 +4058,7 @@ static int process_backlog(struct napi_struct *napi,
int quota)
skb_queue_splice_tail_init(&sd->input_pkt_queue,
&sd->process_queue);
+
if (qlen < quota - work) {
/*
* Inline a custom version of __napi_complete().
@@ -4069,7 +4074,7 @@ static int process_backlog(struct napi_struct *napi,
int quota)
}
rps_unlock(sd);
}
- local_irq_enable();
+ spin_unlock_irqrestore(&sd->process_queue.lock, flags);
return work;
}
@@ -5991,6 +5996,7 @@ static int dev_cpu_callback(struct notifier_block *nfb,
struct sk_buff *skb;
unsigned int cpu, oldcpu = (unsigned long)ocpu;
struct softnet_data *sd, *oldsd;
+ unsigned long flags;
if (action != CPU_DEAD && action != CPU_DEAD_FROZEN)
return NOTIFY_OK;
@@ -6024,11 +6030,15 @@ static int dev_cpu_callback(struct notifier_block
*nfb,
raise_softirq_irqoff(NET_TX_SOFTIRQ);
local_irq_enable();
+ spin_lock_irqsave(&oldsd->process_queue.lock, flags);
/* Process offline CPU's input_pkt_queue */
while ((skb = __skb_dequeue(&oldsd->process_queue))) {
+ spin_unlock_irqrestore(&oldsd->process_queue.lock, flags);
netif_rx(skb);
+ spin_lock_irqsave(&oldsd->process_queue.lock, flags);
input_queue_head_incr(oldsd);
}
+ spin_unlock_irqrestore(&oldsd->process_queue.lock, flags);
while ((skb = __skb_dequeue(&oldsd->input_pkt_queue))) {
netif_rx(skb);
input_queue_head_incr(oldsd);
Thanks
KS
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH 1/5] vxlan: Group Policy extension
From: Thomas Graf @ 2015-01-15 3:20 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, Jesse Gross, Stephen Hemminger, Pravin B Shelar,
Alexei Starovoitov, Nicolas Dichtel, Linux Netdev List,
dev@openvswitch.org
In-Reply-To: <CA+mtBx9QV89vb+kwY4PUnemwqq-vWgpU4paDEs0FjYVDS2MsXQ@mail.gmail.com>
On 01/14/15 at 07:06pm, Tom Herbert wrote:
> > +struct vxlan_metadata {
> > + __be32 vni;
> > + u32 gbp;
>
> Should this be __be32 also and use ntohl/htonl when setting to/from skb->mark?
The bitmask is stored in host byte order in vxlan_metadata to be
compatible with skb->mark and converted to network byte order on
the wire, see:
gbp = (struct vxlanhdr_gbp *)vxh;
md.gbp = ntohs(gbp->policy_id);
and:
gbp->policy_id = htons(md->gbp & VXLAN_GBP_ID_MASK);
^ permalink raw reply
* Re: [net-next PATCH v2 03/12] net: flow: implement flow cache for get routines
From: John Fastabend @ 2015-01-15 3:21 UTC (permalink / raw)
To: Thomas Graf; +Cc: simon.horman, sfeldma, netdev, gerlitz.or, jhs, andy, davem
In-Reply-To: <20150114215232.GF2105@casper.infradead.org>
On 01/14/2015 01:52 PM, Thomas Graf wrote:
> On 01/13/15 at 01:36pm, John Fastabend wrote:
>> I chose rhashtable to get the dynamic resizing. I could use arrays
>> but I don't want to pre-allocate large cache tables when we may
>> never use them.
>>
>> One oddity in the rhashtable implementation is there is no way
>> AFAICS to do delayed free's so we use rcu_sync heavily. This should be
>> fine, get operations shouldn't be a used heavily.
>
> John, can you please clarify a bit, I'm not sure I understand. Are you
> talking about delayed freeing of the table itself or elements?
>
> The Netlink usage would be an example of a user with delayed element
> freeing.
>
> I'm glad to add whatever is required.
>
Took another look at the netlink code looks like this is the correct
pattern where the call_rcu implements the delayed freeing after a grace
period.
mutex_lock(&my_hash_lock);
rhashtable_remove(&my_hash, &my_obj->rhash_head);
mutex_unlock(&my_hash_lock)
[...]
call_rcu(&my_obj->rcu, deferred_my_obj_free);
anyways it looks like it is there no problem after all and I don't
recall what I was thinking thanks for bearing with me. I'll convert
this code to avoid the over-use of rcu_sync.
Thanks,
John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v2 03/12] net: flow: implement flow cache for get routines
From: Thomas Graf @ 2015-01-15 3:24 UTC (permalink / raw)
To: John Fastabend
Cc: simon.horman, sfeldma, netdev, gerlitz.or, jhs, andy, davem
In-Reply-To: <54B7323D.9030506@gmail.com>
On 01/14/15 at 07:21pm, John Fastabend wrote:
> anyways it looks like it is there no problem after all and I don't
> recall what I was thinking thanks for bearing with me. I'll convert
> this code to avoid the over-use of rcu_sync.
It's likely that you looked at this before the per bucket lock work
occured. That's when the Netlink rhashtable code was converted to RCU
with the rhashtable API changed accordingly.
^ permalink raw reply
* [PATCH net-next v2] bridge: fix setlink/dellink notifications
From: roopa @ 2015-01-15 4:02 UTC (permalink / raw)
To: netdev
Cc: shemminger, vyasevic, john.fastabend, tgraf, jhs, sfeldma, jiri,
wkok, ronen.arad
From: Roopa Prabhu <roopa@cumulusnetworks.com>
problems with bridge getlink/setlink notifications today:
- bridge setlink generates two notifications to userspace
- one from the bridge driver
- one from rtnetlink.c (rtnl_bridge_notify)
- dellink generates one notification from rtnetlink.c. Which
means bridge setlink and dellink notifications are not
consistent
- Looking at the code it appears,
If both BRIDGE_FLAGS_MASTER and BRIDGE_FLAGS_SELF were set,
the size calculation in rtnl_bridge_notify can be wrong.
Example: if you set both BRIDGE_FLAGS_MASTER and BRIDGE_FLAGS_SELF
in a setlink request to rocker dev, rtnl_bridge_notify will
allocate skb for one set of bridge attributes, but,
both the bridge driver and rocker dev will try to add
attributes resulting in twice the number of attributes
being added to the skb. (rocker dev calls ndo_dflt_bridge_getlink)
There are multiple options:
1) Generate one notification including all attributes from master and self:
But, I don't think it will work, because both master and self may use
the same attributes/policy. Cannot pack the same set of attributes in a
single notification from both master and slave (duplicate attributes).
2) Generate one notification from master and the other notification from
self (This seems to be ideal):
For master: the master driver will send notification (bridge in this
example)
For self: the self driver will send notification (rocker in the above
example. It can use helpers from rtnetlink.c to do so. Like the
ndo_dflt_bridge_getlink api).
This patch implements 2) (leaving the 'rtnl_bridge_notify' around to be used
with 'self').
v1->v2 :
- rtnl_bridge_notify is now called only for self,
so, remove 'BRIDGE_FLAGS_SELF' check and cleanup a few things
- rtnl_bridge_dellink used to always send a RTM_NEWLINK msg
earlier. So, I have changed the notification from br_dellink to
go as RTM_NEWLINK
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
net/bridge/br_netlink.c | 5 +++++
net/core/rtnetlink.c | 45 +++++++++++++++++++++------------------------
2 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 9f5eb55..f996324 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -432,6 +432,11 @@ int br_dellink(struct net_device *dev, struct nlmsghdr *nlh)
err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
afspec, RTM_DELLINK);
+ if (err == 0)
+ /* Send RTM_NEWLINK because userspace
+ * expects RTM_NEWLINK for vlan dels
+ */
+ br_ifinfo_notify(RTM_NEWLINK, p);
return err;
}
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d06107d..acefd60 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2863,32 +2863,24 @@ static inline size_t bridge_nlmsg_size(void)
+ nla_total_size(sizeof(u16)); /* IFLA_BRIDGE_MODE */
}
-static int rtnl_bridge_notify(struct net_device *dev, u16 flags)
+static int rtnl_bridge_notify(struct net_device *dev)
{
struct net *net = dev_net(dev);
- struct net_device *br_dev = netdev_master_upper_dev_get(dev);
struct sk_buff *skb;
int err = -EOPNOTSUPP;
+ if (!dev->netdev_ops->ndo_bridge_getlink)
+ return 0;
+
skb = nlmsg_new(bridge_nlmsg_size(), GFP_ATOMIC);
if (!skb) {
err = -ENOMEM;
goto errout;
}
- if ((!flags || (flags & BRIDGE_FLAGS_MASTER)) &&
- br_dev && br_dev->netdev_ops->ndo_bridge_getlink) {
- err = br_dev->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev, 0);
- if (err < 0)
- goto errout;
- }
-
- if ((flags & BRIDGE_FLAGS_SELF) &&
- dev->netdev_ops->ndo_bridge_getlink) {
- err = dev->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev, 0);
- if (err < 0)
- goto errout;
- }
+ err = dev->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev, 0);
+ if (err < 0)
+ goto errout;
rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, GFP_ATOMIC);
return 0;
@@ -2958,16 +2950,18 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh)
err = -EOPNOTSUPP;
else
err = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
-
- if (!err)
+ if (!err) {
flags &= ~BRIDGE_FLAGS_SELF;
+
+ /* Generate event to notify upper layer of bridge
+ * change
+ */
+ err = rtnl_bridge_notify(dev);
+ }
}
if (have_flags)
memcpy(nla_data(attr), &flags, sizeof(flags));
- /* Generate event to notify upper layer of bridge change */
- if (!err)
- err = rtnl_bridge_notify(dev, oflags);
out:
return err;
}
@@ -3032,15 +3026,18 @@ static int rtnl_bridge_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
else
err = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
- if (!err)
+ if (!err) {
flags &= ~BRIDGE_FLAGS_SELF;
+
+ /* Generate event to notify upper layer of bridge
+ * change
+ */
+ err = rtnl_bridge_notify(dev);
+ }
}
if (have_flags)
memcpy(nla_data(attr), &flags, sizeof(flags));
- /* Generate event to notify upper layer of bridge change */
- if (!err)
- err = rtnl_bridge_notify(dev, oflags);
out:
return err;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
From: Joe Perches @ 2015-01-15 4:39 UTC (permalink / raw)
To: Ding Tianhong
Cc: arnd, robh+dt, davem, grant.likely, agraf, sergei.shtylyov,
linux-arm-kernel, eric.dumazet, xuwei5, zhangfei.gao, netdev,
devicetree, linux
In-Reply-To: <1421217254-12008-4-git-send-email-dingtianhong@huawei.com>
On Wed, 2015-01-14 at 14:34 +0800, Ding Tianhong wrote:
> Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller.
> The controller has no tx done interrupt, reclaim xmitted buffer in the poll.
Mostly trivial comments:
> +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
[]
> +#define GMAC_MAX_PKT_LEN 1516
[]
> +static int hip04_rx_poll(struct napi_struct *napi, int budget)
> +{
[]
> + while (cnt && !last) {
[]
> + desc = (struct rx_desc *)skb->data;
> + len = be16_to_cpu(desc->pkt_len);
> + err = be32_to_cpu(desc->pkt_err);
> +
> + if (0 == len) {
> + dev_kfree_skb_any(skb);
> + last = true;
> + } else if ((err & RX_PKT_ERR) || (len >= GMAC_MAX_PKT_LEN)) {
Is this ">=" correct? Maybe it should be ">" ?
[]
> +static irqreturn_t hip04_mac_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *ndev = (struct net_device *)dev_id;
Unnecessary cast of void *
[]
> +static int hip04_set_coalesce(struct net_device *netdev,
> + struct ethtool_coalesce *ec)
> +{
> + struct hip04_priv *priv = netdev_priv(netdev);
> +
> + /* Check not supported parameters */
> + if ((ec->rx_max_coalesced_frames) || (ec->rx_coalesce_usecs_irq) ||
> + (ec->rx_max_coalesced_frames_irq) || (ec->tx_coalesce_usecs_irq) ||
> + (ec->use_adaptive_rx_coalesce) || (ec->use_adaptive_tx_coalesce) ||
> + (ec->pkt_rate_low) || (ec->rx_coalesce_usecs_low) ||
> + (ec->rx_max_coalesced_frames_low) || (ec->tx_coalesce_usecs_high) ||
> + (ec->tx_max_coalesced_frames_low) || (ec->pkt_rate_high) ||
> + (ec->tx_coalesce_usecs_low) || (ec->rx_coalesce_usecs_high) ||
> + (ec->rx_max_coalesced_frames_high) || (ec->rx_coalesce_usecs) ||
> + (ec->tx_max_coalesced_frames_irq) ||
> + (ec->stats_block_coalesce_usecs) ||
> + (ec->tx_max_coalesced_frames_high) || (ec->rate_sample_interval))
> + return -EOPNOTSUPP;
Rather than a somewhat haphazard mix of these values,
this might be simpler to read as something like:
/* Check not supported parameters */
if (ec->pkt_rate_low ||
ec->pkt_rate_high ||
ec->use_adaptive_rx_coalesce ||
ec->rx_coalesce_usecs ||
ec->rx_coalesce_usecs_low ||
ec->rx_coalesce_usecs_high ||
ec->rx_coalesce_usecs_irq ||
ec->rx_max_coalesced_frames ||
ec->rx_max_coalesced_frames_low ||
ec->rx_max_coalesced_frames_high ||
ec->rx_max_coalesced_frames_irq ||
ec->use_adaptive_tx_coalesce ||
ec->tx_coalesce_usecs_low ||
ec->tx_coalesce_usecs_high ||
ec->tx_max_coalesced_frames_low ||
ec->tx_max_coalesced_frames_high ||
ec->tx_max_coalesced_frames_irq ||
ec->stats_block_coalesce_usecs ||
ec->rate_sample_interval)
return -EOPNOTSUPP;
> +static void hip04_free_ring(struct net_device *ndev, struct device *d)
> +{
> + struct hip04_priv *priv = netdev_priv(ndev);
> + int i;
> +
> + for (i = 0; i < RX_DESC_NUM; i++)
> + if (priv->rx_buf[i])
> + put_page(virt_to_head_page(priv->rx_buf[i]));
It's generally nicer to use braces around
for loops with single ifs.
> +
> + for (i = 0; i < TX_DESC_NUM; i++)
> + if (priv->tx_skb[i])
> + dev_kfree_skb_any(priv->tx_skb[i]);
^ permalink raw reply
* Re: [PATCH iproute2] ss: Filter inet dgram sockets with established state by default
From: Vadim Kochan @ 2015-01-15 4:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20150114184806.56a7b7e2@urahara>
So it means showing by established state by default.
On Thu, Jan 15, 2015 at 4:48 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Thu, 15 Jan 2015 00:43:47 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
>
>> On Wed, Jan 14, 2015 at 02:41:20PM -0800, Stephen Hemminger wrote:
>> > On Wed, 14 Jan 2015 08:49:44 +0200
>> > Vadim Kochan <vadim4j@gmail.com> wrote:
>> >
>> > > On Tue, Jan 13, 2015 at 05:31:50PM -0800, Stephen Hemminger wrote:
>> > > > On Thu, 8 Jan 2015 19:32:22 +0200
>> > > > Vadim Kochan <vadim4j@gmail.com> wrote:
>> > > >
>> > > > > From: Vadim Kochan <vadim4j@gmail.com>
>> > > > >
>> > > > > As inet dgram sockets (udp, raw) can call connect(...) - they
>> > > > > might be set in ESTABLISHED state. So keep the original behaviour of
>> > > > > 'ss' which filtered them by ESTABLISHED state by default. So:
>> > > > >
>> > > > > $ ss -u
>> > > > >
>> > > > > or
>> > > > >
>> > > > > $ ss -w
>> > > > >
>> > > > > Will show only ESTABLISHED UDP sockets by default.
>> > > > >
>> > > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>> > > > > ---
>> > > > > misc/ss.c | 4 ++--
>> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
>> > > > >
>> > > > > diff --git a/misc/ss.c b/misc/ss.c
>> > > > > index 08d210a..015d829 100644
>> > > > > --- a/misc/ss.c
>> > > > > +++ b/misc/ss.c
>> > > > > @@ -170,11 +170,11 @@ static const struct filter default_dbs[MAX_DB] = {
>> > > > > .families = (1 << AF_INET) | (1 << AF_INET6),
>> > > > > },
>> > > > > [UDP_DB] = {
>> > > > > - .states = (1 << SS_CLOSE),
>> > > > > + .states = (1 << SS_ESTABLISHED),
>> > > > > .families = (1 << AF_INET) | (1 << AF_INET6),
>> > > > > },
>> > > > > [RAW_DB] = {
>> > > > > - .states = (1 << SS_CLOSE),
>> > > > > + .states = (1 << SS_ESTABLISHED),
>> > > > > .families = (1 << AF_INET) | (1 << AF_INET6),
>> > > > > },
>> > > > > [UNIX_DG_DB] = {
>> > > >
>> > > > This is a change likely to break somebody using 'ss -u' now and the bound
>> > > > sockets will disappear from the output.
>> > > >
>> > >
>> > > But thats was as original behaviour before I added table-driven code
>> > > (about few commits ago), so thats a rather fix (sorry I did not noticed
>> > > about it) to keep the previous behaviour for dgram sockets - show
>> > > established states by default.
>> > >
>> > > Regards,
>> >
>> > Ok, I will merge it and update the comments.
>> Even with this PATCH I am still confused what is preferred behaviour -
>> show established dgram sockets (as it was all the way) or closed + established by default.
>>
>> What do you think ?
>>
>> Thanks,
>
> Make it work like earliest releases (like 3 months ago).
^ permalink raw reply
* RE: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: Sriharsha Basavapatna @ 2015-01-15 4:59 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Netdev List
In-Reply-To: <CA+mtBx9Kd8JM53RJFJ_R-ZW_FN=UhDQgBNgLNPqadGA9o3ZNiA@mail.gmail.com>
-----Original Message-----
From: Tom Herbert [mailto:therbert@google.com]
Sent: Thursday, January 15, 2015 8:00 AM
To: Sriharsha Basavapatna
Cc: Linux Netdev List
Subject: Re: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
On Thu, Jan 15, 2015 at 2:38 AM, Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com> wrote:
> Other tunnels like GRE break while VxLAN offloads are enabled in
> Skyhawk-R. To avoid this, we should restrict offload features on a
> per-packet basis in such conditions.
>
> Signed-off-by: Sriharsha Basavapatna
> <sriharsha.basavapatna@emulex.com>
> ---
> v2 changes: fixed minor nits pointed out by Sergei Shtylyov
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 41 +++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
> b/drivers/net/ethernet/emulex/benet/be_main.c
> index 41a0a54..d48806b 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -4383,8 +4383,9 @@ static int be_ndo_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> * distinguish various types of transports (VxLAN, GRE, NVGRE ..). So, offload
> * is expected to work across all types of IP tunnels once exported. Skyhawk
> * supports offloads for either VxLAN or NVGRE, exclusively. So we
> export VxLAN
> - * offloads in hw_enc_features only when a VxLAN port is added. Note
> this only
> - * ensures that other tunnels work fine while VxLAN offloads are not enabled.
> + * offloads in hw_enc_features only when a VxLAN port is added. If
> + other (non
> + * VxLAN) tunnels are configured while VxLAN offloads are enabled,
> + offloads for
> + * those other tunnels are unexported on the fly through ndo_features_check().
> *
> * Skyhawk supports VxLAN offloads only for one UDP dport. So, if the stack
> * adds more than one port, disable offloads and don't re-enable them
> again @@ -4463,7 +4464,41 @@ static netdev_features_t be_features_check(struct sk_buff *skb,
> struct net_device *dev,
> netdev_features_t features)
> {
> - return vxlan_features_check(skb, features);
> + struct be_adapter *adapter = netdev_priv(dev);
> + u8 l4_hdr = 0;
> +
> + /* The code below restricts offload features for some tunneled packets.
> + * Offload features for normal (non tunnel) packets are unchanged.
> + */
> + if (!skb->encapsulation ||
> + !(adapter->flags & BE_FLAGS_VXLAN_OFFLOADS))
> + return features;
> +
> + /* It's an encapsulated packet and VxLAN offloads are enabled. We
> + * should disable tunnel offload features if it's not a VxLAN packet,
> + * as tunnel offloads have been enabled only for VxLAN. This is done to
> + * allow other tunneled traffic like GRE work fine while VxLAN
> + * offloads are configured in Skyhawk-R.
> + */
> + switch (vlan_get_protocol(skb)) {
> + case htons(ETH_P_IP):
> + l4_hdr = ip_hdr(skb)->protocol;
> + break;
> + case htons(ETH_P_IPV6):
> + l4_hdr = ipv6_hdr(skb)->nexthdr;
> + break;
> + default:
> + return features;
> + }
> +
> + if (l4_hdr != IPPROTO_UDP ||
I don't understand why this is needed. The only GSO type with with encapsulation allowed by device features SKB_GSO_UDP_TUNNEL. This should not be GRE for instance. Do you see cases where protocol is not UDP at this point?
[Harsha] It's needed for GRE checksum case; without this, GRE pkts are sent down without checksum by the stack, but HW
can only offload checksum for VxLAN pkts.
> + skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
> + skb->inner_protocol != htons(ETH_P_TEB) ||
> + skb_inner_mac_header(skb) - skb_transport_header(skb) !=
> + sizeof(struct udphdr) + sizeof(struct vxlanhdr))
> + return features & ~(NETIF_F_ALL_CSUM |
> + NETIF_F_GSO_MASK);
> +
> + return features;
> }
> #endif
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org More majordomo info
> at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: Tom Herbert @ 2015-01-15 5:33 UTC (permalink / raw)
To: Sriharsha Basavapatna; +Cc: Linux Netdev List
In-Reply-To: <31318D46B5DF3F4AB71CC057601E9FEB3A7F5178@CMEXMB1.ad.emulex.com>
> I don't understand why this is needed. The only GSO type with with encapsulation allowed by device features SKB_GSO_UDP_TUNNEL. This should not be GRE for instance. Do you see cases where protocol is not UDP at this point?
> [Harsha] It's needed for GRE checksum case; without this, GRE pkts are sent down without checksum by the stack, but HW
> can only offload checksum for VxLAN pkts.
>
Okay, I see that this is a problem with checksum not GSO. Please ask
your hardware guys to provide NETIF_F_HW_CSUM to avoid any more of
this unpleasantness in the future :-)
>> + skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
>> + skb->inner_protocol != htons(ETH_P_TEB) ||
>> + skb_inner_mac_header(skb) - skb_transport_header(skb) !=
>> + sizeof(struct udphdr) + sizeof(struct vxlanhdr))
>> + return features & ~(NETIF_F_ALL_CSUM |
>> + NETIF_F_GSO_MASK);
>> +
>> + return features;
>> }
>> #endif
>>
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org More majordomo info
>> at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: Sriharsha Basavapatna @ 2015-01-15 5:45 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Netdev List
In-Reply-To: <CA+mtBx-tLRi21Sveh-TOmMC0T2cRNqcaEOx2thnqhU-ZLyaN2A@mail.gmail.com>
-----Original Message-----
From: Tom Herbert [mailto:therbert@google.com]
Sent: Thursday, January 15, 2015 11:04 AM
To: Sriharsha Basavapatna
Cc: Linux Netdev List
Subject: Re: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
> I don't understand why this is needed. The only GSO type with with encapsulation allowed by device features SKB_GSO_UDP_TUNNEL. This should not be GRE for instance. Do you see cases where protocol is not UDP at this point?
> [Harsha] It's needed for GRE checksum case; without this, GRE pkts
> are sent down without checksum by the stack, but HW can only offload checksum for VxLAN pkts.
>
Okay, I see that this is a problem with checksum not GSO. Please ask your hardware guys to provide NETIF_F_HW_CSUM to avoid any more of this unpleasantness in the future :-)
[Harsha] Ok, will do :-)
>> + skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
>> + skb->inner_protocol != htons(ETH_P_TEB) ||
>> + skb_inner_mac_header(skb) - skb_transport_header(skb) !=
>> + sizeof(struct udphdr) + sizeof(struct vxlanhdr))
>> + return features & ~(NETIF_F_ALL_CSUM |
>> + NETIF_F_GSO_MASK);
>> +
>> + return features;
>> }
>> #endif
>>
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org More majordomo
>> info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
From: Nakashima Akihiro @ 2015-01-15 5:57 UTC (permalink / raw)
To: davem@davemloft.net, netdev@vger.kernel.org
Cc: Ueda Motoki, Otsu Takahiro, Tomono Mitsunori,
linux-kernel@vger.kernel.org
Dear David and networking developers:
I got kernel panic on 3.4.105 kernel.
Please see a report below.
[1.] One line summary of the problem: [3.4] neigh_destroy() crashes on unplug netdev.
[2.] Full description of the problem/report:
I got kernel panic: neigh_destroy() crashes on unplug my wlan dongle. Please see Oops.. message for detail.
I found this problem is occured on kernel 3.4 branch, but kernel 3.6 or later do not have it.
It does not occur on every netdev device, but I think it is not a driver specific problem.
And I found 20 patches that you released on 05-Jul-2012 look effective to solve it.
Patches are below:
01. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a263b3093641fb1ec377582c90986a7fd0625184
02. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c521f2ba9646c5543963cbc2b9c9d3f02a82594
03. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=60d354ebebd9d0f760cb6c3b9f53a7ade0f8cd0e
04. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5110effee8fde2edfacac9cd12a9960ab2dc39ea
05. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f894cbf847c9bea1955095bf37aca6c050553167
06. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dbedbe6d56e8944f220e34deb9ebdf4bec2a2afd
07. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=178709bbfe9d4fe432c272ed65a34b8582703c23
08. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24db1ba866eebf5b516df80ea2212d2479bfb502
09. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b399d46b317a6d0a73ad523e014ecfa4d449769
10. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c473737765c0f72ceb5b245ada7ead798d88b4f6
11. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9d751667fd60788fe3641738938e0968e99cece
12. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13a43d94ab026c423dc8902170ef27c2bd36aa87
13. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fccd7d5c77ff61d5283e7ce8242791d5f00dcc17
14. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d248b1cf4e09dbec8cef5f7fbeda5874248bd09
15. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=534cb283efef9fdbd9f70f4615054d26aa444dd6
16. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=97cac0821af4474ec4ba3a9e7a36b98ed9b6db88
17. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f187bc6efb7250afee0e2009b6106370319b0c8b
18. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1e31fb02b31ba88d5650d97c35eb58f52bfe0e1
19. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36bdbcae2fa2a6dfa99344d4190fcea0aa7b7c25
20. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a2de86f63cfc92f7aaf11e7b9d9f2150946a1622
I applied these patches to 3.4.105 kernel, and confirmed the problem is solved on my box.
Could you confirm and backport them to 3.4 branch?
[3.] Keywords (i.e., modules, networking, kernel): networking
[4.] Kernel version (from /proc/version):
Linux version 3.4.105 (root@JP1201393) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP Tue Jan 13 13:39:40 JST 2015
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
BUG: unable to handle kernel paging request at f87be0ac
IP: [<c1475c5f>] neigh_destroy+0x8f/0x110
*pdpt = 00000000018c0001 *pde = 0000000032f7c067 *pte = 0000000000000000
Oops: 0000 [#1] SMP
Modules linked in: mt7603u_sta(0) nls_iso8859_1 bnep rfcomm bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec i915 snd_hwdep snd_pcm drm_kms_helper binfmt_misc snd_seq_midi drm snd_rawmidi snd_seq_midi_event snd_seq aesni_intel snd_timer snd_seq_device snd cryptd aes_i586 i2c_algo_bit microcode soundcore psmouse video snd_page_alloc serio_raw mac_hid ppdev parport_pc lp parport usbhid hid usb_storage ahci firewire_ohci libahci firewire_core crc_itu_te1000e
Pid: 19, comm: ksoftirqd/3 Tainted: G O 3.4.105 #1 EPSON DIRECT CORP. MR690D0F61/MR6900
EIP: 0060:[<c1475c5f>] EFLAGS: 00010206 CPU: 3
EIP is at neigh_destroy+0x8f/0x110
EAX: f87be000 EBX: f1fd461c ECX: 80150006 EDX: 00000100
ESI: f1fd4600 EDI: ec5ae000 EBP: f2d71ef4 ESP: f2d71edc
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: f87be0ac CR3: 3184b000 CR4: 000407f0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process ksoftirqd/3 (pid: 19, ti=f2d70000 task=f2d68000 task.ti=f2d70000)
Stack:
c1472b23 c1472b23 f1fd4614 ee27b0c0 00000000 00000005 f2d71f0c c1472b95
c1552da3 0000000a ee26a9c0 00000005 f2d71f14 c149292c f2d71f44 c10a80f6
f33bc0e0 0000000a f1b1cc8c f33bc0f8 c17b9ec0 f2d68000 00000000 00000003
Call Trace:
[<c1472b23>] ? dst_destroy+0x43/0xe0
[<c1472b23>] ? dst_destroy+0x43/0xe0
[<c1472b95>] dst_destroy+0xb5/0xe0
[<c1552da3>] ? _raw_spin_unlock_bh+0x13/0x20
[<c149292c>] dst_rcu_free+0x1c/0x30
[<c10a80f6>] __rcu_process_callbacks+0x186/0x310
[<c10a82bc>] rcu_process_callbacks+0x3c/0xc0
[<c1038041>] __do_softirq+0x81/0x190
[<c15533cd>] ? apic_timer_interrupt+0x31/0x38
[<c10381f8>] run_ksoftirqd+0xa8/0x130
[<c1038150>] ? __do_softirq+0x190/0x190
[<c104ff82>] kthread+0x72/0x80
[<c104ff10>] ? flush_kthread_work+0xc0/0xc0
[<c1559ebe>] kernel_thread_helper+0x6/0x10
Code: 40 04 00 00 00 00 89 51 04 89 0a e8 bc a2 fe ff 8b 03 39 c3 75 d6 8b 45 f0 e8 fe d0 0d 00 c7 46 2c 00 00 00 00 8b 87 34 01 00 00 <8b> 90 ac 00 00 00 85 d2 74 04 89 f0 ff d2 8b 87 98 02 00 00 64
EIP: [<c1475c5f>] neigh_destroy+0x8f/0x110 SS:ESP 0068:f2d71edc
CR2: 00000000f87be0ac
Kernel panic - not syncing: Fatal exception in interrupt
panic occurred, switching back to text console
call trace indicate these code line:
<c1475c5f>: net/core/neighbour.c:729
<c1472b23>: net/core/dst.c:250
<c1472b95>: include/net/neighbour.h:294
<c1552da3>: kernel/spinlock.c:194
<c149292c>: include/net/dst.h:385
[6.] A small shell script or example program which triggers the
problem (if possible)
Method to reproduce the problem:
1. run shell script below:
#/bin/sh
while [ true ]
do
ifconfig wlan0 192.168.1.2 up
done
2. unplug and plug a netdev dongle. (repeat)
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
--- ver_linux ---
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux JP1201393 3.4.105 #2 SMP Tue Jan 13 13:39:40 JST 2015 i686 i686 i386 GNU/Linux
Gnu C 4.6
Gnu make 3.81
binutils 2.22
util-linux 2.20.1
mount support
module-init-tools 3.16
e2fsprogs 1.42
pcmciautils 018
PPP 2.4.5
Linux C Library 2.15
Dynamic linker (ldd) 2.15
Procps 3.2.8
Net-tools 1.60
Kbd 1.15.2
Sh-utils 8.13
wireless-tools 30
Modules Loaded mt7603u_sta nls_iso8859_1 rfcomm bnep bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec i915 snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event drm_kms_helper aesni_intel snd_seq drm cryptd psmouse snd_timer snd_seq_device aes_i586 microcode binfmt_misc serio_raw snd soundcore snd_page_alloc i2c_algo_bit mac_hid video ppdev parport_pc lp parport usbhid hid usb_storage ahci libahci e1000e firewire_ohci firewire_core crc_itu_t
[7.2.] Processor information (from /proc/cpuinfo):
I think this is no relationship about the problem.
If it is needed, I will gather it.
[7.3.] Module information (from /proc/modules):
--- /proc/modules ---
mt7603u_sta 1114536 1 - Live 0x00000000 (O)
nls_iso8859_1 12618 1 - Live 0x00000000
rfcomm 57545 0 - Live 0x00000000
bnep 18868 2 - Live 0x00000000
bluetooth 263846 10 rfcomm,bnep, Live 0x00000000
snd_hda_codec_realtek 63163 1 - Live 0x00000000
snd_hda_intel 31907 3 - Live 0x00000000
snd_hda_codec 102579 2 snd_hda_codec_realtek,snd_hda_intel, Live 0x00000000
i915 427399 2 - Live 0x00000000
snd_hwdep 13277 1 snd_hda_codec, Live 0x00000000
snd_pcm 84645 2 snd_hda_intel,snd_hda_codec, Live 0x00000000
snd_seq_midi 13133 0 - Live 0x00000000
snd_rawmidi 25115 1 snd_seq_midi, Live 0x00000000
snd_seq_midi_event 14476 1 snd_seq_midi, Live 0x00000000
drm_kms_helper 45322 1 i915, Live 0x00000000
aesni_intel 18135 0 - Live 0x00000000
snd_seq 55404 2 snd_seq_midi,snd_seq_midi_event, Live 0x00000000
drm 215637 3 i915,drm_kms_helper, Live 0x00000000
cryptd 15580 1 aesni_intel, Live 0x00000000
psmouse 81253 0 - Live 0x00000000
snd_timer 24503 2 snd_pcm,snd_seq, Live 0x00000000
snd_seq_device 14138 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x00000000
aes_i586 16996 1 aesni_intel, Live 0x00000000
microcode 18819 0 - Live 0x00000000
binfmt_misc 17208 1 - Live 0x00000000
serio_raw 13156 0 - Live 0x00000000
snd 60917 16 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq_midi,snd_rawmidi,snd_seq,snd_timer,snd_seq_device, Live 0x00000000
soundcore 12601 1 snd, Live 0x00000000
snd_page_alloc 14037 2 snd_hda_intel,snd_pcm, Live 0x00000000
i2c_algo_bit 13198 1 i915, Live 0x00000000
mac_hid 13038 0 - Live 0x00000000
video 18688 1 i915, Live 0x00000000
ppdev 17364 0 - Live 0x00000000
parport_pc 27505 1 - Live 0x00000000
lp 13300 0 - Live 0x00000000
parport 40763 3 ppdev,parport_pc,lp, Live 0x00000000
usbhid 47307 0 - Live 0x00000000
hid 81906 1 usbhid, Live 0x00000000
usb_storage 48081 1 - Live 0x00000000
ahci 25497 2 - Live 0x00000000
libahci 25871 1 ahci, Live 0x00000000
e1000e 175750 0 - Live 0x00000000
firewire_ohci 35480 0 - Live 0x00000000
firewire_core 56954 1 firewire_ohci, Live 0x00000000
crc_itu_t 12628 1 firewire_core, Live 0x00000000
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
--- /proc/ioports ---
0000-03af : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0200-0201 : pnp 00:02
0378-037a : parport0
03b0-03df : PCI Bus 0000:00
03e0-0cf7 : PCI Bus 0000:00
03f8-03ff : serial
0400-0453 : pnp 00:0a
0400-0403 : ACPI PM1a_EVT_BLK
0404-0405 : ACPI PM1a_CNT_BLK
0408-040b : ACPI PM_TMR
0410-0415 : ACPI CPU throttle
0420-042f : ACPI GPE0_BLK
0450-0450 : ACPI PM2_CNT_BLK
0454-0457 : pnp 00:0b
0458-047f : pnp 00:0a
04d0-04d1 : pnp 00:08
0500-057f : pnp 00:0a
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1180-119f : pnp 00:0a
d000-dfff : PCI Bus 0000:04
d000-d01f : 0000:04:00.0
e000-efff : PCI Bus 0000:03
e000-e0ff : 0000:03:00.0
f000-f03f : 0000:00:02.0
f040-f05f : 0000:00:1f.3
f060-f07f : 0000:00:1f.2
f060-f07f : ahci
f080-f09f : 0000:00:19.0
f0a0-f0a3 : 0000:00:1f.2
f0a0-f0a3 : ahci
f0b0-f0b7 : 0000:00:1f.2
f0b0-f0b7 : ahci
f0c0-f0c3 : 0000:00:1f.2
f0c0-f0c3 : ahci
f0d0-f0d7 : 0000:00:1f.2
f0d0-f0d7 : ahci
--- /proc/iomem ---
00000000-0000ffff : reserved
00010000-0009d7ff : System RAM
0009d800-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000a0000-000bffff : Video RAM area
000c0000-000dffff : PCI Bus 0000:00
000c0000-000cd7ff : Video ROM
000e0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-1fffffff : System RAM
01000000-0155addd : Kernel code
0155adde-01813f3f : Kernel data
018c0000-0194bfff : Kernel bss
20000000-201fffff : reserved
20200000-3fffffff : System RAM
40000000-401fffff : reserved
40200000-bad8bfff : System RAM
bad8c000-badd8fff : ACPI Non-volatile Storage
badd9000-bade0fff : ACPI Tables
bade1000-badf5fff : reserved
badf6000-badf7fff : System RAM
badf8000-bae04fff : ACPI Non-volatile Storage
bae05000-bae2bfff : reserved
bae2c000-bae6efff : ACPI Non-volatile Storage
bae6f000-baffffff : System RAM
bb000000-bb7fffff : RAM buffer
bb800000-bf9fffff : reserved
bfa00000-ffffffff : PCI Bus 0000:00
d0000000-dfffffff : 0000:00:02.0
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : pnp 00:01
fe000000-fe3fffff : 0000:00:02.0
fe400000-fe4fffff : PCI Bus 0000:04
fe400000-fe47ffff : 0000:04:00.0
fe400000-fe47ffff : e1000e
fe480000-fe4bffff : 0000:04:00.0
fe4c0000-fe4dffff : 0000:04:00.0
fe4c0000-fe4dffff : e1000e
fe4e0000-fe4e3fff : 0000:04:00.0
fe4e0000-fe4e3fff : e1000e
fe500000-fe5fffff : PCI Bus 0000:03
fe500000-fe5007ff : 0000:03:00.0
fe500000-fe5007ff : firewire_ohci
fe600000-fe61ffff : 0000:00:19.0
fe600000-fe61ffff : e1000e
fe620000-fe623fff : 0000:00:1b.0
fe620000-fe623fff : ICH HD audio
fe624000-fe6240ff : 0000:00:1f.3
fe625000-fe6257ff : 0000:00:1f.2
fe625000-fe6257ff : ahci
fe626000-fe6263ff : 0000:00:1d.0
fe626000-fe6263ff : ehci_hcd
fe627000-fe6273ff : 0000:00:1a.0
fe627000-fe6273ff : ehci_hcd
fe628000-fe628fff : 0000:00:19.0
fe628000-fe628fff : e1000e
fe629000-fe62900f : 0000:00:16.0
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fed08000-fed08fff : pnp 00:0a
fed10000-fed19fff : pnp 00:01
fed1c000-fed1ffff : reserved
fed1c000-fed1ffff : pnp 00:0a
fed20000-fed3ffff : pnp 00:01
fed90000-fed93fff : pnp 00:01
fee00000-fee0ffff : pnp 00:01
fee00000-fee00fff : Local APIC
ff000000-ffffffff : reserved
ff000000-ffffffff : pnp 00:0a
100000000-23f7fffff : System RAM
23f800000-23fffffff : RAM buffer
[7.5.] PCI information ('lspci -vvv' as root)
I think this is no relationship about the problem.
If it is needed, I will gather it.
[7.6.] SCSI information (from /proc/scsi/scsi):
I don't think no relationship about this issue.
If it is needed, I will gather it.
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
patches I described on [2.] look effective.
Best regards,
Akihiro Nakashima
----------------------------------
NAKASHIMA Akihiro
Nakashima.Akihiro@exc.epson.co.jp
----------------------------------
^ permalink raw reply
* [MERGE] net --> net-next
From: David Miller @ 2015-01-15 6:06 UTC (permalink / raw)
To: netdev
With Linus taking in my bug fixes from 'net' I subsequently merged
his tree into 'net' and the merged 'net' into 'net-next'.
Just FYI...
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: David Miller @ 2015-01-15 6:06 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, david.vrabel
In-Reply-To: <20150115134735.1e4612c6@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 15 Jan 2015 13:47:35 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
> use different locks for Rx and Tx stats") from the net tree and commit
> a55e8bb8fb89 ("xen-netfront: refactor making Tx requests") from the
> net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks a lot Stephen, I just resolved this.
^ permalink raw reply
* Re: [PATCH 0/5 net-next v6] VXLAN Group Policy Extension
From: David Miller @ 2015-01-15 6:12 UTC (permalink / raw)
To: tgraf
Cc: jesse, stephen, pshelar, therbert, alexei.starovoitov,
nicolas.dichtel, netdev, dev
In-Reply-To: <cover.1421290198.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 15 Jan 2015 03:53:54 +0100
> Implements supports for the Group Policy VXLAN extension [0] to provide
> a lightweight and simple security label mechanism across network peers
> based on VXLAN. The security context and associated metadata is mapped
> to/from skb->mark. This allows further mapping to a SELinux context
> using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
> tc, etc.
>
> The extension is disabled by default and should be run on a distinct
> port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs
> which ignore unknown reserved bits will be able to receive VXLAN-GBP
> frames.
>
> Simple usage example:
>
> 10.1.1.1:
> # ip link add vxlan0 type vxlan id 10 remote 10.1.1.2 gbp
> # iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
>
> 10.1.1.2:
> # ip link add vxlan0 type vxlan id 10 remote 10.1.1.1 gbp
> # iptables -I INPUT -m mark --mark 0x200 -j DROP
>
> iproute2 [1] and OVS [2] support will be provided in separate patches.
>
> [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
> [1] https://github.com/tgraf/iproute2/tree/vxlan-gbp
> [2] https://github.com/tgraf/ovs/tree/vxlan-gbp
Applied, thanks a lot Thomas.
^ permalink raw reply
* Re: [PATCH 0/8] netfilter updates for net-next
From: David Miller @ 2015-01-15 6:54 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1421267689-24894-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 14 Jan 2015 21:34:41 +0100
> The following patchset contains netfilter updates for net-next, just a
> bunch of cleanups and small enhancement to selectively flush conntracks
> in ctnetlink, more specifically the patches are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks a lot Pablo.
^ permalink raw reply
* Re: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: David Miller @ 2015-01-15 6:55 UTC (permalink / raw)
To: sriharsha.basavapatna; +Cc: netdev
In-Reply-To: <1421318323-2547-1-git-send-email-sriharsha.basavapatna@emulex.com>
From: Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
Date: Thu, 15 Jan 2015 16:08:43 +0530
> Other tunnels like GRE break while VxLAN offloads are enabled in Skyhawk-R. To
> avoid this, we should restrict offload features on a per-packet basis in such
> conditions.
>
> Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: core: Fix race by protecting process_queues at CPU hotplug
From: Eric Dumazet @ 2015-01-15 7:01 UTC (permalink / raw)
To: subashab; +Cc: netdev
In-Reply-To: <75547b88b7e2d15b35339a6321c3a929.squirrel@www.codeaurora.org>
On Thu, 2015-01-15 at 03:13 +0000, subashab@codeaurora.org wrote:
> I am seeing frequent crashes in high throughput conditions in a
> multiprocessor system with kernel version 3.10 where cores are getting hot
> plugged. I have pinned the network stack to a particular core using
> receive packet steering (RPS). At the time of crash, it looks like a
> contention of the process_queue between dev_cpu_callback and
> process_backlog.
Your patch is mangled, hard to tell what is going on.
^ permalink raw reply
* Re: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
From: Eric Dumazet @ 2015-01-15 7:03 UTC (permalink / raw)
To: Nakashima Akihiro
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ueda Motoki,
Otsu Takahiro, Tomono Mitsunori, linux-kernel@vger.kernel.org
In-Reply-To: <E694983F62A0954788A62E997021A9C31093E1@JPEX011.apo.epson.net>
On Thu, 2015-01-15 at 05:57 +0000, Nakashima Akihiro wrote:
> Dear David and networking developers:
>
> I got kernel panic on 3.4.105 kernel.
> Please see a report below.
Please try a recent kernel.
We are not going to debug such an old one, given there are chances we
already fixed the problem ages ago.
Thanks
^ permalink raw reply
* Re: [patch net] team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin
From: Jiri Pirko @ 2015-01-15 7:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jbenc
In-Reply-To: <20150114.165509.1466571325244320266.davem@davemloft.net>
Wed, Jan 14, 2015 at 10:55:09PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 14 Jan 2015 18:15:30 +0100
>
>> This patch is fixing a race condition that may cause setting
>> count_pending to -1, which results in unwanted big bulk of arp messages
>> (in case of "notify peers").
>>
>> Consider following scenario:
> ...
>> Fix this race by using atomic_dec_if_positive - that will prevent
>> count_pending running under 0.
>>
>> Fixes: fc423ff00df3a1955441 ("team: add peer notification")
>> Fixes: 492b200efdd20b8fcfd ("team: add support for sending multicast rejoins")
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> Signed-off-by: Jiri Benc <jbenc@redhat.com>
>
>Applied, thanks.
>
>I am assuming that v3.12 and later need this fix, therefore I'm queueing it up for
>-stable.
Yes, thanks!
^ permalink raw reply
* Re: [patch-net-next v2 3/3] net: ethernet: cpsw: don't requests IRQs we don't use
From: Mugunthan V N @ 2015-01-15 7:49 UTC (permalink / raw)
To: Felipe Balbi, davem; +Cc: Tony Lindgren, Linux OMAP Mailing List, netdev
In-Reply-To: <1421254729-10602-3-git-send-email-balbi@ti.com>
On Wednesday 14 January 2015 10:28 PM, Felipe Balbi wrote:
> CPSW never uses RX_THRESHOLD or MISC interrupts. In
> fact, they are always kept masked in their appropriate
> IRQ Enable register.
>
> Instead of allocating an IRQ that never fires, it's best
> to remove that code altogether and let future patches
> implement it if anybody needs those.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Instead of introducing dummy ISR in previous patch and then removing in
this patch, both can be squashed into a single patch.
Regards
Mugunthan V N
^ permalink raw reply
* RE: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
From: Nakashima Akihiro @ 2015-01-15 7:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ueda Motoki,
Otsu Takahiro, Tomono Mitsunori, linux-kernel@vger.kernel.org
In-Reply-To: <1421305399.11734.40.camel@edumazet-glaptop2.roam.corp.google.com>
Dear Eric:
3.6 or later kernels (including recent mainline) do not have this problem.
3.4.105 is based on an old kernel, but it is a latest kernel of 3.4 LTS branch.
I think it is better to backport 20 patches to LTS branch.
But if you do not have such support policy, I will apply these patches to my 3.4 kernel only.
Thanks
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Thursday, January 15, 2015 4:03 PM
To: Nakashima Akihiro
Cc: davem@davemloft.net; netdev@vger.kernel.org; Ueda Motoki; Otsu Takahiro; Tomono Mitsunori; linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
On Thu, 2015-01-15 at 05:57 +0000, Nakashima Akihiro wrote:
> Dear David and networking developers:
>
> I got kernel panic on 3.4.105 kernel.
> Please see a report below.
Please try a recent kernel.
We are not going to debug such an old one, given there are chances we already fixed the problem ages ago.
Thanks
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: wstephen-sgV2jX0FEOL9JmXXK+q4OQ @ 2015-01-15 8:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Wang, jcliburn-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5550127.3sXOcCISZN@wuerfel>
Hi Arnd, Francois
The nss-gmac driver is for the internal GMAC IP in the Qualcomm IPQ806x
SoC. There are 2 ARM cores and 2 NSS cores inside the IPQ806x SoC. The
main purpose of these NSS cores is to offload the networking stack from
the ARM cores to achieve high performance at routing/ipsec..etc without
exhausting the ARM core CPU cycles. There is another nss-drv driver for
the NSS cores.
The nss-gmac driver is designed to work standalone or with the nss-drv
driver so the switchable data plane overlay was implemented. When it
worked standalone, the data plane is running on the ARM core as a standard
networking driver. The nss-drv driver can take over the data plane and
offload it to the NSS cores. The STMicro stmmac driver does not have this
kind of overlay design so is not suitable for IPQ806x. This is why we
don't based on the stmmac driver
Thanks,
Stephen
>> diff --git a/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> new file mode 100644
>> index 0000000..806f2e6
>> --- /dev/null
>> +++ b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> @@ -0,0 +1,14 @@
>> +Linux Driver for 3504 DWC Ether MAC 10/100/1000 Universal
>> +Linux Driver for 3507 DWC Ether MAC 10/100 Universal
>> +
>> +IMPORTANT: Synopsys Ethernet MAC Linux Software Drivers and
>> documentation (hereinafter, "Software") are unsupported proprietary
>> works of Synopsys, Inc. unless otherwise expressly agreed to in writing
>> between Synopsys and you.
>> +
>> +The Software uses certain Linux kernel functionality and may therefore
>> be subject to the GNU Public License which is available at:
>> +http://www.gnu.org/licenses/gpl.html
>
> It sounds like this one is related to the dwmac driver in
> drivers/net/ethernet/stmicro/stmmac/. Please move the code into
> the same directory and reuse as much as you can.
>
> If this is a completely unrelated part, it should probably go
> into drivers/net/ethernet/designware or drivers/net/ethernet/synopsys.
>
>> +#ifdef CONFIG_OF
>> +#include <msm_nss_gmac.h>
>> +#else
>> +#include <mach/msm_nss_gmac.h>
>> +#endif
>
> Drop the non-CONFIG_OF part here and elsewhere, we don't support
> separate platform directories any more, and mach-qcom is already
> DT-only.
>
>> +/**********************************************************
>> + * GMAC registers Map
>> + * For Pci based system address is BARx + gmac_register_base
>> + * For any other system translation is done accordingly
>> + **********************************************************/
>> +enum gmac_registers {
>> + gmac_config = 0x0000, /* Mac config Register */
>> + gmac_frame_filter = 0x0004, /* Mac frame filtering controls */
>> + gmac_hash_high = 0x0008, /* Multi-cast hash table high */
>> + gmac_hash_low = 0x000c, /* Multi-cast hash table low */
>> + gmac_gmii_addr = 0x0010, /* GMII address Register(ext. Phy) */
>> + gmac_gmii_data = 0x0014, /* GMII data Register(ext. Phy) */
>> + gmac_flow_control = 0x0018, /* Flow control Register */
>> + gmac_vlan = 0x001c, /* VLAN tag Register (IEEE 802.1Q) */
>> + gmac_version = 0x0020, /* GMAC Core Version Register */
>> + gmac_wakeup_addr = 0x0028, /* GMAC wake-up frame filter adrress
>> + reg */
>
> This looks a lot like dwmac1000 as well.
>
>> + if (of_property_read_u32(np, "qcom,id", &gmacdev->macid)
>> + || of_property_read_u32(np, "qcom,emulation", &gmaccfg->emulation)
>> + || of_property_read_u32(np, "qcom,phy_mii_type",
>> &gmaccfg->phy_mii_type)
>> + || of_property_read_u32(np, "qcom,phy_mdio_addr",
>> &gmaccfg->phy_mdio_addr)
>> + || of_property_read_u32(np, "qcom,rgmii_delay",
>> &gmaccfg->rgmii_delay)
>> + || of_property_read_u32(np, "qcom,poll_required",
>> &gmaccfg->poll_required)
>> + || of_property_read_u32(np, "qcom,forced_speed",
>> &gmaccfg->forced_speed)
>> + || of_property_read_u32(np, "qcom,forced_duplex",
>> &gmaccfg->forced_duplex)
>> + || of_property_read_u32(np, "qcom,irq", &netdev->irq)
>> + || of_property_read_u32(np, "qcom,socver", &gmaccfg->socver)) {
>
> This is not an acceptable way to pass data from DT, please use the
> standard properties.
>
>> + if (test_bit(__NSS_GMAC_LINKPOLL, &gmacdev->flags)) {
>> +#if (LINUX_VERSION_CODE <= KERNEL_VERSION(3, 8, 0))
>> + gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
>> + &nss_gmac_adjust_link, 0, phyif);
>> +#else
>> + gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
>> + &nss_gmac_adjust_link, phyif);
>> +#endif
>
> Drop all LINUX_VERSION_CODE checks
>
>> + if (IS_ERR_OR_NULL(gmacdev->phydev)) {
>> + netdev_dbg(netdev, "PHY %s attach FAIL", phy_id);
>> + ret = -EIO;
>> + goto nss_gmac_phy_attach_fail;
>> + }
>
> Also any IS_ERR_OR_NULL checks, you are using the API incorrectly.
>
>> +static struct of_device_id nss_gmac_dt_ids[] = {
>> + { .compatible = "qcom,nss-gmac0" },
>> + { .compatible = "qcom,nss-gmac1" },
>> + { .compatible = "qcom,nss-gmac2" },
>> + { .compatible = "qcom,nss-gmac3" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, nss_gmac_dt_ids);
>
> Are all four versions supported by this driver?
>
> Each one of these needs its own devicetree binding that documents which
> hardware it is for and what the supported DT properties are.
>
>> +static struct platform_driver nss_gmac_drv = {
>> + .probe = nss_gmac_probe,
>> + .remove = nss_gmac_remove,
>> + .driver = {
>> + .name = "nss-gmac",
>> + .owner = THIS_MODULE,
>> +#ifdef CONFIG_OF
>> + .of_match_table = of_match_ptr(nss_gmac_dt_ids),
>> +#endif
>
> The redundancy here is redundant and unnecessary.
>
>> +
>> +/**
>> + * @brief IOCTL interface.
>> + * This function is mainly for debugging purpose.
>> + * This provides hooks for Register read write, Retrieve descriptor
>> status
>> + * and Retreiving Device structure information.
>> + * @param[in] pointer to net_device structure.
>> + * @param[in] pointer to ifreq structure.
>> + * @param[in] ioctl command.
>> + * @return Returns 0 on success Error code on failure.
>> + */
>> +static int32_t nss_gmac_linux_do_ioctl(struct net_device *netdev,
>> + struct ifreq *ifr, int32_t cmd)
>> +{
>
> Remove the private ioctls.
>
>> +/**
>> + * @brief Stats Callback to receive statistics from NSS
>> + * @param[in] pointer to gmac context
>> + * @param[in] pointer to gmac statistics
>> + * @return Returns void.
>> + */
>> +static void nss_gmac_stats_receive(struct nss_gmac_dev *gmacdev,
>> + struct nss_gmac_stats *gstat)
>> +{
> ...
>> +}
>> +EXPORT_SYMBOL(nss_gmac_receive);
>
> Why multiple modules instead of linking everything together?
>
>> +
>> +/**
>> + * NSS Driver interface APIs
>> + */
>
> What is an NSS driver?
>
>> +/*
>> + * nss_gmac_open_work()
>> + * Schedule delayed work to open the netdev again
>> + */
>> +void nss_gmac_open_work(struct work_struct *work)
>> +{
>> + struct nss_gmac_dev *gmacdev = container_of(to_delayed_work(work),
>> + struct nss_gmac_dev, gmacwork);
>> +
>> + netdev_dbg(gmacdev->netdev, "Do the network up in delayed queue %s\n",
>> + gmacdev->netdev->name);
>> + nss_gmac_linux_open(gmacdev->netdev);
>> +}
>
> You seem to have an operating system abstraction layer in here. We know
> which OS we are running on, so please remove the abstraction.
>
> Arnd
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [PATCH] net: sxgbe: Fix waring for double kfree()
From: Dan Carpenter @ 2015-01-15 8:12 UTC (permalink / raw)
To: Kukjin Kim; +Cc: netdev, Dave Miller, Byungho An
In-Reply-To: <1421286191-9550-1-git-send-email-kgene@kernel.org>
On Thu, Jan 15, 2015 at 10:43:11AM +0900, Kukjin Kim wrote:
> rx_ring->rx_skbuff = kmalloc_array(rx_rsize,
> sizeof(struct sk_buff *), GFP_KERNEL);
> - if (rx_ring->rx_skbuff == NULL)
> - goto rxbuff_err;
> + if (!rx_ring->rx_skbuff) {
This is missing a dma_free_coherent() here.
> + kfree(rx_ring->rx_skbuff_dma);
> + goto error;
> + }
>
> /* initialise the buffers */
> for (desc_index = 0; desc_index < rx_rsize; desc_index++) {
> @@ -502,13 +508,6 @@ static int init_rx_ring(struct net_device *dev, u8 queue_no,
> err_init_rx_buffers:
> while (--desc_index >= 0)
> free_rx_ring(priv->device, rx_ring, desc_index);
> - kfree(rx_ring->rx_skbuff);
The double free bug is that free_rx_ring() frees
kfree(rx_ring->rx_skbuff_dma); and kfree(rx_ring->rx_skbuff); so just
calling it in a loop here will cause a double free.
Also free_rx_ring() doesn't take an index parameter, it takes a size
parameter.
The right way to fix this is to create a release function that mirrors
sxgbe_init_rx_buffers().
static void sxgbe_free_rx_buffers(struct net_device *dev,
struct sxgbe_rx_norm_desc *p, int i,
unsigned int dma_buf_sz,
struct sxgbe_rx_queue *rx_ring)
{
struct sxgbe_priv_data *priv = netdev_priv(dev);
kfree_skb(rx_ring->rx_skbuff[i]);
dma_unmap_single(priv->device, rx_ring->rx_skbuff_dma[i],
dma_buf_sz, DMA_FROM_DEVICE);
}
Then just swap that into the free loop instead of the free_rx_ring().
err_init_rx_buffers:
while (--desc_index >= 0) {
struct sxgbe_rx_norm_desc *p;
p = rx_ring->dma_rx + desc_index;
sxgbe_init_rx_buffers(dev, p, desc_index, bfsize, rx_ring);
}
kfree(rx_ring->rx_skbuff);
Something like that.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next v13 0/3] add hisilicon hip04 ethernet driver
From: Ding Tianhong @ 2015-01-15 8:37 UTC (permalink / raw)
To: Alexander Graf, arnd, robh+dt, davem, grant.likely
Cc: sergei.shtylyov, linux-arm-kernel, eric.dumazet, xuwei5,
zhangfei.gao, netdev, devicetree, linux
In-Reply-To: <54B642B4.8010807@suse.de>
On 2015/1/14 18:19, Alexander Graf wrote:
>
>
> On 14.01.15 07:34, Ding Tianhong wrote:
>> v13:
>> - Fix the problem of alignment parameters for function and checkpatch warming.
>>
>> v12:
>> - According Alex's suggestion, modify the changelog and add MODULE_DEVICE_TABLE
>> for hip04 ethernet.
>>
>> v11:
>> - Add ethtool support for tx coalecse getting and setting, the xmit_more
>> is not supported for this patch, but I think it could work for hip04,
>> will support it later after some tests for performance better.
>>
>> Here are some performance test results by ping and iperf(add tx_coalesce_frames/users),
>> it looks that the performance and latency is more better by tx_coalesce_frames/usecs.
>>
>> - Before:
>> $ ping 192.168.1.1 ...
>> === 192.168.1.1 ping statistics ===
>> 24 packets transmitted, 24 received, 0% packet loss, time 22999ms
>> rtt min/avg/max/mdev = 0.180/0.202/0.403/0.043 ms
>>
>> $ iperf -c 192.168.1.1 ...
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0- 1.0 sec 115 MBytes 945 Mbits/sec
>>
>> - After:
>> $ ping 192.168.1.1 ...
>> === 192.168.1.1 ping statistics ===
>> 24 packets transmitted, 24 received, 0% packet loss, time 22999ms
>> rtt min/avg/max/mdev = 0.178/0.190/0.380/0.041 ms
>>
>> $ iperf -c 192.168.1.1 ...
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0- 1.0 sec 115 MBytes 965 Mbits/sec
>
> Using v11 on top of 3.18 and after generating some traffic on the
> network as well as compiling code on ahci in parallel I ran into the
> following OOPS. Any idea what exactly is going on?
>
>>From a 10000 feet perspective it looks like two problems to me
>
> 1) Allocation failure doesn't get handled properly somewhere
> 2) We fail to allocate with order=0 - I don't see why
>
is it easy to repetition this bug? how big is your memory on your board, is it happened in your previous hip04 driver?
ding
>
> Alex
>
>
> [44085.652301] ld: page allocation failure: order:0, mode:0x120
> [44085.671314] CPU: 0 PID: 5121 Comm: ld Not tainted 3.18.0-5-lpae #1
> [44085.692110] [<c0335814>] (unwind_backtrace) from [<c032fcc8>]
> (show_stack+0x18/0x1c)
> [44085.718109] [<c032fcc8>] (show_stack) from [<c0a50afc>]
> (dump_stack+0x88/0x98)
> [44085.742360] [<c0a50afc>] (dump_stack) from [<c0443f98>]
> (warn_alloc_failed+0xdc/0x124)
> [44085.768938] [<c0443f98>] (warn_alloc_failed) from [<c04469ec>]
> (__alloc_pages_nodemask+0x7ac/0xa8c)
> [44085.799305] [<c04469ec>] (__alloc_pages_nodemask) from [<c0959a88>]
> (__netdev_alloc_frag+0xac/0x17c)
> [44085.829994] [<c0959a88>] (__netdev_alloc_frag) from [<bf00051c>]
> (hip04_rx_poll+0x168/0x3cc [hip04_eth])
> [44085.861830] [<bf00051c>] (hip04_rx_poll [hip04_eth]) from
> [<c096c0fc>] (net_rx_action+0x15c/0x258)
> [44085.891897] [<c096c0fc>] (net_rx_action) from [<c0369508>]
> (__do_softirq+0x138/0x2dc)
> [44085.918171] [<c0369508>] (__do_softirq) from [<c0369920>]
> (irq_exit+0x80/0xb8)
> [44085.942408] [<c0369920>] (irq_exit) from [<c03b3ee0>]
> (__handle_domain_irq+0x68/0xa8)
> [44085.968685] [<c03b3ee0>] (__handle_domain_irq) from [<c03086ac>]
> (hip04_handle_irq+0x38/0x68)
> [44085.997296] [<c03086ac>] (hip04_handle_irq) from [<c0a56d48>]
> (__irq_usr+0x48/0x60)
> [44086.022977] Exception stack(0xd3fbbfb0 to 0xd3fbbff8)
> [44086.039925] bfa0: 03fa94f8
> 01fc2598 01fc2598 00000000
> [44086.067357] bfc0: 03fa9458 40482000 00000000 400878b0 004e46e8
> 00000040 01f61f80 00000013
> [44086.094785] bfe0: fbad2488 bed4c270 403aeb5c 403bbe84 200e0010 ffffffff
> [44086.116970] Mem-info:
> [44086.124597] DMA per-cpu:
> [44086.133098] CPU 0: hi: 186, btch: 31 usd: 191
> [44086.149167] HighMem per-cpu:
> [44086.158829] CPU 0: hi: 186, btch: 31 usd: 10
> [44086.174919] active_anon:78994 inactive_anon:57435 isolated_anon:0
> [44086.174919] active_file:721847 inactive_file:559931 isolated_file:0
> [44086.174919] unevictable:20 dirty:567 writeback:0 unstable:0
> [44086.174919] free:2674014 slab_reclaimable:41072 slab_unreclaimable:5704
> [44086.174919] mapped:13107 shmem:42709 pagetables:933 bounce:0
> [44086.174919] free_cma:16216
> [44086.286552] DMA free:1088kB min:3012kB low:3764kB high:4516kB
> active_anon:584kB inactive_anon:2948kB active_file:183224kB
> inactive_file:183268kB unevictable:16kB isolated(anon):0kB
> isolated(file):0kB present:778240kB managed:569024kB mlocked:16kB
> dirty:28kB writeback:0kB mapped:864kB shmem:2948kB
> slab_reclaimable:164288kB slab_unreclaimable:22816kB kernel_stack:776kB
> pagetables:3732kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB
> pages_scanned:0 all_unreclaimable? no
> [44086.427835] lowmem_reserve[]: 0 0 15624 15624
> [44086.442687] HighMem free:10694968kB min:512kB low:21708kB
> high:42908kB active_anon:315392kB inactive_anon:226792kB
> active_file:2704164kB inactive_file:2056456kB unevictable:64kB
> isolated(anon):0kB isolated(file):0kB present:15998976kB
> managed:15998976kB mlocked:64kB dirty:2240kB writeback:0kB
> mapped:51564kB shmem:167888kB slab_reclaimable:0kB
> slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB
> bounce:59318392kB free_cma:64864kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> [44086.590672] lowmem_reserve[]: 0 0 0 0
> [44086.603158] DMA: 0*4kB 0*8kB 0*16kB 0*32kB 1*64kB (R) 0*128kB 0*256kB
> 0*512kB 1*1024kB (R) 0*2048kB 0*4096kB = 1088kB
> [44086.639330] HighMem: 6*4kB (UMC) 2*8kB (U) 3*16kB (UMC) 5*32kB (UC)
> 3*64kB (UMC) 1*128kB (C) 1*256kB (M) 57*512kB (UM) 25*1024kB (UMC)
> 7*2048kB (UMC) 2594*4096kB (MRC) = 10694968kB
> [44086.694225] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=2048kB
> [44086.722524] 1324446 total pagecache pages
> [44086.735973] 33 pages in swap cache
> [44086.747384] Swap cache stats: add 741, delete 708, find 0/0
> [44086.766072] Free swap = 497068kB
> [44086.777185] Total swap = 500032kB
> [44087.151253] 4194304 pages of RAM
> [44087.162085] 2674498 free pages
> [44087.172327] 52304 reserved pages
> [44087.183150] 46573 slab pages
> [44087.192810] 1004058 pages shared
> [44087.203632] 33 pages swap cached
> [44087.217489] Unable to handle kernel paging request at virtual address
> b0000000
> [44087.241776] pgd = c0303000
> [44087.250887] [b0000000] *pgd=80000010306003, *pmd=00000000
> [44087.269133] Internal error: Oops: 2a06 [#1] SMP ARM
> [44087.285499] Modules linked in: fuse dm_mod uio_pdrv_genirq uio
> nls_iso8859_1 nls_cp437 vfat fat sg st sr_mod cdrom af_packet squashfs
> loop virtio_blk virtio_ring virtio brd marvell ahci_platform
> libahci_platform libahci hip04_mdio gpio_dwapb hip04_eth [last unloaded:
> dm_mod]
> [44087.368299] CPU: 0 PID: 9 Comm: rcuos/0 Not tainted 3.18.0-5-lpae #1
> [44087.389614] task: e88a46c0 ti: e88ac000 task.ti: e88ac000
> [44087.407749] PC is at v7_dma_inv_range+0x34/0x4c
> [44087.422951] LR is at dma_cache_maint_page+0x9c/0x118
> [44087.439609] pc : [<c0340b94>] lr : [<c033a67c>] psr: 400e0013
> [44087.439609] sp : e88addc0 ip : c0340c2c fp : 00000002
> [44087.478104] r10: 00000000 r9 : c0e73580 r8 : c0e778c4
> [44087.495630] r7 : c0fdfb80 r6 : c0f20780 r5 : 00000000 r4 : 00000640
> [44087.517524] r3 : 0000003f r2 : 00000040 r1 : b0000640 r0 : b0000000
> [44087.539424] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM
> Segment kernel
> [44087.563939] Control: 30c5387d Table: 21305b40 DAC: fffffffd
> [44087.583213] Process rcuos/0 (pid: 9, stack limit = 0xe88ac238)
> [44087.602777] Stack: (0xe88addc0 to 0xe88ae000)
> [44087.617398] ddc0: 00000000 00000000 e88a4708 e8ae059c e8ae0000
> c0e778c4 c0fdfb80 00000640
> [44087.644829] dde0: 00000000 df7f9000 00000002 c033a91c c0340c2c
> 00000700 df9da740 e8ae059c
> [44087.672259] de00: e8ae0000 000012ac 00000038 db903700 e8ae02d8
> c0fdfb80 00000001 bf000498
> [44087.699689] de20: 00000640 00000002 00000000 c0e9c5b0 e88ac000
> 00000101 c0e7ab04 00000000
> [44087.727119] de40: 00000040 bf001e28 c0f77800 e8ae059c 00000000
> 00000040 0000012c df9da740
> [44087.754549] de60: c0e6d100 00000101 e88ac000 c096c0fc c0f245e4
> df9da748 007aae3c e88ac000
> [44087.781978] de80: c0f26038 c0f2410d e88a5850 00000003 c0e6d08c
> 00000002 e88ac000 00000002
> [44087.809407] dea0: c0f24314 00000101 e1f4d4c0 c0369508 00000000
> c0e94fd4 0000000c c0e6d080
> [44087.836837] dec0: c0e65448 0000000a c0f34000 c0e6d100 007aae3b
> e88ac030 c0a62b84 00208040
> [44087.864266] dee0: a00e0013 600e0013 df9d7680 000001ff 00000001
> df9d7744 00000000 c0e73630
> [44087.891696] df00: e1f4d4c0 c036976c e88ac010 c0369830 db903700
> df9d7680 e88ac000 c03bc8cc
> [44087.919125] df20: 00000000 d3fedb80 000b7df0 00000000 e88a46c0
> c039db48 e88adf38 e88adf38
> [44087.946554] df40: 00000000 e8838940 00000000 df9d7680 c03bc74c
> 00000000 00000000 00000000
> [44087.973984] df60: 00000000 c0380398 00000000 00000000 00000001
> df9d7680 00000000 00000000
> [44088.001413] df80: e88adf80 e88adf80 00000000 00000000 e88adf90
> e88adf90 e88adfac e8838940
> [44088.028843] dfa0: c03802b8 00000000 00000000 c032bbc8 00000000
> 00000000 00000000 00000000
> [44088.056272] dfc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [44088.083701] dfe0: 00000000 00000000 00000000 00000000 00000013
> 00000000 e88adff4 00000000
> [44088.111150] [<c0340b94>] (v7_dma_inv_range) from [<c033a67c>]
> (dma_cache_maint_page+0x9c/0x118)
> [44088.140339] [<c033a67c>] (dma_cache_maint_page) from [<c033a91c>]
> (__dma_page_dev_to_cpu+0x90/0x110)
> [44088.170996] [<c033a91c>] (__dma_page_dev_to_cpu) from [<bf000498>]
> (hip04_rx_poll+0xe4/0x3cc [hip04_eth])
> [44088.203119] [<bf000498>] (hip04_rx_poll [hip04_eth]) from
> [<c096c0fc>] (net_rx_action+0x15c/0x258)
> [44088.233185] [<c096c0fc>] (net_rx_action) from [<c0369508>]
> (__do_softirq+0x138/0x2dc)
> [44088.259457] [<c0369508>] (__do_softirq) from [<c036976c>]
> (do_softirq+0x5c/0x64)
> [44088.284270] [<c036976c>] (do_softirq) from [<c0369830>]
> (__local_bh_enable_ip+0xbc/0xc0)
> [44088.311428] [<c0369830>] (__local_bh_enable_ip) from [<c03bc8cc>]
> (rcu_nocb_kthread+0x180/0x5bc)
> [44088.340910] [<c03bc8cc>] (rcu_nocb_kthread) from [<c0380398>]
> (kthread+0xe0/0xf8)
> [44088.366026] [<c0380398>] (kthread) from [<c032bbc8>]
> (ret_from_fork+0x14/0x20)
> [44088.390260] Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36)
> [44088.410808] ---[ end trace ccf8b617d193d373 ]---
> [44088.426324] Kernel panic - not syncing: Fatal exception in interrupt
> [44088.447652] Rebooting in 100 seconds..Reboot failed -- System halted
>
> .
>
^ permalink raw reply
* Re: [ 2375.793397] WARNING: CPU: 0 PID: 1149 at net/netlink/genetlink.c:1037 genl_unbind+0xc0/0xd0()
From: Johannes Berg @ 2015-01-15 8:37 UTC (permalink / raw)
To: Jeff Layton; +Cc: netdev
In-Reply-To: <20150114212039.68c9a5a6@synchrony.poochiereds.net>
On Wed, 2015-01-14 at 21:20 -0500, Jeff Layton wrote:
> > Ok - after long deliberation I found a way to trigger it. It requires
> > that you leave a multicast group (likely by destroying a socket) at the
> > same time as the kernel unregisters the generic netlink group. I have no
> > idea what generic netlink group you might be using here, but I could
> > reproduce it with a strategically placed delay in the netlink code and
> > the nl80211 genl group by opening a socket, closing the socket, and
> > removing the cfg80211 module (to unregister the nl80211 genl group)
> > while the socket was still being closed.
> >
> > I'll think about a fix tomorrow - it doesn't seem trivial due to
> > possible locking concerns.
> FWIW, it popped around a dozen times or so?
Yeah it would pop up for every multicast group that any socket you owned
while closing the program (which of course closes the sockets) would
have opened on that genl family.
The thing that confuses me is how you managed to unregister a genl
family at literally the same time, but I cannot find - from code review
- a way to trigger it without that. If the family goes away cleanly
before then the groups of all open sockets are cleared so it can't
happen, and if the family is still alive when the socket is closed then
of course it also can't happen.
> Unfortunately, I didn't save the logs from the run. I'll try to
> reproduce it again tomorrow (and save the logs this time), but I don't
> see it every time.
If you do manage to do that it would be great to confirm that it is
indeed the scenario I found (and reproduced).
Thanks,
johannes
^ 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