* Re: [net-next PATCH v2 00/12] Flow API
From: Or Gerlitz @ 2015-01-14 15:00 UTC (permalink / raw)
To: John Fastabend
Cc: Thomas Graf, simon.horman, Scott Feldman, Linux Netdev List,
Jamal Hadi Salim, Andy Gospodarek, David Miller,
Alexei Starovoitov
In-Reply-To: <54B680EB.8040404@gmail.com>
On Wed, Jan 14, 2015 at 4:44 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
> On 01/13/2015 10:29 PM, Or Gerlitz wrote:
>>
>> On Tue, Jan 13, 2015 at 11:35 PM, John Fastabend
>> <john.fastabend@gmail.com> wrote:
>>>
>>> I tried to roll in all the feedback from v1 into this series annotated
>>> here,
>> Can you please drop V2 to your
>> https://github.com/jrfastab/rocker-net-next.git tree?
> Should be there now, but as Alexei noted I seem to have missed updating
> the patch commit messages so they still reference the old names.
Oh, I see it now.. yep, with the old names and dates to Dec 30th...
^ permalink raw reply
* Re: [net-next PATCH v2 02/12] net: flow_table: add flow, delete flow
From: John Fastabend @ 2015-01-14 14:55 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Thomas Graf, simon.horman, Scott Feldman, netdev@vger.kernel.org,
gerlitz.or@gmail.com, Jamal Hadi Salim, Andy Gospodarek,
David S. Miller
In-Reply-To: <CAADnVQK0FqxD9iu5UzFu0Pizi9tQPgjmAs3WBbV7y8jk0Sdi5w@mail.gmail.com>
On 01/13/2015 03:00 PM, Alexei Starovoitov wrote:
> On Tue, Jan 13, 2015 at 1:35 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> Now that the device capabilities are exposed we can add support to
>> add and delete flows from the tables.
>>
>> The two operations are
>>
>> table_set_flows :
>>
>> The set flow operations is used to program a set of flows into a
>> hardware device table. The message is consumed via netlink encoded
>
> should now netlink cmd be called table_set_rules ?
> and s/flow/rule/ everywhere in commit log?
>
>> message which is then decoded into a null terminated array of
>> flow entry structures. A flow entry structure is defined as
>>
>> struct net_flow_flow {
>
> commit log no longer matches implementation ;)
> should be net_flow_rule ?
>
Oops, I guess I'll update it after waiting a bit for more feedback.
> can you update your .html writeup?
Took a quick scan at this think I caught most cases and some typos
as well.
> I hope to see more real examples in there.
Sure, I'll put together some more interesting examples in the next
day or so.
>
> btw how the whole thing will work with queue splitting from
> your other patch?
>
If one of the actions supported by the device is forward_to_queue() or
forward_to_socket() we can use the API to steer potentially interesting
packets to a user space application for processing.
Going the other way applications could tell the hardware to
drop/mangle/fwd packets. At some point I thought it would be interesting
to use both the the flow API here and the queue splitting from the
other patch with a tool like Suricata.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* RE: [PATCH v2 1/1] atm: remove deprecated use of pci api
From: David Laight @ 2015-01-14 14:47 UTC (permalink / raw)
To: 'David Miller', lambert.quentin@gmail.com
Cc: chas@cmf.nrl.navy.mil, linux-atm-general@lists.sourceforge.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20150113.215944.1703977685948196746.davem@davemloft.net>
From: David Miller
> From: Quentin Lambert <lambert.quentin@gmail.com>
> Date: Mon, 12 Jan 2015 17:10:42 +0100
>
> > @@ -2246,7 +2246,8 @@ static int eni_init_one(struct pci_dev *pci_dev,
> > goto err_disable;
> >
> > zero = &eni_dev->zero;
> > - zero->addr = pci_alloc_consistent(pci_dev, ENI_ZEROES_SIZE, &zero->dma);
> > + zero->addr = dma_alloc_coherent(&pci_dev->dev, ENI_ZEROES_SIZE,
> > + &zero->dma, GFP_ATOMIC);
> > if (!zero->addr)
> > goto err_kfree;
> >
>
> I really would like you to look at these locations and see if
> GFP_KERNEL can be used instead of GFP_ATOMIC. I bet that nearly
> all of these can, and it is preferred.
And there isn't much point inlining the wrapper until that has been done.
Not only that, the corresponding pci_free_consistent() calls need changing
at (much) the same time.
David
^ permalink raw reply
* Re: [net-next PATCH v2 00/12] Flow API
From: John Fastabend @ 2015-01-14 14:44 UTC (permalink / raw)
To: Or Gerlitz
Cc: Thomas Graf, simon.horman, Scott Feldman, Linux Netdev List,
Jamal Hadi Salim, Andy Gospodarek, David Miller,
Alexei Starovoitov
In-Reply-To: <CAJ3xEMhSkHMTqvvaP2jS5Q8dh3FgqSt2JnQc+WuPeYwh0P5dkw@mail.gmail.com>
On 01/13/2015 10:29 PM, Or Gerlitz wrote:
> On Tue, Jan 13, 2015 at 11:35 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> I tried to roll in all the feedback from v1 into this series annotated
>> here,
>
> Hi John,
>
> Can you please drop V2 to your
> https://github.com/jrfastab/rocker-net-next.git tree?
>
> thanks,
>
> Or.
>
Should be there now, but as Alexei noted I seem to have missed updating
the patch commit messages so they still reference the old names.
--
John Fastabend Intel Corporation
^ permalink raw reply
* [PATCH] ixgbe: Re-enable relaxed ordering as part of init/restart sequence for non-DCA config
From: Sowmini Varadhan @ 2015-01-14 14:40 UTC (permalink / raw)
To: sowmini.varadhan, jeffrey.t.kirsher, jesse.brandeburg,
bruce.w.allan, carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
matthew.vick, john.ronciak, mitch.a.williams
Cc: linux.nics, e1000-devel, netdev, linux-kernel, sparclinux,
emil.s.tantilov
Relaxed ordering is disabled by default at driver initialization
and re-enabled when DCA is used. The reason it is disabled was
due to an issue on some chipsets (see comments in ixgbe_update_tx_dca()).
But when DCA is not used, RO needs to be re-enabled, else we have
a serialization bottleneck on platforms like SPARC.
This patch eliminates the bottleneck for ixgbe when DCA is not configured.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Cc: Emil Tantilov <emil.s.tantilov@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 20 ++++++++++++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 1 +
6 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index c5c97b4..85c7a28 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1161,6 +1161,7 @@ static struct ixgbe_mac_operations mac_ops_82598 = {
.clear_hw_cntrs = &ixgbe_clear_hw_cntrs_generic,
.get_media_type = &ixgbe_get_media_type_82598,
.enable_rx_dma = &ixgbe_enable_rx_dma_generic,
+ .enable_relaxed_ordering = &ixgbe_enable_relaxed_ordering,
.get_mac_addr = &ixgbe_get_mac_addr_generic,
.stop_adapter = &ixgbe_stop_adapter_generic,
.get_bus_info = &ixgbe_get_bus_info_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 9c66bab..4453d92 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -338,6 +338,26 @@ s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw)
return 0;
}
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw)
+{
+ u32 i;
+ u32 regval;
+
+ /* Enable relaxed ordering */
+ for (i = 0; i < hw->mac.max_tx_queues; i++) {
+ regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(i));
+ regval |= IXGBE_DCA_TXCTRL_DESC_WRO_EN;
+ IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(i), regval);
+ }
+
+ for (i = 0; i < hw->mac.max_rx_queues; i++) {
+ regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
+ regval |= (IXGBE_DCA_RXCTRL_DATA_WRO_EN |
+ IXGBE_DCA_RXCTRL_HEAD_WRO_EN);
+ IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
+ }
+}
+
/**
* ixgbe_init_hw_generic - Generic hardware initialization
* @hw: pointer to hardware structure
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index 8cfadcb..c399c18 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -37,6 +37,7 @@ s32 ixgbe_init_ops_generic(struct ixgbe_hw *hw);
s32 ixgbe_init_hw_generic(struct ixgbe_hw *hw);
s32 ixgbe_start_hw_generic(struct ixgbe_hw *hw);
s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw);
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw);
s32 ixgbe_clear_hw_cntrs_generic(struct ixgbe_hw *hw);
s32 ixgbe_read_pba_string_generic(struct ixgbe_hw *hw, u8 *pba_num,
u32 pba_num_size);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ed2c7d..dec815b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4898,6 +4898,12 @@ void ixgbe_reset(struct ixgbe_adapter *adapter)
if (test_bit(__IXGBE_PTP_RUNNING, &adapter->state))
ixgbe_ptp_reset(adapter);
+
+#ifndef CONFIG_IXGBE_DCA
+ /* ixgbe_update_tx_dca() will re-enable RO when DCA is enabled */
+ if (hw->mac.ops.enable_relaxed_ordering)
+ hw->mac.ops.enable_relaxed_ordering(hw);
+#endif
}
/**
@@ -8470,6 +8476,11 @@ skip_sriov:
"representative who provided you with this "
"hardware.\n");
}
+#ifndef CONFIG_IXGBE_DCA
+ /* ixgbe_update_tx_dca() will re-enable RO when DCA is enabled */
+ if (hw->mac.ops.enable_relaxed_ordering)
+ hw->mac.ops.enable_relaxed_ordering(hw);
+#endif
strcpy(netdev->name, "eth%d");
err = register_netdev(netdev);
if (err)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index d101b25..b967241 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -3013,6 +3013,7 @@ struct ixgbe_mac_operations {
void (*release_swfw_sync)(struct ixgbe_hw *, u32);
s32 (*prot_autoc_read)(struct ixgbe_hw *, bool *, u32 *);
s32 (*prot_autoc_write)(struct ixgbe_hw *, u32, bool);
+ void (*enable_relaxed_ordering)(struct ixgbe_hw *);
/* Link */
void (*disable_tx_laser)(struct ixgbe_hw *);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
index ba54ff0..88adad2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
@@ -781,6 +781,7 @@ static struct ixgbe_mac_operations mac_ops_X540 = {
.clear_hw_cntrs = &ixgbe_clear_hw_cntrs_generic,
.get_media_type = &ixgbe_get_media_type_X540,
.enable_rx_dma = &ixgbe_enable_rx_dma_generic,
+ .enable_relaxed_ordering = &ixgbe_enable_relaxed_ordering,
.get_mac_addr = &ixgbe_get_mac_addr_generic,
.get_san_mac_addr = &ixgbe_get_san_mac_addr_generic,
.get_device_caps = &ixgbe_get_device_caps_generic,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] atm: remove deprecated use of pci api
From: Quentin Lambert @ 2015-01-14 14:25 UTC (permalink / raw)
To: chas williams - CONTRACTOR, David Miller
Cc: linux-atm-general, netdev, linux-kernel
In-Reply-To: <20150114085851.234db50d@thirdoffive.cmf.nrl.navy.mil>
On 14/01/2015 14:58, chas williams - CONTRACTOR wrote:
> I think I would like to go through and just fix all the usages of the
> older pci interface. This patch isn't very complete due to its
> automated nature.
>
> I will make some time this weekend.
It was my original intent to produce a complete patch, I obviously
misused the tool and forgot a significant number of cases.
But I am ok with fixing that and submitting a complete version of this
patch if you like.
^ permalink raw reply
* Re: [PATCH v2 1/1] atm: remove deprecated use of pci api
From: chas williams - CONTRACTOR @ 2015-01-14 13:58 UTC (permalink / raw)
To: David Miller; +Cc: lambert.quentin, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20150113.215944.1703977685948196746.davem@davemloft.net>
On Tue, 13 Jan 2015 21:59:44 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Quentin Lambert <lambert.quentin@gmail.com>
> Date: Mon, 12 Jan 2015 17:10:42 +0100
>
> > @@ -2246,7 +2246,8 @@ static int eni_init_one(struct pci_dev *pci_dev,
> > goto err_disable;
> >
> > zero = &eni_dev->zero;
> > - zero->addr = pci_alloc_consistent(pci_dev, ENI_ZEROES_SIZE, &zero->dma);
> > + zero->addr = dma_alloc_coherent(&pci_dev->dev, ENI_ZEROES_SIZE,
> > + &zero->dma, GFP_ATOMIC);
> > if (!zero->addr)
> > goto err_kfree;
> >
>
> I really would like you to look at these locations and see if
> GFP_KERNEL can be used instead of GFP_ATOMIC. I bet that nearly
> all of these can, and it is preferred.
>
> Thanks.
I think I would like to go through and just fix all the usages of the
older pci interface. This patch isn't very complete due to its
automated nature.
I will make some time this weekend.
^ permalink raw reply
* [PATCH net] openvswitch: packet messages need their own probe attribtue
From: Thomas Graf @ 2015-01-14 13:56 UTC (permalink / raw)
To: Florian Westphal, davem, Sander Eikelenboom
Cc: Pravin B Shelar, netdev, dev, jrajahalme
In-Reply-To: <20150114130351.GB13716@breakpoint.cc>
User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
and packet messages. This leads to an out-of-bounds access in
ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
OVS_PACKET_ATTR_MAX.
Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value
as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
while maintaining to be binary compatible with existing OVS binaries.
Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Tracked-down-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
include/uapi/linux/openvswitch.h | 4 ++++
net/openvswitch/datapath.c | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 3a6dcaa..f714e86 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -174,6 +174,10 @@ enum ovs_packet_attr {
OVS_PACKET_ATTR_USERDATA, /* OVS_ACTION_ATTR_USERSPACE arg. */
OVS_PACKET_ATTR_EGRESS_TUN_KEY, /* Nested OVS_TUNNEL_KEY_ATTR_*
attributes. */
+ OVS_PACKET_ATTR_UNUSED1,
+ OVS_PACKET_ATTR_UNUSED2,
+ OVS_PACKET_ATTR_PROBE, /* Packet operation is a feature probe,
+ error logging should be suppressed. */
__OVS_PACKET_ATTR_MAX
};
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4e9a5f0..b07349e 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -524,7 +524,7 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, struct genl_info *info)
struct vport *input_vport;
int len;
int err;
- bool log = !a[OVS_FLOW_ATTR_PROBE];
+ bool log = !a[OVS_PACKET_ATTR_PROBE];
err = -EINVAL;
if (!a[OVS_PACKET_ATTR_PACKET] || !a[OVS_PACKET_ATTR_KEY] ||
@@ -610,6 +610,7 @@ static const struct nla_policy packet_policy[OVS_PACKET_ATTR_MAX + 1] = {
[OVS_PACKET_ATTR_PACKET] = { .len = ETH_HLEN },
[OVS_PACKET_ATTR_KEY] = { .type = NLA_NESTED },
[OVS_PACKET_ATTR_ACTIONS] = { .type = NLA_NESTED },
+ [OVS_PACKET_ATTR_PROBE] = { .type = NLA_FLAG },
};
static const struct genl_ops dp_packet_genl_ops[] = {
--
1.9.3
^ permalink raw reply related
* Re: [patch net-next 1/2 v3] tc: add BPF based action
From: Daniel Borkmann @ 2015-01-14 13:28 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, jhs, ast, hannes
In-Reply-To: <1421229297-14473-1-git-send-email-jiri@resnulli.us>
On 01/14/2015 10:54 AM, Jiri Pirko wrote:
> This action provides a possibility to exec custom BPF code.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
...
> diff --git a/net/sched/Kconfig b/net/sched/Kconfig
> index c54c9d9..cc311e9 100644
> --- a/net/sched/Kconfig
> +++ b/net/sched/Kconfig
> @@ -698,6 +698,17 @@ config NET_ACT_VLAN
> To compile this code as a module, choose M here: the
> module will be called act_vlan.
>
> +config NET_ACT_BPF
> + tristate "BPF based action"
> + depends on NET_CLS_ACT
> + ---help---
> + Say Y here to execute BFP code on packets.
^^^
(typo)
Technically correct, but I'd be a bit more precise. When we add eBPF
support one day, this description should be extended to better explain
what it can do, for now it would be good to mention that it can
filter + drop packets.
> + If unsure, say N.
> +
> + To compile this code as a module, choose M here: the
> + module will be called act_bpf.
> +
...
> diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
> new file mode 100644
> index 0000000..0e2a912
> --- /dev/null
> +++ b/net/sched/act_bpf.c
> @@ -0,0 +1,206 @@
...
> +static int tcf_bpf(struct sk_buff *skb, const struct tc_action *a,
> + struct tcf_result *res)
> +{
> + struct tcf_bpf *b = a->priv;
> + int action;
> + int filter_res;
> +
> + spin_lock(&b->tcf_lock);
> + b->tcf_tm.lastuse = jiffies;
> + bstats_update(&b->tcf_bstats, skb);
> + action = b->tcf_action;
> +
> + filter_res = BPF_PROG_RUN(b->filter, skb);
> + if (filter_res == -1)
> + goto drop;
> +
> + goto unlock;
> +
Why this double goto stuff? Wouldn't it be easier to just write it as:
filter_res = BPF_PROG_RUN(b->filter, skb);
if (filter_res == -1) {
/* #-1 return code from the BPF program in act_bpf
* is being interpreted as a drop.
*/
action = TC_ACT_SHOT;
b->tcf_qstats.drops++;
}
spin_unlock(&b->tcf_lock);
return action;
I'm still wondering about the drop semantics ... wouldn't it be more
intuitive to use 0 for drops in this context?
> +drop:
> + action = TC_ACT_SHOT;
> + b->tcf_qstats.drops++;
> +unlock:
> + spin_unlock(&b->tcf_lock);
> + return action;
> +}
...
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net-next v3] rhashtable: Fix race in rhashtable_destroy() and use regular work_struct
From: Sergei Shtylyov @ 2015-01-14 13:25 UTC (permalink / raw)
To: Ying Xue, tgraf; +Cc: davem, netdev
In-Reply-To: <1421228256-740-1-git-send-email-ying.xue@windriver.com>
Hello.
On 1/14/2015 12:37 PM, Ying Xue wrote:
> When we put our declared work task in the global workqueue with
> schedule_delayed_work(), its delay parameter is always zero.
> Therefore, we should define a regular work in rhashtable structure
> instead of a delayed work.
> By the way, we add a condition to check whether resizing functions
> are NULL before cancel the work, avoiding to cancel an uninitialized
s/before cancel/before cancelling/.
> work.
[...]
> Fixes: 97defe1 ("rhashtable: Per bucket locks & deferred expansion/shrinking")
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Cc: Thomas Graf <tgraf@suug.ch>
> Acked-by: Thomas Graf <tgraf@suug.ch>
[...]
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index ed6ae1a..1f56189 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
[...]
> @@ -911,12 +911,11 @@ EXPORT_SYMBOL_GPL(rhashtable_init);
> void rhashtable_destroy(struct rhashtable *ht)
> {
> ht->being_destroyed = true;
Empty line needed here.
> + if (ht->p.grow_decision || ht->p.shrink_decision)
> + cancel_work_sync(&ht->run_work);
>
> mutex_lock(&ht->mutex);
> -
> - cancel_delayed_work(&ht->run_work);
> bucket_table_free(rht_dereference(ht->tbl, ht));
> -
> mutex_unlock(&ht->mutex);
> }
> EXPORT_SYMBOL_GPL(rhashtable_destroy);
WBR, Sergei
^ permalink raw reply
* [net] i40e: adds FCoE configure option
From: Jeff Kirsher @ 2015-01-14 13:14 UTC (permalink / raw)
To: davem; +Cc: Vasu Dev, netdev, nhorman, sassmann, jogreene, stable,
Jeff Kirsher
From: Vasu Dev <vasu.dev@intel.com>
Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
as needed but otherwise have it disabled by default.
This also eliminate multiple FCoE config checks, instead now just
one config check for CONFIG_I40E_FCOE.
The I40E FCoE was added with 3.17 kernel and therefore this patch
shall be applied to stable 3.17 kernel also.
CC: <stable@vger.kernel.org>
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Tested-by: Jim Young <jamesx.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/Kconfig | 11 +++++++++++
drivers/net/ethernet/intel/i40e/Makefile | 2 +-
drivers/net/ethernet/intel/i40e/i40e_osdep.h | 4 ++--
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 5b8300a..4d61ef5 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -281,6 +281,17 @@ config I40E_DCB
If unsure, say N.
+config I40E_FCOE
+ bool "Fibre Channel over Ethernet (FCoE)"
+ default n
+ depends on I40E && DCB && FCOE
+ ---help---
+ Say Y here if you want to use Fibre Channel over Ethernet (FCoE)
+ in the driver. This will create new netdev for exclusive FCoE
+ use with XL710 FCoE offloads enabled.
+
+ If unsure, say N.
+
config I40EVF
tristate "Intel(R) XL710 X710 Virtual Function Ethernet support"
depends on PCI_MSI
diff --git a/drivers/net/ethernet/intel/i40e/Makefile b/drivers/net/ethernet/intel/i40e/Makefile
index 4b94ddb..c405819 100644
--- a/drivers/net/ethernet/intel/i40e/Makefile
+++ b/drivers/net/ethernet/intel/i40e/Makefile
@@ -44,4 +44,4 @@ i40e-objs := i40e_main.o \
i40e_virtchnl_pf.o
i40e-$(CONFIG_I40E_DCB) += i40e_dcb.o i40e_dcb_nl.o
-i40e-$(CONFIG_FCOE:m=y) += i40e_fcoe.o
+i40e-$(CONFIG_I40E_FCOE) += i40e_fcoe.o
diff --git a/drivers/net/ethernet/intel/i40e/i40e_osdep.h b/drivers/net/ethernet/intel/i40e/i40e_osdep.h
index 045b5c4..ad802dd 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_osdep.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_osdep.h
@@ -78,7 +78,7 @@ do { \
} while (0)
typedef enum i40e_status_code i40e_status;
-#if defined(CONFIG_FCOE) || defined(CONFIG_FCOE_MODULE)
+#ifdef CONFIG_I40E_FCOE
#define I40E_FCOE
-#endif /* CONFIG_FCOE or CONFIG_FCOE_MODULE */
+#endif
#endif /* _I40E_OSDEP_H_ */
--
1.9.3
^ permalink raw reply related
* Re: 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229
From: Thomas Graf @ 2015-01-14 13:13 UTC (permalink / raw)
To: Florian Westphal
Cc: Sander Eikelenboom, Pravin B Shelar, David S. Miller, netdev, dev
In-Reply-To: <20150114130351.GB13716@breakpoint.cc>
On 01/14/15 at 02:03pm, Florian Westphal wrote:
> Thomas Graf <tgraf@suug.ch> wrote:
> > Copying ovs-dev mailing list and thus qutoing full message.
> >
> > On 01/14/15 at 01:14pm, Sander Eikelenboom wrote:
> > > Hi,
> > >
> > > I was testing 3.19-rc4 with openvswitch and encountered the splat below.
> >
> > What version of OVS are you using? Did this work properly with rc3 or
> > an older kernel?
>
> seems like it was introduced via 05da5898a96c
> (openvswitch: Add support for OVS_FLOW_ATTR_PROBE).
>
> It adds test for OVS_FLOW_ATTR_PROBE to ovs_packet_cmd_execute() but
> this function seems to only expect OVS_PACKET_ATTR_* (so we get
> out-of-bounds access)?
Absolutely, just came to the same conclusion independently. I'll send
a fix.
^ permalink raw reply
* Re: 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229
From: Sander Eikelenboom @ 2015-01-14 13:05 UTC (permalink / raw)
To: Thomas Graf; +Cc: Pravin B Shelar, David S. Miller, netdev, dev
In-Reply-To: <20150114130005.GA564@casper.infradead.org>
Wednesday, January 14, 2015, 2:00:05 PM, you wrote:
> Copying ovs-dev mailing list and thus qutoing full message.
> On 01/14/15 at 01:14pm, Sander Eikelenboom wrote:
>> Hi,
>>
>> I was testing 3.19-rc4 with openvswitch and encountered the splat below.
> What version of OVS are you using? Did this work properly with rc3 or
> an older kernel?
Hi Thomas,
Don't know for sure, i haven't seen it before, but on the other hand after a
reboot it is running fine now for some time.
So it seems it's not reliably reproducible :(.
OVS version is current Debian wheezy:
ii openvswitch-common 1.4.2+git20120612-9.1~deb7u1 amd64 Open vSwitch common components
ii openvswitch-controller 1.4.2+git20120612-9.1~deb7u1 amd64 Open vSwitch controller implementation
ii openvswitch-pki 1.4.2+git20120612-9.1~deb7u1 all Open vSwitch public key infrastructure dependency package
ii openvswitch-switch 1.4.2+git20120612-9.1~deb7u1 amd64 Open vSwitch switch implementations
--
Sander
>> #addr2line -e /boot/vmlinux-3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ ffffffff818a1690
>> /mnt/kernelbuild/linux-tip/net/openvswitch/datapath.c:527
>> --
>> Sander
>>
>> [ 463.033308] BUG: unable to handle kernel paging request at ffff880055f15000
>> [ 463.072154] IP: [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
>> [ 463.106202] PGD 1e10067 PUD 2097067 PMD 5ff54067 PTE 0
>> [ 463.126940] Oops: 0000 [#1] SMP
>> [ 463.147505] Modules linked in:
>> [ 463.166938] CPU: 2 PID: 3049 Comm: ovs-vswitchd Not tainted 3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ #1
>> [ 463.187507] Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
>> [ 463.208553] task: ffff880058d30000 ti: ffff880055c38000 task.ti: ffff880055c38000
>> [ 463.229734] RIP: e030:[<ffffffff818a1690>] [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
>> [ 463.251082] RSP: e02b:ffff880055c3ba48 EFLAGS: 00010296
>> [ 463.271786] RAX: ffff88004fe38818 RBX: ffffffff81ed4cc0 RCX: 0000000000000000
>> [ 463.293072] RDX: ffff880055c3bb00 RSI: ffff880055c3bad0 RDI: ffff8800559dc700
>> [ 463.314521] RBP: ffff8800559dc700 R08: ffffffff81b08d00 R09: 000000007ffff000
>> [ 463.336189] R10: ffff88004fe38814 R11: ffffffff81ed4cc0 R12: ffff880055f14fc0
>> [ 463.356906] R13: ffff88004fe38800 R14: ffff880055f14fc0 R15: ffffffff81b08c60
>> [ 463.377482] FS: 00007f196321c700(0000) GS:ffff88005f700000(0000) knlGS:ffff88005f680000
>> [ 463.398646] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 463.419995] CR2: ffff880055f15000 CR3: 000000005622e000 CR4: 0000000000042660
>> [ 463.441577] Stack:
>> [ 463.462975] 000000000000000c ffff88004fe38814 0000000000000005 ffffffff8130b116
>> [ 463.485114] ffffffff81ed4cc0 ffffffff81ed4cc0 ffff8800559dc700 ffff880055f14fc0
>> [ 463.507367] ffff88004fe38800 0000000000000008 ffffffff81b08c60 ffffffff81794364
>> [ 463.530186] Call Trace:
>> [ 463.552330] [<ffffffff8130b116>] ? nla_parse+0x57/0xe7
>> [ 463.574869] [<ffffffff81794364>] ? genl_family_rcv_msg+0x243/0x2a9
>> [ 463.597276] [<ffffffff818ad9a2>] ? __slab_alloc.constprop.63+0x2bb/0x2e5
>> [ 463.619394] [<ffffffff81794402>] ? genl_rcv_msg+0x38/0x5b
>> [ 463.641361] [<ffffffff817911a6>] ? __netlink_lookup+0x3a/0x40
>> [ 463.663192] [<ffffffff817943ca>] ? genl_family_rcv_msg+0x2a9/0x2a9
>> [ 463.685141] [<ffffffff81793686>] ? netlink_rcv_skb+0x36/0x7c
>> [ 463.706874] [<ffffffff81793987>] ? genl_rcv+0x1f/0x2c
>> [ 463.729152] [<ffffffff817930ea>] ? netlink_unicast+0x100/0x19c
>> [ 463.751315] [<ffffffff8179350d>] ? netlink_sendmsg+0x311/0x36b
>> [ 463.772483] [<ffffffff8173d574>] ? do_sock_sendmsg+0x62/0x7b
>> [ 463.793309] [<ffffffff8173e6ce>] ? copy_msghdr_from_user+0x158/0x17c
>> [ 463.814032] [<ffffffff8173e94c>] ? ___sys_sendmsg+0x11f/0x197
>> [ 463.834595] [<ffffffff8173ddfd>] ? sock_poll+0xf2/0xfd
>> [ 463.854970] [<ffffffff81136d27>] ? ep_send_events_proc+0x91/0x153
>> [ 463.875603] [<ffffffff81136c96>] ? ep_read_events_proc+0x92/0x92
>> [ 463.896168] [<ffffffff818b6929>] ? _raw_spin_unlock_irqrestore+0x42/0x5b
>> [ 463.917050] [<ffffffff8113759c>] ? ep_scan_ready_list.isra.14+0x163/0x182
>> [ 463.938458] [<ffffffff81137820>] ? ep_poll+0x250/0x2c4
>> [ 463.958214] [<ffffffff8173f410>] ? __sys_sendmsg+0x3b/0x5d
>> [ 463.977581] [<ffffffff818b6da9>] ? system_call_fastpath+0x12/0x17
>> [ 463.996860] Code: ff 89 d8 5b 5d 41 5c 41 5d 41 5e c3 41 57 41 56 41 55 41 54 55 53 48 83 ec 28 48 8b 46 18 4c 8b 76 20 48 89 44 24 08 49 8b 46 08 <49> 8b 6e 40 48 85 c0 0f 84 e0 01 00 00 49 83 7e 10 00 0f 84 d5
>> [ 464.037236] RIP [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
>> [ 464.056926] RSP <ffff880055c3ba48>
>> [ 464.076182] CR2: ffff880055f15000
>> [ 464.095097] ---[ end trace 8bcb28ced5309e55 ]---
^ permalink raw reply
* Re: 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229
From: Florian Westphal @ 2015-01-14 13:03 UTC (permalink / raw)
To: Thomas Graf
Cc: Sander Eikelenboom, Pravin B Shelar, David S. Miller, netdev, dev
In-Reply-To: <20150114130005.GA564@casper.infradead.org>
Thomas Graf <tgraf@suug.ch> wrote:
> Copying ovs-dev mailing list and thus qutoing full message.
>
> On 01/14/15 at 01:14pm, Sander Eikelenboom wrote:
> > Hi,
> >
> > I was testing 3.19-rc4 with openvswitch and encountered the splat below.
>
> What version of OVS are you using? Did this work properly with rc3 or
> an older kernel?
seems like it was introduced via 05da5898a96c
(openvswitch: Add support for OVS_FLOW_ATTR_PROBE).
It adds test for OVS_FLOW_ATTR_PROBE to ovs_packet_cmd_execute() but
this function seems to only expect OVS_PACKET_ATTR_* (so we get
out-of-bounds access)?
^ permalink raw reply
* Re: [PATCH 2/2] mdio-mux-gpio: use new gpiod_get_array and gpiod_put_array functions
From: Rojhalat Ibrahim @ 2015-01-14 13:01 UTC (permalink / raw)
To: Alexandre Courbot
Cc: linux-gpio@vger.kernel.org, Alexandre Courbot, Linus Walleij,
David Miller, netdev
In-Reply-To: <CAAVeFuLqV7CvR2-SNWsrQuBzctQx1wiMtWwjw=cPbp5GRnMdcw@mail.gmail.com>
On Wednesday 14 January 2015 14:11:27 Alexandre Courbot wrote:
> On Sat, Jan 10, 2015 at 12:19 AM, Rojhalat Ibrahim <imr@rtschenk.de> wrote:
> > Use the new gpiod_get_array and gpiod_put_array functions for obtaining and
> > disposing of GPIO descriptors.
> >
> > Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
> > ---
> > This patch depends on my previous patch "gpiolib: add gpiod_get_array and
> > gpiod_put_array functions".
> >
> > drivers/net/phy/mdio-mux-gpio.c | 28 ++++++++--------------------
> > 1 file changed, 8 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
> > index 1eaf81e..35c37da 100644
> > --- a/drivers/net/phy/mdio-mux-gpio.c
> > +++ b/drivers/net/phy/mdio-mux-gpio.c
> > @@ -47,7 +47,6 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
> > {
> > struct mdio_mux_gpio_state *s;
> > int num_gpios;
> > - unsigned int n;
> > int r;
> >
> > if (!pdev->dev.of_node)
> > @@ -63,16 +62,10 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
> >
> > s->num_gpios = num_gpios;
> >
> > - for (n = 0; n < num_gpios; ) {
> > - struct gpio_desc *gpio = gpiod_get_index(&pdev->dev, NULL, n,
> > - GPIOD_OUT_LOW);
> > - if (IS_ERR(gpio)) {
> > - r = PTR_ERR(gpio);
> > - goto err;
> > - }
> > - s->gpio[n] = gpio;
> > - n++;
> > - }
> > + r = gpiod_get_array(&pdev->dev, NULL, s->gpio, num_gpios,
> > + GPIOD_OUT_LOW);
> > + if (r != num_gpios)
> > + return r;
> >
> > r = mdio_mux_init(&pdev->dev,
> > mdio_mux_gpio_switch_fn, &s->mux_handle, s);
> > @@ -80,22 +73,17 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
> > if (r == 0) {
> > pdev->dev.platform_data = s;
> > return 0;
> > + } else {
> > + gpiod_put_array(s->gpio, num_gpios);
> > + return r;
> > }
>
> Suggestion: handle the errors in the if condition, and let normal
> execution be visible at the first level of indentation of the
> function. I.e:
>
> if (r != 0) {
> gpiod_put_array(s->gpio, num_gpios);
> return r;
> }
>
> pdev->dev.platform_data = s;
> return 0;
>
> This is how previous errors are handled in this function and is
> generally a good thing to do as it makes the function's logic easier
> to follow.
>
Ok, will do.
Thanks for the review.
^ permalink raw reply
* Re: 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229
From: Thomas Graf @ 2015-01-14 13:00 UTC (permalink / raw)
To: Sander Eikelenboom; +Cc: Pravin B Shelar, David S. Miller, netdev, dev
In-Reply-To: <1645184106.20150114131420@eikelenboom.it>
Copying ovs-dev mailing list and thus qutoing full message.
On 01/14/15 at 01:14pm, Sander Eikelenboom wrote:
> Hi,
>
> I was testing 3.19-rc4 with openvswitch and encountered the splat below.
What version of OVS are you using? Did this work properly with rc3 or
an older kernel?
> #addr2line -e /boot/vmlinux-3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ ffffffff818a1690
> /mnt/kernelbuild/linux-tip/net/openvswitch/datapath.c:527
> --
> Sander
>
> [ 463.033308] BUG: unable to handle kernel paging request at ffff880055f15000
> [ 463.072154] IP: [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
> [ 463.106202] PGD 1e10067 PUD 2097067 PMD 5ff54067 PTE 0
> [ 463.126940] Oops: 0000 [#1] SMP
> [ 463.147505] Modules linked in:
> [ 463.166938] CPU: 2 PID: 3049 Comm: ovs-vswitchd Not tainted 3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ #1
> [ 463.187507] Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
> [ 463.208553] task: ffff880058d30000 ti: ffff880055c38000 task.ti: ffff880055c38000
> [ 463.229734] RIP: e030:[<ffffffff818a1690>] [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
> [ 463.251082] RSP: e02b:ffff880055c3ba48 EFLAGS: 00010296
> [ 463.271786] RAX: ffff88004fe38818 RBX: ffffffff81ed4cc0 RCX: 0000000000000000
> [ 463.293072] RDX: ffff880055c3bb00 RSI: ffff880055c3bad0 RDI: ffff8800559dc700
> [ 463.314521] RBP: ffff8800559dc700 R08: ffffffff81b08d00 R09: 000000007ffff000
> [ 463.336189] R10: ffff88004fe38814 R11: ffffffff81ed4cc0 R12: ffff880055f14fc0
> [ 463.356906] R13: ffff88004fe38800 R14: ffff880055f14fc0 R15: ffffffff81b08c60
> [ 463.377482] FS: 00007f196321c700(0000) GS:ffff88005f700000(0000) knlGS:ffff88005f680000
> [ 463.398646] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 463.419995] CR2: ffff880055f15000 CR3: 000000005622e000 CR4: 0000000000042660
> [ 463.441577] Stack:
> [ 463.462975] 000000000000000c ffff88004fe38814 0000000000000005 ffffffff8130b116
> [ 463.485114] ffffffff81ed4cc0 ffffffff81ed4cc0 ffff8800559dc700 ffff880055f14fc0
> [ 463.507367] ffff88004fe38800 0000000000000008 ffffffff81b08c60 ffffffff81794364
> [ 463.530186] Call Trace:
> [ 463.552330] [<ffffffff8130b116>] ? nla_parse+0x57/0xe7
> [ 463.574869] [<ffffffff81794364>] ? genl_family_rcv_msg+0x243/0x2a9
> [ 463.597276] [<ffffffff818ad9a2>] ? __slab_alloc.constprop.63+0x2bb/0x2e5
> [ 463.619394] [<ffffffff81794402>] ? genl_rcv_msg+0x38/0x5b
> [ 463.641361] [<ffffffff817911a6>] ? __netlink_lookup+0x3a/0x40
> [ 463.663192] [<ffffffff817943ca>] ? genl_family_rcv_msg+0x2a9/0x2a9
> [ 463.685141] [<ffffffff81793686>] ? netlink_rcv_skb+0x36/0x7c
> [ 463.706874] [<ffffffff81793987>] ? genl_rcv+0x1f/0x2c
> [ 463.729152] [<ffffffff817930ea>] ? netlink_unicast+0x100/0x19c
> [ 463.751315] [<ffffffff8179350d>] ? netlink_sendmsg+0x311/0x36b
> [ 463.772483] [<ffffffff8173d574>] ? do_sock_sendmsg+0x62/0x7b
> [ 463.793309] [<ffffffff8173e6ce>] ? copy_msghdr_from_user+0x158/0x17c
> [ 463.814032] [<ffffffff8173e94c>] ? ___sys_sendmsg+0x11f/0x197
> [ 463.834595] [<ffffffff8173ddfd>] ? sock_poll+0xf2/0xfd
> [ 463.854970] [<ffffffff81136d27>] ? ep_send_events_proc+0x91/0x153
> [ 463.875603] [<ffffffff81136c96>] ? ep_read_events_proc+0x92/0x92
> [ 463.896168] [<ffffffff818b6929>] ? _raw_spin_unlock_irqrestore+0x42/0x5b
> [ 463.917050] [<ffffffff8113759c>] ? ep_scan_ready_list.isra.14+0x163/0x182
> [ 463.938458] [<ffffffff81137820>] ? ep_poll+0x250/0x2c4
> [ 463.958214] [<ffffffff8173f410>] ? __sys_sendmsg+0x3b/0x5d
> [ 463.977581] [<ffffffff818b6da9>] ? system_call_fastpath+0x12/0x17
> [ 463.996860] Code: ff 89 d8 5b 5d 41 5c 41 5d 41 5e c3 41 57 41 56 41 55 41 54 55 53 48 83 ec 28 48 8b 46 18 4c 8b 76 20 48 89 44 24 08 49 8b 46 08 <49> 8b 6e 40 48 85 c0 0f 84 e0 01 00 00 49 83 7e 10 00 0f 84 d5
> [ 464.037236] RIP [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
> [ 464.056926] RSP <ffff880055c3ba48>
> [ 464.076182] CR2: ffff880055f15000
> [ 464.095097] ---[ end trace 8bcb28ced5309e55 ]---
^ permalink raw reply
* Re: [PATCH net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: Sergei Shtylyov @ 2015-01-14 12:55 UTC (permalink / raw)
To: Sriharsha Basavapatna, netdev
In-Reply-To: <1421293069-30518-1-git-send-email-sriharsha.basavapatna@emulex.com>
Hello.
On 1/15/2015 6:37 AM, Sriharsha Basavapatna 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>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 41 +++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 3 deletions(-)
Some nitpicking, mostly grammatical...
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 41a0a54..726a4a4 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
[...]
> @@ -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.
You forgot space before (.
> + */
> + 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 trafffic like GRE work fine while VxLAN
Just "traffic", too many f's.
> + * 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 ||
> + 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)))
() not needed around !=.
[...]
WBR, Sergei
^ permalink raw reply
* [PATCH net] cxgb4vf: Fix queue allocation for 40G adapter
From: Hariprasad Shenai @ 2015-01-14 12:28 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, nirranjan, Hariprasad Shenai
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
.../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index 2215d43..a936ee8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2430,7 +2430,7 @@ static void cfg_queues(struct adapter *adapter)
*/
n10g = 0;
for_each_port(adapter, pidx)
- n10g += is_10g_port(&adap2pinfo(adapter, pidx)->link_cfg);
+ n10g += is_x_10g_port(&adap2pinfo(adapter, pidx)->link_cfg);
/*
* We default to 1 queue per non-10G port and up to # of cores queues
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 0/7] Fix sti drivers whcih mix reg address spaces
From: Maxime Coquelin @ 2015-01-14 12:17 UTC (permalink / raw)
To: David Miller, peter.griffin-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
srinivas.kandagatla-Re5JQEeQqe8AvxtiuMwx3w,
patrice.chotard-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
kishon-l0cyMroinI0, arnd-r2nGTMty4D4,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150111.185445.1288456704842706068.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi David,
On 01/12/2015 12:54 AM, David Miller wrote:
> From: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Date: Wed, 7 Jan 2015 15:04:05 +0000
>
>> A V2 of this old series incorporating Arnd and Lees Feedback form v1.
>>
>> Following on from Arnds comments about the picophy driver here
>> https://lkml.org/lkml/2014/11/13/161, this series fixes the
>> remaining upstreamed drivers for STI, which are mixing address spaces
>> in the reg property. We do this in a way similar to the keystone
>> and bcm7445 platforms, by having sysconfig phandle/ offset pair
>> (where only one register is required). Or phandle / integer array
>> where multiple offsets in the same bank are needed).
>>
>> This series breaks DT compatability! But the platform support
>> is WIP and only being used by the few developers who are upstreaming
>> support for it. I've made each change to the driver / dt doc / dt
>> file as a single atomic commit so the kernel will remain bisectable.
>>
>> This series then also enables the picophy driver, and adds back in
>> the ehci/ohci dt nodes for stih410 which make use of the picophy.
> Series applied to net-next, thanks.
Did you apply all the series to net-next?
I need the DT patches in STi SoC tree, that will go to Linus tree via
arm-soc, hopefully for v3.20.
How could we synchronize?
Maybe I could create an immutable tag on top of STi DT branch, which is
based on top of v3.19-rc1,
that you would merge in your tree?
Please let me know your preferred way.
Thanks,
Maxime
--
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
* 3.19-rc4: BUG: unable to handle kernel paging request at ffff880055f15000 ovs_packet_cmd_execute+0x1f/0x229
From: Sander Eikelenboom @ 2015-01-14 12:14 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: David S. Miller, netdev, linux-kernel
Hi,
I was testing 3.19-rc4 with openvswitch and encountered the splat below.
#addr2line -e /boot/vmlinux-3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ ffffffff818a1690
/mnt/kernelbuild/linux-tip/net/openvswitch/datapath.c:527
--
Sander
[ 463.033308] BUG: unable to handle kernel paging request at ffff880055f15000
[ 463.072154] IP: [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
[ 463.106202] PGD 1e10067 PUD 2097067 PMD 5ff54067 PTE 0
[ 463.126940] Oops: 0000 [#1] SMP
[ 463.147505] Modules linked in:
[ 463.166938] CPU: 2 PID: 3049 Comm: ovs-vswitchd Not tainted 3.19.0-rc4-creanuc-20150114-doflr-apicpatchv3-apicrevert+ #1
[ 463.187507] Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
[ 463.208553] task: ffff880058d30000 ti: ffff880055c38000 task.ti: ffff880055c38000
[ 463.229734] RIP: e030:[<ffffffff818a1690>] [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
[ 463.251082] RSP: e02b:ffff880055c3ba48 EFLAGS: 00010296
[ 463.271786] RAX: ffff88004fe38818 RBX: ffffffff81ed4cc0 RCX: 0000000000000000
[ 463.293072] RDX: ffff880055c3bb00 RSI: ffff880055c3bad0 RDI: ffff8800559dc700
[ 463.314521] RBP: ffff8800559dc700 R08: ffffffff81b08d00 R09: 000000007ffff000
[ 463.336189] R10: ffff88004fe38814 R11: ffffffff81ed4cc0 R12: ffff880055f14fc0
[ 463.356906] R13: ffff88004fe38800 R14: ffff880055f14fc0 R15: ffffffff81b08c60
[ 463.377482] FS: 00007f196321c700(0000) GS:ffff88005f700000(0000) knlGS:ffff88005f680000
[ 463.398646] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 463.419995] CR2: ffff880055f15000 CR3: 000000005622e000 CR4: 0000000000042660
[ 463.441577] Stack:
[ 463.462975] 000000000000000c ffff88004fe38814 0000000000000005 ffffffff8130b116
[ 463.485114] ffffffff81ed4cc0 ffffffff81ed4cc0 ffff8800559dc700 ffff880055f14fc0
[ 463.507367] ffff88004fe38800 0000000000000008 ffffffff81b08c60 ffffffff81794364
[ 463.530186] Call Trace:
[ 463.552330] [<ffffffff8130b116>] ? nla_parse+0x57/0xe7
[ 463.574869] [<ffffffff81794364>] ? genl_family_rcv_msg+0x243/0x2a9
[ 463.597276] [<ffffffff818ad9a2>] ? __slab_alloc.constprop.63+0x2bb/0x2e5
[ 463.619394] [<ffffffff81794402>] ? genl_rcv_msg+0x38/0x5b
[ 463.641361] [<ffffffff817911a6>] ? __netlink_lookup+0x3a/0x40
[ 463.663192] [<ffffffff817943ca>] ? genl_family_rcv_msg+0x2a9/0x2a9
[ 463.685141] [<ffffffff81793686>] ? netlink_rcv_skb+0x36/0x7c
[ 463.706874] [<ffffffff81793987>] ? genl_rcv+0x1f/0x2c
[ 463.729152] [<ffffffff817930ea>] ? netlink_unicast+0x100/0x19c
[ 463.751315] [<ffffffff8179350d>] ? netlink_sendmsg+0x311/0x36b
[ 463.772483] [<ffffffff8173d574>] ? do_sock_sendmsg+0x62/0x7b
[ 463.793309] [<ffffffff8173e6ce>] ? copy_msghdr_from_user+0x158/0x17c
[ 463.814032] [<ffffffff8173e94c>] ? ___sys_sendmsg+0x11f/0x197
[ 463.834595] [<ffffffff8173ddfd>] ? sock_poll+0xf2/0xfd
[ 463.854970] [<ffffffff81136d27>] ? ep_send_events_proc+0x91/0x153
[ 463.875603] [<ffffffff81136c96>] ? ep_read_events_proc+0x92/0x92
[ 463.896168] [<ffffffff818b6929>] ? _raw_spin_unlock_irqrestore+0x42/0x5b
[ 463.917050] [<ffffffff8113759c>] ? ep_scan_ready_list.isra.14+0x163/0x182
[ 463.938458] [<ffffffff81137820>] ? ep_poll+0x250/0x2c4
[ 463.958214] [<ffffffff8173f410>] ? __sys_sendmsg+0x3b/0x5d
[ 463.977581] [<ffffffff818b6da9>] ? system_call_fastpath+0x12/0x17
[ 463.996860] Code: ff 89 d8 5b 5d 41 5c 41 5d 41 5e c3 41 57 41 56 41 55 41 54 55 53 48 83 ec 28 48 8b 46 18 4c 8b 76 20 48 89 44 24 08 49 8b 46 08 <49> 8b 6e 40 48 85 c0 0f 84 e0 01 00 00 49 83 7e 10 00 0f 84 d5
[ 464.037236] RIP [<ffffffff818a1690>] ovs_packet_cmd_execute+0x1f/0x229
[ 464.056926] RSP <ffff880055c3ba48>
[ 464.076182] CR2: ffff880055f15000
[ 464.095097] ---[ end trace 8bcb28ced5309e55 ]---
^ permalink raw reply
* Re: [patch net-next 2/2] tc: cls_bpf: rename bpf_len to bpf_num_ops
From: Daniel Borkmann @ 2015-01-14 12:12 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, jhs, ast, hannes
In-Reply-To: <1421229297-14473-2-git-send-email-jiri@resnulli.us>
On 01/14/2015 10:54 AM, Jiri Pirko wrote:
> It was suggested by DaveM to change the name as "len" might indicate
> unit bytes.
>
> Suggested-by: David Miller <davem@davemloft.net>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Fine by me.
Acked-by: Daniel Borkmann <dborkman@redhat.com>
^ permalink raw reply
* [PATCH net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: Sriharsha Basavapatna @ 2015-01-15 3:37 UTC (permalink / raw)
To: netdev
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>
---
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..726a4a4 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 trafffic 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 ||
+ 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
^ permalink raw reply related
* [PATCH_V4] dm9000: Add regulator and reset support to dm9000
From: Zubair Lutfullah Kakakhel @ 2015-01-14 10:36 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8
In boards, the dm9000 chip's power and reset can be controlled by gpio.
It makes sense to add them to the dm9000 driver and let dt be used to
enable power and reset the phy.
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Paul Burton <paul.burton-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
---
V3 Fixed an indentation and removed a call to gpio_direction_output as
devm_gpio_request_one can handle it.
V2 A few fixes and more error checks. Nothing major
V1 Minor blooper
---
.../devicetree/bindings/net/davicom-dm9000.txt | 4 +++
drivers/net/ethernet/davicom/dm9000.c | 40 ++++++++++++++++++++++
2 files changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
index 28767ed..5224bf0 100644
--- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt
+++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
@@ -11,6 +11,8 @@ Required properties:
Optional properties:
- davicom,no-eeprom : Configuration EEPROM is not available
- davicom,ext-phy : Use external PHY
+- reset-gpios : phandle of gpio that will be used to reset chip during probe
+- vcc-supply : phandle of regulator that will be used to enable power to chip
Example:
@@ -21,4 +23,6 @@ Example:
interrupts = <7 4>;
local-mac-address = [00 00 de ad be ef];
davicom,no-eeprom;
+ reset-gpios = <&gpf 12 GPIO_ACTIVE_LOW>;
+ vcc-supply = <ð0_power>;
};
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index ef0bb58..375a16d 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -36,6 +36,9 @@
#include <linux/platform_device.h>
#include <linux/irq.h>
#include <linux/slab.h>
+#include <linux/regulator/consumer.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <asm/delay.h>
#include <asm/irq.h>
@@ -1426,11 +1429,48 @@ dm9000_probe(struct platform_device *pdev)
struct dm9000_plat_data *pdata = dev_get_platdata(&pdev->dev);
struct board_info *db; /* Point a board information structure */
struct net_device *ndev;
+ struct device *dev = &pdev->dev;
const unsigned char *mac_src;
int ret = 0;
int iosize;
int i;
u32 id_val;
+ int reset_gpios;
+ enum of_gpio_flags flags;
+ struct regulator *power;
+
+ power = devm_regulator_get(dev, "vcc");
+ if (PTR_ERR(power) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (IS_ERR(power)) {
+ dev_dbg(dev, "no regulator provided\n");
+ } else {
+ ret = regulator_enable(power);
+ if (ret != 0) {
+ dev_err(dev,
+ "Failed to enable power regulator: %d\n", ret);
+ return ret;
+ }
+ dev_dbg(dev, "regulator enabled\n");
+ }
+
+ reset_gpios = of_get_named_gpio_flags(dev->of_node, "reset-gpios", 0,
+ &flags);
+ if (gpio_is_valid(reset_gpios)) {
+ ret = devm_gpio_request_one(dev, reset_gpios, flags,
+ "dm9000_reset");
+ if (ret) {
+ dev_err(dev, "failed to request reset gpio %d: %d\n",
+ reset_gpios, ret);
+ return -ENODEV;
+ }
+
+ /* According to manual PWRST# Low Period Min 1ms */
+ msleep(2);
+ gpio_set_value(reset_gpios, 1);
+ /* Needs 3ms to read eeprom when PWRST is deasserted */
+ msleep(4);
+ }
if (!pdata) {
pdata = dm9000_parse_dt(&pdev->dev);
--
1.9.1
--
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 related
* Re: [PATCH net-next v13 0/3] add hisilicon hip04 ethernet driver
From: Alexander Graf @ 2015-01-14 10:19 UTC (permalink / raw)
To: Ding Tianhong, arnd, robh+dt, davem, grant.likely
Cc: sergei.shtylyov, linux-arm-kernel, eric.dumazet, xuwei5,
zhangfei.gao, netdev, devicetree, linux
In-Reply-To: <1421217254-12008-1-git-send-email-dingtianhong@huawei.com>
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
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
* [PATCH net-next] socket: use iov_length()
From: Nicolas Dichtel @ 2015-01-14 10:07 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel
Better to use available helpers.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/socket.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index a2c33a4dc7ba..b1f3fa4da020 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -883,10 +883,8 @@ static ssize_t do_sock_read(struct msghdr *msg, struct kiocb *iocb,
{
struct socket *sock = file->private_data;
size_t size = 0;
- int i;
- for (i = 0; i < nr_segs; i++)
- size += iov[i].iov_len;
+ size = iov_length(iov, nr_segs);
msg->msg_name = NULL;
msg->msg_namelen = 0;
@@ -922,10 +920,8 @@ static ssize_t do_sock_write(struct msghdr *msg, struct kiocb *iocb,
{
struct socket *sock = file->private_data;
size_t size = 0;
- int i;
- for (i = 0; i < nr_segs; i++)
- size += iov[i].iov_len;
+ size = iov_length(iov, nr_segs);
msg->msg_name = NULL;
msg->msg_namelen = 0;
--
2.1.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox