* Re: [PATCH] soc: ti/knav_dma: include dmaengine header
From: David Miller @ 2017-09-05 16:12 UTC (permalink / raw)
To: arnd; +Cc: arm, dave.jiang, netdev, m-karicheri2, linux-kernel
In-Reply-To: <20170905083146.1289546-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 5 Sep 2017 10:31:35 +0200
> A header file cleanup apparently caused a build regression
> with one driver using the knav infrastructure:
>
> In file included from drivers/net/ethernet/ti/netcp_core.c:30:0:
> include/linux/soc/ti/knav_dma.h:129:30: error: field 'direction' has incomplete type
> enum dma_transfer_direction direction;
> ^~~~~~~~~
> drivers/net/ethernet/ti/netcp_core.c: In function 'netcp_txpipe_open':
> drivers/net/ethernet/ti/netcp_core.c:1349:21: error: 'DMA_MEM_TO_DEV' undeclared (first use in this function); did you mean 'DMA_MEMORY_MAP'?
> config.direction = DMA_MEM_TO_DEV;
> ^~~~~~~~~~~~~~
> DMA_MEMORY_MAP
> drivers/net/ethernet/ti/netcp_core.c:1349:21: note: each undeclared identifier is reported only once for each function it appears in
> drivers/net/ethernet/ti/netcp_core.c: In function 'netcp_setup_navigator_resources':
> drivers/net/ethernet/ti/netcp_core.c:1659:22: error: 'DMA_DEV_TO_MEM' undeclared (first use in this function); did you mean 'DMA_DESC_HOST'?
> config.direction = DMA_DEV_TO_MEM;
>
> As the header is no longer included implicitly through netdevice.h,
> we should include it in the header that references the enum.
>
> Fixes: 0dd5759dbb1c ("net: remove dmaengine.h inclusion from netdevice.h")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> If the cleanup patch hasn't been submitted for mainline yet, please
> add this fixup to the net-next tree, otherwise I'll merge it through
> arm-soc.
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net/ncsi: fix ncsi_vlan_rx_{add,kill}_vid references
From: David Miller @ 2017-09-05 16:12 UTC (permalink / raw)
To: arnd; +Cc: gwshan, sam, joel, netdev, linux-kernel
In-Reply-To: <20170905080615.1131665-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 5 Sep 2017 10:05:47 +0200
> We get a new link error in allmodconfig kernels after ftgmac100
> started using the ncsi helpers:
>
> ERROR: "ncsi_vlan_rx_kill_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] undefined!
> ERROR: "ncsi_vlan_rx_add_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] undefined!
>
> Related to that, we get another error when CONFIG_NET_NCSI is disabled:
>
> drivers/net/ethernet/faraday/ftgmac100.c:1626:25: error: 'ncsi_vlan_rx_add_vid' undeclared here (not in a function); did you mean 'ncsi_start_dev'?
> drivers/net/ethernet/faraday/ftgmac100.c:1627:26: error: 'ncsi_vlan_rx_kill_vid' undeclared here (not in a function); did you mean 'ncsi_vlan_rx_add_vid'?
>
> This fixes both problems at once, using a 'static inline' stub helper
> for the disabled case, and exporting the functions when they are present.
>
> Fixes: 51564585d8c6 ("ftgmac100: Support NCSI VLAN filtering when available")
> Fixes: 21acf63013ed ("net/ncsi: Configure VLAN tag filter")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bpf: fix numa_node validation
From: David Miller @ 2017-09-05 16:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kafai, daniel, ast
In-Reply-To: <1504590062.15310.36.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 04 Sep 2017 22:41:02 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> syzkaller reported crashes in bpf map creation or map update [1]
>
> Problem is that nr_node_ids is a signed integer,
> NUMA_NO_NODE is also an integer, so it is very tempting
> to declare numa_node as a signed integer.
>
> This means the typical test to validate a user provided value :
>
> if (numa_node != NUMA_NO_NODE &&
> (numa_node >= nr_node_ids ||
> !node_online(numa_node)))
>
> must be written :
>
> if (numa_node != NUMA_NO_NODE &&
> ((unsigned int)numa_node >= nr_node_ids ||
> !node_online(numa_node)))
>
>
> [1]
...
> Fixes: 96eabe7a40aa ("bpf: Allow selecting numa node during map creation")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads
From: Tom Herbert @ 2017-09-05 16:02 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Saeed Mahameed, Saeed Mahameed, David S. Miller,
Linux Netdev List
In-Reply-To: <87r2vls8hp.fsf@stressinduktion.org>
On Tue, Sep 5, 2017 at 4:14 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Tom Herbert <tom@herbertland.com> writes:
>
>> There is absolutely no requirement in IP that packets are delivered in
>> order-- there never has been and there never will be! If the ULP, like
>> Ethernet encapsulation, requires in order deliver then it needs to
>> implement that itself like TCP, GRE, and other protocols ensure that
>> with sequence numbers and reassembly. All of these hoops we do make
>> sure that packets always follow the same path and are always in order
>> are done for benefit of middlebox devices like stateful firewalls that
>> have force us to adopt their concept of network architecture-- in the
>> long run this is self-defeating and kills our ability to innovate.
>>
>> I'm not saying that we shouldn't consider legacy devices, but we
>> should scrutinize new development or solutions that perpetuate
>> incorrect design or bad assumptions.
>
> So configure RSS per port and ensure no fragments are send to those
> ports. This is possible and rather easy to do. It solves the problem
> with legacy software and it spreads out packets for your applications.
>
> It is not perfect but it is working and solves both problems.
>
Hannes,
I don't see how that solves anything. The purpose of RSS is to
distribute the load of protocol packets across queues. This needs to
work for UDP applications. For instance, if I were building a QUIC
server I'd want the sort of flow distribution that a TCP server would
give. You can't do that by configuring a few ports in the device.
If I were to suggest any HW change it would be to not do DPI on
fragments (MF or offset is set). This ensures that all packets of the
fragment train get hashed to the same queue and is on fact what RPS
has been doing for years without any complaints.
But even before I'd make that recommendation, I'd really like
understand what the problem actually is. The only thing I can garner
from this discussion and the Intel patch is that when fragments are
received OOO that is perceived as a problem. But the by the protocol
specification clearly says this is not a problem. So the questions
are: who is negatively affected by this? Is this a problem because
some artificial test that checks for everything to be in order is now
failing? Is this affecting real users? Is this an issue in the stack
or really with some implementation outside of the stack? If it is an
implementation outside of the stack, then are we just bandaid'ing over
someone else's incorrect implementation by patching the kernel (like
would have be the case if we change the kernel to interoperate with
Facebook's switch that couldn't handle OOO in twstate).
Thanks,
Tom
> Bye,
> Hannes
^ permalink raw reply
* [PATCH 24/25 v2] net/cdc_ncm: Replace tasklet with softirq hrtimer
From: Sebastian Andrzej Siewior @ 2017-09-05 15:42 UTC (permalink / raw)
To: Bjørn Mork
Cc: Anna-Maria Gleixner, LKML, Peter Zijlstra, Ingo Molnar,
Christoph Hellwig, keescook, John Stultz, Thomas Gleixner,
Oliver Neukum, Greg Kroah-Hartman, linux-usb, netdev
In-Reply-To: <87mv6fzvpr.fsf@miraculix.mork.no>
From: Thomas Gleixner <tglx@linutronix.de>
The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
softirq context. This can be also achieved without the tasklet but with
CLOCK_MONOTONIC_SOFT as hrtimer base.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bigeasy: using usb_get_intfdata() as suggested by Bjørn Mork]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
On 2017-08-31 15:57:04 [+0200], Bjørn Mork wrote:
> I believe the struct usbnet pointer is redundant. We already have lots
> of pointers back and forth here. This should work, but is not tested:
>
> struct usbnet *dev = usb_get_intfdata(ctx->control):
I think so, too. Still untested as I don't have a working gadget around.
v1…v2: Updated as suggested by Bjørn and added Greg's Acked-by.
drivers/net/usb/cdc_ncm.c | 36 +++++++++++++++---------------------
include/linux/usb/cdc_ncm.h | 1 -
2 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 8f572b9f3625..42f7bd90e6a4 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -61,7 +61,6 @@ static bool prefer_mbim;
module_param(prefer_mbim, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(prefer_mbim, "Prefer MBIM setting on dual NCM/MBIM functions");
-static void cdc_ncm_txpath_bh(unsigned long param);
static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx);
static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *hr_timer);
static struct usb_driver cdc_ncm_driver;
@@ -777,10 +776,8 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_
if (!ctx)
return -ENOMEM;
- hrtimer_init(&ctx->tx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer_init(&ctx->tx_timer, CLOCK_MONOTONIC_SOFT, HRTIMER_MODE_REL);
ctx->tx_timer.function = &cdc_ncm_tx_timer_cb;
- ctx->bh.data = (unsigned long)dev;
- ctx->bh.func = cdc_ncm_txpath_bh;
atomic_set(&ctx->stop, 0);
spin_lock_init(&ctx->mtx);
@@ -967,10 +964,7 @@ void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf)
atomic_set(&ctx->stop, 1);
- if (hrtimer_active(&ctx->tx_timer))
- hrtimer_cancel(&ctx->tx_timer);
-
- tasklet_kill(&ctx->bh);
+ hrtimer_cancel(&ctx->tx_timer);
/* handle devices with combined control and data interface */
if (ctx->control == ctx->data)
@@ -1348,20 +1342,9 @@ static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx)
HRTIMER_MODE_REL);
}
-static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *timer)
+static void cdc_ncm_txpath_bh(struct cdc_ncm_ctx *ctx)
{
- struct cdc_ncm_ctx *ctx =
- container_of(timer, struct cdc_ncm_ctx, tx_timer);
-
- if (!atomic_read(&ctx->stop))
- tasklet_schedule(&ctx->bh);
- return HRTIMER_NORESTART;
-}
-
-static void cdc_ncm_txpath_bh(unsigned long param)
-{
- struct usbnet *dev = (struct usbnet *)param;
- struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
+ struct usbnet *dev = usb_get_intfdata(ctx->control);
spin_lock_bh(&ctx->mtx);
if (ctx->tx_timer_pending != 0) {
@@ -1379,6 +1362,17 @@ static void cdc_ncm_txpath_bh(unsigned long param)
}
}
+static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *timer)
+{
+ struct cdc_ncm_ctx *ctx =
+ container_of(timer, struct cdc_ncm_ctx, tx_timer);
+
+ if (!atomic_read(&ctx->stop))
+ cdc_ncm_txpath_bh(ctx);
+
+ return HRTIMER_NORESTART;
+}
+
struct sk_buff *
cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
{
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 1a59699cf82a..62b506fddf8d 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -92,7 +92,6 @@
struct cdc_ncm_ctx {
struct usb_cdc_ncm_ntb_parameters ncm_parm;
struct hrtimer tx_timer;
- struct tasklet_struct bh;
const struct usb_cdc_ncm_desc *func_desc;
const struct usb_cdc_mbim_desc *mbim_desc;
--
2.14.1
^ permalink raw reply related
* [PATCH net] rds: Fix non-atomic operation on shared flag variable
From: Håkon Bugge @ 2017-09-05 15:42 UTC (permalink / raw)
To: Santosh Shilimkar, David S . Miller
Cc: netdev, linux-rdma, rds-devel, linux-kernel, knut.omang,
wei.lin.guay
The bits in m_flags in struct rds_message are used for a plurality of
reasons, and from different contexts. To avoid any missing updates to
m_flags, use the atomic set_bit() instead of the non-atomic equivalent.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Knut Omang <knut.omang@oracle.com>
Reviewed-by: Wei Lin Guay <wei.lin.guay@oracle.com>
---
net/rds/send.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 41b9f0f..058a407 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -273,7 +273,7 @@ int rds_send_xmit(struct rds_conn_path *cp)
len = ntohl(rm->m_inc.i_hdr.h_len);
if (cp->cp_unacked_packets == 0 ||
cp->cp_unacked_bytes < len) {
- __set_bit(RDS_MSG_ACK_REQUIRED, &rm->m_flags);
+ set_bit(RDS_MSG_ACK_REQUIRED, &rm->m_flags);
cp->cp_unacked_packets =
rds_sysctl_max_unacked_packets;
@@ -829,7 +829,7 @@ static int rds_send_queue_rm(struct rds_sock *rs, struct rds_connection *conn,
* throughput hits a certain threshold.
*/
if (rs->rs_snd_bytes >= rds_sk_sndbuf(rs) / 2)
- __set_bit(RDS_MSG_ACK_REQUIRED, &rm->m_flags);
+ set_bit(RDS_MSG_ACK_REQUIRED, &rm->m_flags);
list_add_tail(&rm->m_sock_item, &rs->rs_send_queue);
set_bit(RDS_MSG_ON_SOCK, &rm->m_flags);
--
2.9.3
^ permalink raw reply related
* [PATCH net v2] net: sched: don't use GFP_KERNEL under spin lock
From: Jakub Kicinski @ 2017-09-05 15:31 UTC (permalink / raw)
To: netdev, eric.dumazet
Cc: jiri, Chris Mi, xiyou.wangcong, jhs, oss-drivers, Jakub Kicinski
The new TC IDR code uses GFP_KERNEL under spin lock. Which leads
to:
[ 582.621091] BUG: sleeping function called from invalid context at ../mm/slab.h:416
[ 582.629721] in_atomic(): 1, irqs_disabled(): 0, pid: 3379, name: tc
[ 582.636939] 2 locks held by tc/3379:
[ 582.641049] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff910354ce>] rtnetlink_rcv_msg+0x92e/0x1400
[ 582.650958] #1: (&(&tn->idrinfo->lock)->rlock){+.-.+.}, at: [<ffffffff9110a5e0>] tcf_idr_create+0x2f0/0x8e0
[ 582.662217] Preemption disabled at:
[ 582.662222] [<ffffffff9110a5e0>] tcf_idr_create+0x2f0/0x8e0
[ 582.672592] CPU: 9 PID: 3379 Comm: tc Tainted: G W 4.13.0-rc7-debug-00648-g43503a79b9f0 #287
[ 582.683432] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
[ 582.691937] Call Trace:
...
[ 582.742460] kmem_cache_alloc+0x286/0x540
[ 582.747055] radix_tree_node_alloc.constprop.6+0x4a/0x450
[ 582.753209] idr_get_free_cmn+0x627/0xf80
...
[ 582.815525] idr_alloc_cmn+0x1a8/0x270
...
[ 582.833804] tcf_idr_create+0x31b/0x8e0
...
Try to preallocate the memory with idr_prealloc(GFP_KERNEL)
(as suggested by Eric Dumazet), and change the allocation
flags under spin lock.
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
net/sched/act_api.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 0eb545bcb247..a306974e2fb4 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -296,10 +296,12 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
spin_lock_init(&p->tcfa_lock);
/* user doesn't specify an index */
if (!index) {
+ idr_preload(GFP_KERNEL);
spin_lock_bh(&idrinfo->lock);
err = idr_alloc_ext(idr, NULL, &idr_index, 1, 0,
- GFP_KERNEL);
+ GFP_ATOMIC);
spin_unlock_bh(&idrinfo->lock);
+ idr_preload_end();
if (err) {
err3:
free_percpu(p->cpu_qstats);
@@ -307,10 +309,12 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
}
p->tcfa_index = idr_index;
} else {
+ idr_preload(GFP_KERNEL);
spin_lock_bh(&idrinfo->lock);
err = idr_alloc_ext(idr, NULL, NULL, index, index + 1,
- GFP_KERNEL);
+ GFP_ATOMIC);
spin_unlock_bh(&idrinfo->lock);
+ idr_preload_end();
if (err)
goto err3;
p->tcfa_index = index;
--
2.14.1
^ permalink raw reply related
* Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode
From: Roopa Prabhu @ 2017-09-05 15:17 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nikolay Aleksandrov, netdev@vger.kernel.org, David Ahern,
Cong Wang, Jamal Hadi Salim
In-Reply-To: <20170905140750.GB7936@nanopsycho>
On Tue, Sep 5, 2017 at 7:07 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Sep 05, 2017 at 02:48:21PM CEST, nikolay@cumulusnetworks.com wrote:
>>Hi all,
>>This RFC adds a new mode for clsact which designates a device's egress
>>classifier as global per netns. The packets that are not classified for
>>a particular device will be classified using the global classifier.
>>We have needed a global classifier for some time now for various
>>purposes and setting the single bridge or loopback/vrf device as the
>>global classifier device is acceptable for us. Doing it this way avoids
>>the act/cls device and queue dependencies.
>>
>>This is strictly an RFC patch just to show the intent, if we agree on
>>the details the proposed patch will have support for both ingress and
>>egress, and will be using a static key to avoid the fast path test when no
>>global classifier has been configured.
>>
>>Example (need a modified tc that adds TCA_OPTIONS when using q_clsact):
>>$ tc qdisc add dev lo clsact global
>>$ tc filter add dev lo egress protocol ip u32 match ip dst 4.3.2.1/32 action drop
>>
>>the last filter will be global for all devices that don't have a
>>specific egress_cl_list (i.e. have clsact configured).
>>
>>Any comments and thoughts would be greatly appreciated.
>
> Did you see my shared blocks work? I believe that it should resolve your
> usecase, in a generic way. You just have to bind the devices you need to
> the shared block. Please see the RFC:
>
> https://www.spinics.net/lists/netdev/msg444067.html
Jiri, yes, we have seen this series. This still requires one to make
the association between dev and tc shared block..and
the rules are associated with every device. Your work will help the
case and is needed for tc in general and can co-exist.
It takes us closer but is still not a way to create global tc rules.
imagine thousands of netdevs. We would ideally like the show to also
display a single set of rules.
Given tc has a rich set of classifiers and actions (and very
extensible!), we are trying to see if those can
be easily applied globally than being tied to a device. Maybe there
are other better ways to achieve this...this thread
is to start that discussion. I think solving this once will help the
scale issue for your hardware offload case as well.
^ permalink raw reply
* Re: [PATCH net-next] bpf: fix numa_node validation
From: Alexei Starovoitov @ 2017-09-05 14:43 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev, Martin KaFai Lau, Daniel Borkmann
In-Reply-To: <1504590062.15310.36.camel@edumazet-glaptop3.roam.corp.google.com>
On 9/4/17 10:41 PM, Eric Dumazet wrote:
> Call Trace:
> __do_kmalloc_node mm/slab.c:3688 [inline]
> __kmalloc_node+0x33/0x70 mm/slab.c:3696
> kmalloc_node include/linux/slab.h:535 [inline]
> alloc_htab_elem+0x2a8/0x480 kernel/bpf/hashtab.c:740
> htab_map_update_elem+0x740/0xb80 kernel/bpf/hashtab.c:820
> map_update_elem kernel/bpf/syscall.c:587 [inline]
> SYSC_bpf kernel/bpf/syscall.c:1468 [inline]
> SyS_bpf+0x20c5/0x4c40 kernel/bpf/syscall.c:1443
> entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x440409
> RSP: 002b:00007ffd1f1792b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440409
> RDX: 0000000000000020 RSI: 0000000020006000 RDI: 0000000000000002
> RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401d70
> R13: 0000000000401e00 R14: 0000000000000000 R15: 0000000000000000
> Code: 83 c2 01 89 50 18 4c 03 70 08 e8 38 f4 ff ff 4d 85 f6 0f 85 3e ff ff ff 44 89 fe 4c 89 ef e8 94 fb ff ff 49 89 c6 e9 2b ff ff ff <0f> 0b 0f 0b 0f 0b 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
> RIP: ____cache_alloc_node+0x1d4/0x1e0 mm/slab.c:3292 RSP: ffff8801c0c97638
> ---[ end trace d745f355da2e33ce ]---
> Kernel panic - not syncing: Fatal exception
>
> Fixes: 96eabe7a40aa ("bpf: Allow selecting numa node during map creation")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Good catch. Thanks!
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [oss-drivers] Re: [PATCH net] net: sched: don't use GFP_KERNEL under spin lock
From: Jiri Pirko @ 2017-09-05 14:31 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20170905152551.748e4af2@cakuba.netronome.com>
Tue, Sep 05, 2017 at 04:25:51PM CEST, kubakici@wp.pl wrote:
>On Tue, 5 Sep 2017 14:52:21 +0200, Jiri Pirko wrote:
>> Tue, Sep 05, 2017 at 12:59:48PM CEST, kubakici@wp.pl wrote:
>> >Jiri, FWIW I also just noticed these, but they seem related to the
>> >earlier TC chain work?
>>
>> What do you do to trigger this?
>
>Sorry, I wasted a bit of time there because kmemleak takes surprisingly
>long to notice the memory leak... In the end this is sufficient:
>
> modprobe nfp
> ifconfig p4p1 10.8.1.1/24 up
> tc qdisc add dev p4p1 handle ffff: ingress
> tc filter add dev p4p1 parent ffff: protocol 802.1Q flower vlan_id 600 \
> action mirred egress redirect dev p4p1
> tc filter del dev p4p1 parent ffff:
> rmmod nfp
Will try. Thanks!
^ permalink raw reply
* Re: [oss-drivers] Re: [PATCH net] net: sched: don't use GFP_KERNEL under spin lock
From: Jakub Kicinski @ 2017-09-05 14:25 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, oss-drivers
In-Reply-To: <20170905125221.GA7936@nanopsycho>
On Tue, 5 Sep 2017 14:52:21 +0200, Jiri Pirko wrote:
> Tue, Sep 05, 2017 at 12:59:48PM CEST, kubakici@wp.pl wrote:
> >Jiri, FWIW I also just noticed these, but they seem related to the
> >earlier TC chain work?
>
> What do you do to trigger this?
Sorry, I wasted a bit of time there because kmemleak takes surprisingly
long to notice the memory leak... In the end this is sufficient:
modprobe nfp
ifconfig p4p1 10.8.1.1/24 up
tc qdisc add dev p4p1 handle ffff: ingress
tc filter add dev p4p1 parent ffff: protocol 802.1Q flower vlan_id 600 \
action mirred egress redirect dev p4p1
tc filter del dev p4p1 parent ffff:
rmmod nfp
^ permalink raw reply
* Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode
From: Jiri Pirko @ 2017-09-05 14:23 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, dsa, xiyou.wangcong, jhs
In-Reply-To: <20170905140750.GB7936@nanopsycho>
Tue, Sep 05, 2017 at 04:07:51PM CEST, jiri@resnulli.us wrote:
>Tue, Sep 05, 2017 at 02:48:21PM CEST, nikolay@cumulusnetworks.com wrote:
>>Hi all,
>>This RFC adds a new mode for clsact which designates a device's egress
>>classifier as global per netns. The packets that are not classified for
>>a particular device will be classified using the global classifier.
>>We have needed a global classifier for some time now for various
>>purposes and setting the single bridge or loopback/vrf device as the
>>global classifier device is acceptable for us. Doing it this way avoids
>>the act/cls device and queue dependencies.
>>
>>This is strictly an RFC patch just to show the intent, if we agree on
>>the details the proposed patch will have support for both ingress and
>>egress, and will be using a static key to avoid the fast path test when no
>>global classifier has been configured.
>>
>>Example (need a modified tc that adds TCA_OPTIONS when using q_clsact):
>>$ tc qdisc add dev lo clsact global
>>$ tc filter add dev lo egress protocol ip u32 match ip dst 4.3.2.1/32 action drop
>>
>>the last filter will be global for all devices that don't have a
>>specific egress_cl_list (i.e. have clsact configured).
>>
>>Any comments and thoughts would be greatly appreciated.
For the record, I think this "global" thing is a hack similar to
cls_u32 shared hashlists.
>
>Did you see my shared blocks work? I believe that it should resolve your
>usecase, in a generic way. You just have to bind the devices you need to
>the shared block. Please see the RFC:
>
>https://www.spinics.net/lists/netdev/msg444067.html
^ permalink raw reply
* VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)
From: Johannes Berg @ 2017-09-05 14:20 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
Cc: Igor Mitsyanko, Avinash Patil
In-Reply-To: <1504619151.12380.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
+netdev
On Tue, 2017-09-05 at 15:45 +0200, Johannes Berg wrote:
>
> In a way this feature seems mis-designed - you never have 802.1Q tags
> over the air, but you're inserting them on RX and stripping them on
> TX, probably in order to make bridging to ethernet easier and not
> have to have 802.1Q acceleration on the ethernet port, or - well - in
> order to have an ability to do this with an ethernet card that only
> has a single CPU port.
Ok this isn't really right either - it's only for saving the 802.1Q
acceleration on the Ethernet port, really - and saving the extra
bridges.
To clarify, I think what you - conceptually - want is the following
topology:
+--- eth0.1 --- br.1 --- wlan0.1
|
eth0 ---+--- eth0.2 --- br.2 --- wlan0.2
|
+--- eth0.3 --- br.3 --- wlan0.3
where eth0.N is just "ip link add link eth0 name eth0.N type vlan id N"
and br.N is obviously a bridge for each, and the wlan0.N are AP_VLAN
type interfaces that isolate the clients against each other as far as
wifi is concerned.
Is this correct? As far as I understand, that's the baseline topology
that you're trying to achieve, expressed in terms of Linux networking.
Now, you seem to want to compress this to
+--- wlan0.1
|
eth0 --- br ---+--- wlan0.2
|
+--- wlan0.3
and have the 802.1Q tag insertion/removal that's normally configured to
happen in eth0.N already be handled in wlan0.N.
Also correct?
We clearly don't have APIs for this, and I don't think it makes sense
in the Linux space - the bridge and wlan0.N suddenly have tagged
traffic rather than untagged, and the VLAN tagging is completely hidden
from the management view.
johannes
^ permalink raw reply
* Re: [PATCH net] net: sched: don't use GFP_KERNEL under spin lock
From: Eric Dumazet @ 2017-09-05 14:10 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, jiri, Chris Mi, xiyou.wangcong, jhs, oss-drivers
In-Reply-To: <20170905105442.30972-1-jakub.kicinski@netronome.com>
On Tue, 2017-09-05 at 03:54 -0700, Jakub Kicinski wrote:
> The new TC IDR code uses GFP_KERNEL under spinlocks. Which leads
> to:
> ...
>
> Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Simon Horman <simon.horman@netronome.com>
> ---
> net/sched/act_api.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index 0eb545bcb247..a48e4b45722d 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -298,7 +298,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
> if (!index) {
idr_preload(GFP_KERNEL);
> spin_lock_bh(&idrinfo->lock);
> err = idr_alloc_ext(idr, NULL, &idr_index, 1, 0,
> - GFP_KERNEL);
> + GFP_ATOMIC);
> spin_unlock_bh(&idrinfo->lock);
> if (err) {
> err3:
> @@ -309,7 +309,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
> } else {
idr_preload(GFP_KERNEL);
> spin_lock_bh(&idrinfo->lock);
> err = idr_alloc_ext(idr, NULL, NULL, index, index + 1,
> - GFP_KERNEL);
> + GFP_ATOMIC);
> spin_unlock_bh(&idrinfo->lock);
> if (err)
> goto err3;
^ permalink raw reply
* Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi
From: Willem de Bruijn @ 2017-09-05 14:09 UTC (permalink / raw)
To: Jason Wang
Cc: Network Development, virtualization, Koichiro Den,
Michael S. Tsirkin
In-Reply-To: <96819b6a-6d44-fd7e-37af-5a0db81b3840@redhat.com>
On Mon, Sep 4, 2017 at 5:03 AM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2017年09月02日 00:17, Willem de Bruijn wrote:
>>>>>
>>>>> This is not a 50/50 split, which impliesTw that some packets from the
>>>>> large
>>>>> packet flow are still converted to copying. Without the change the rate
>>>>> without queue was 80k zerocopy vs 80k copy, so this choice of
>>>>> (vq->num >> 2) appears too conservative.
>>>>>
>>>>> However, testing with (vq->num >> 1) was not as effective at mitigating
>>>>> stalls. I did not save that data, unfortunately. Can run more tests on
>>>>> fine
>>>>> tuning this variable, if the idea sounds good.
>>>>
>>>>
>>>> Looks like there're still two cases were left:
>>>
>>> To be clear, this patch is not intended to fix all issues. It is a small
>>> improvement to avoid HoL blocking due to queued zerocopy skbs.
>
>
> Right, just want to see if there's anything left.
>
>>>
>>> The trade-off is that reverting to copying in these cases increases
>>> cycle cost. I think that that is a trade-off worth making compared to
>>> the alternative drop in throughput. It probably would be good to be
>>> able to measure this without kernel instrumentation: export
>>> counters similar to net->tx_zcopy_err and net->tx_packets (though
>>> without reset to zero, as in vhost_net_tx_packet).
>
>
> I think it's acceptable if extra cycles were spent if we detect HOL anyhow.
>
>>>
>>>> 1) sndbuf is not INT_MAX
>>>
>>> You mean the case where the device stalls, later zerocopy notifications
>>> are queued, but these are never cleaned in free_old_xmit_skbs,
>>> because it requires a start_xmit and by now the (only) socket is out of
>>> descriptors?
>>
>> Typo, sorry. I meant out of sndbuf.
>
>
> I mean e.g for tun. If its sndbuf is smaller than e.g (vq->num >> 1) *
> $pkt_size and if all packet were held by some modules, limitation like
> vq->num >> 1 won't work since we hit sudbuf before it.
Good point.
>>
>>> A watchdog would help somewhat. With tx-napi, this case cannot occur,
>>> either, as free_old_xmit_skbs no longer depends on a call to start_xmit.
>>>
>>>> 2) tx napi is used for virtio-net
>>>
>>> I am not aware of any issue specific to the use of tx-napi?
>
>
> Might not be clear here, I mean e.g virtio_net (tx-napi) in guest +
> vhost_net (zerocopy) in host. In this case, even if we switch to datacopy if
> ubuf counts exceeds vq->num >> 1, we still complete tx buffers in order, tx
> interrupt could be delayed for indefinite time.
Copied buffers are completed immediately in handle_tx.
Do you mean when a process sends fewer packets than vq->num >> 1,
so that all are queued? Yes, then the latency is indeed that of the last
element leaving the qdisc.
>>>
>>>> 1) could be a corner case, and for 2) what your suggest here may not
>>>> solve
>>>> the issue since it still do in order completion.
>>>
>>> Somewhat tangential, but it might also help to break the in-order
>>> completion processing in vhost_zerocopy_signal_used. Complete
>>> all descriptors between done_idx and upend_idx. done_idx should
>>> then only be forward to the oldest still not-completed descriptor.
>>>
>>> In the test I ran, where the oldest descriptors are held in a queue and
>>> all newer ones are tail-dropped,
>
>
> Do you mean the descriptors were tail-dropped by vhost?
Tail-dropped by netem. The dropped items are completed out of
order by vhost before the held items.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode
From: Jiri Pirko @ 2017-09-05 14:07 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, dsa, xiyou.wangcong, jhs
In-Reply-To: <1504615701-20912-1-git-send-email-nikolay@cumulusnetworks.com>
Tue, Sep 05, 2017 at 02:48:21PM CEST, nikolay@cumulusnetworks.com wrote:
>Hi all,
>This RFC adds a new mode for clsact which designates a device's egress
>classifier as global per netns. The packets that are not classified for
>a particular device will be classified using the global classifier.
>We have needed a global classifier for some time now for various
>purposes and setting the single bridge or loopback/vrf device as the
>global classifier device is acceptable for us. Doing it this way avoids
>the act/cls device and queue dependencies.
>
>This is strictly an RFC patch just to show the intent, if we agree on
>the details the proposed patch will have support for both ingress and
>egress, and will be using a static key to avoid the fast path test when no
>global classifier has been configured.
>
>Example (need a modified tc that adds TCA_OPTIONS when using q_clsact):
>$ tc qdisc add dev lo clsact global
>$ tc filter add dev lo egress protocol ip u32 match ip dst 4.3.2.1/32 action drop
>
>the last filter will be global for all devices that don't have a
>specific egress_cl_list (i.e. have clsact configured).
>
>Any comments and thoughts would be greatly appreciated.
Did you see my shared blocks work? I believe that it should resolve your
usecase, in a generic way. You just have to bind the devices you need to
the shared block. Please see the RFC:
https://www.spinics.net/lists/netdev/msg444067.html
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Hannes Frederic Sowa @ 2017-09-05 13:34 UTC (permalink / raw)
To: Jan Scheurich
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, e@erig.me
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D787F5650-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
Hello Jan,
Jan Scheurich <jan.scheurich-IzeFyvvaP7pWk0Htik3J/w@public.gmane.org> writes:
> Please have a look at the Google doc that sketches the overall
> solution to support NSH in OVS.
> https://drive.google.com/open?id=1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8
>
> In details it is slightly outdated but the NSH MD1 support (and all
> prerequisites like PTAP and Generic Encap/Decap) have been implemented
> in OVS 2.8 (ofproto layer and the userspace datapath).
>
> The NSH use cases are discussed in the chapter "Support for NSH". OVS
> is primarily targeting the Classifier and SFF use cases. Obviously the
> classifier must be able to set the MD1 context headers. The final SFF
> must be able to inspect the context headers, typically to determine
> the L2 or L3 forwarding context (e.g. VRF) in which to forward the
> decapsulated packet on to its final destination.
>From Yi Yang's mail I understood that you put a tunnel ID into
context[0]. In this case, I can understand that you want to match on
that. I was under the impression that the combination of tenant id from
the vxlan-gpe header and the path id plus ttl would give enough state
for the SDN to keep state on where the packet is in the network. I don't
understand what a tunnel id is.
I understood that the context fields are usable by the service function
chains, but they are actually in use by the outer SDN and basically
standardized.
> This information has end-to-end significance for the SFP and is
> encoded by the classifier in the NSH context headers. It cannot be put
> into transport tunnel options of e.g. a Geneve tunnel connecting two
> SFFs along the SFP.
Because the TLVs are not end to end in the geneve case? Yes, this makes
sense.
> We are now trying to establish feature parity in the kernel
> datapath. If the kernel datapath chooses not to support the MD1
> fields, OVS with kernel datapath will not be able to address the
> classifier and final SFF use cases.
As I understand this now, you are designing some kind of protocol or
particular implementation on top of NSH. Thus you don't expect masks to
grow limitless and you don't allow any SFC elements to take part in the
decision what to communicate over the context fields.
I still wonder about the hash as part of the NSH context and how that
fits into the picture, which looked like the only standardized
application of context headers from your google doc.
Btw., I don't want to block this patch.
Bye,
Hannes
^ permalink raw reply
* Re: [wireless-testsing2:master 4/5] drivers/net/ethernet/marvell/mvpp2.c:7618:49: error: passing argument 4 of 'mvpp2_port_copy_mac_addr' from incompatible pointer type
From: Bob Copeland @ 2017-09-05 13:29 UTC (permalink / raw)
To: kbuild test robot; +Cc: David S. Miller, kbuild-all, netdev
In-Reply-To: <201709052144.zyrDXrmL%fengguang.wu@intel.com>
My fault, mismerged a driver conflict -- will fix in next w-t build.
On Tue, Sep 05, 2017 at 09:16:48PM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git master
> head: d17be7f7503bf9492198a242779a68af93fd92de
> commit: 96c03618031bae5e9068b16f9e437b79f98f6482 [4/5] Merge remote-tracking branch 'mac80211-next/master'
> config: ia64-allyesconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 6.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 96c03618031bae5e9068b16f9e437b79f98f6482
> # save the attached .config to linux build tree
> make.cross ARCH=ia64
>
> All errors (new ones prefixed by >>):
>
> drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_port_probe':
> >> drivers/net/ethernet/marvell/mvpp2.c:7618:49: error: passing argument 4 of 'mvpp2_port_copy_mac_addr' from incompatible pointer type [-Werror=incompatible-pointer-types]
> mvpp2_port_copy_mac_addr(dev, priv, port_node, &mac_from);
--
Bob Copeland %% https://bobcopeland.com/
^ permalink raw reply
* [wireless-testsing2:master 4/5] drivers/net/ethernet/marvell/mvpp2.c:7618:49: error: passing argument 4 of 'mvpp2_port_copy_mac_addr' from incompatible pointer type
From: kbuild test robot @ 2017-09-05 13:16 UTC (permalink / raw)
To: David S. Miller; +Cc: kbuild-all, netdev, Bob Copeland
[-- Attachment #1: Type: text/plain, Size: 16168 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git master
head: d17be7f7503bf9492198a242779a68af93fd92de
commit: 96c03618031bae5e9068b16f9e437b79f98f6482 [4/5] Merge remote-tracking branch 'mac80211-next/master'
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 96c03618031bae5e9068b16f9e437b79f98f6482
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_port_probe':
>> drivers/net/ethernet/marvell/mvpp2.c:7618:49: error: passing argument 4 of 'mvpp2_port_copy_mac_addr' from incompatible pointer type [-Werror=incompatible-pointer-types]
mvpp2_port_copy_mac_addr(dev, priv, port_node, &mac_from);
^
drivers/net/ethernet/marvell/mvpp2.c:7468:13: note: expected 'char **' but argument is of type 'const char **'
static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 *priv,
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/marvell/mvpp2.c:7509:7: warning: unused variable 'hw_mac_addr' [-Wunused-variable]
char hw_mac_addr[ETH_ALEN] = {0};
^~~~~~~~~~~
drivers/net/ethernet/marvell/mvpp2.c:7507:14: warning: unused variable 'dt_mac_addr' [-Wunused-variable]
const char *dt_mac_addr;
^~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/mvpp2_port_copy_mac_addr +7618 drivers/net/ethernet/marvell/mvpp2.c
3ba8c81e1 Antoine Tenart 2017-09-02 7495
3f518509d Marcin Wojtas 2014-07-10 7496 /* Ports initialization */
3f518509d Marcin Wojtas 2014-07-10 7497 static int mvpp2_port_probe(struct platform_device *pdev,
3f518509d Marcin Wojtas 2014-07-10 7498 struct device_node *port_node,
59b9a31ed Thomas Petazzoni 2017-03-07 7499 struct mvpp2 *priv)
3f518509d Marcin Wojtas 2014-07-10 7500 {
3f518509d Marcin Wojtas 2014-07-10 7501 struct device_node *phy_node;
542897d98 Antoine Tenart 2017-08-30 7502 struct phy *comphy;
3f518509d Marcin Wojtas 2014-07-10 7503 struct mvpp2_port *port;
edc660fa0 Marcin Wojtas 2015-08-06 7504 struct mvpp2_port_pcpu *port_pcpu;
3f518509d Marcin Wojtas 2014-07-10 7505 struct net_device *dev;
3f518509d Marcin Wojtas 2014-07-10 7506 struct resource *res;
3f518509d Marcin Wojtas 2014-07-10 7507 const char *dt_mac_addr;
96c036180 Bob Copeland 2017-09-04 7508 const char *mac_from = "";
4c2286826 Antoine Tenart 2017-08-25 7509 char hw_mac_addr[ETH_ALEN] = {0};
09f839755 Thomas Petazzoni 2017-08-03 7510 unsigned int ntxqs, nrxqs;
213f428f5 Thomas Petazzoni 2017-08-03 7511 bool has_tx_irqs;
3f518509d Marcin Wojtas 2014-07-10 7512 u32 id;
3f518509d Marcin Wojtas 2014-07-10 7513 int features;
3f518509d Marcin Wojtas 2014-07-10 7514 int phy_mode;
edc660fa0 Marcin Wojtas 2015-08-06 7515 int err, i, cpu;
3f518509d Marcin Wojtas 2014-07-10 7516
213f428f5 Thomas Petazzoni 2017-08-03 7517 has_tx_irqs = mvpp2_port_has_tx_irqs(priv, port_node);
213f428f5 Thomas Petazzoni 2017-08-03 7518
213f428f5 Thomas Petazzoni 2017-08-03 7519 if (!has_tx_irqs)
213f428f5 Thomas Petazzoni 2017-08-03 7520 queue_mode = MVPP2_QDIST_SINGLE_MODE;
213f428f5 Thomas Petazzoni 2017-08-03 7521
09f839755 Thomas Petazzoni 2017-08-03 7522 ntxqs = MVPP2_MAX_TXQ;
213f428f5 Thomas Petazzoni 2017-08-03 7523 if (priv->hw_version == MVPP22 && queue_mode == MVPP2_QDIST_MULTI_MODE)
213f428f5 Thomas Petazzoni 2017-08-03 7524 nrxqs = MVPP2_DEFAULT_RXQ * num_possible_cpus();
213f428f5 Thomas Petazzoni 2017-08-03 7525 else
09f839755 Thomas Petazzoni 2017-08-03 7526 nrxqs = MVPP2_DEFAULT_RXQ;
09f839755 Thomas Petazzoni 2017-08-03 7527
09f839755 Thomas Petazzoni 2017-08-03 7528 dev = alloc_etherdev_mqs(sizeof(*port), ntxqs, nrxqs);
3f518509d Marcin Wojtas 2014-07-10 7529 if (!dev)
3f518509d Marcin Wojtas 2014-07-10 7530 return -ENOMEM;
3f518509d Marcin Wojtas 2014-07-10 7531
3f518509d Marcin Wojtas 2014-07-10 7532 phy_node = of_parse_phandle(port_node, "phy", 0);
3f518509d Marcin Wojtas 2014-07-10 7533 phy_mode = of_get_phy_mode(port_node);
3f518509d Marcin Wojtas 2014-07-10 7534 if (phy_mode < 0) {
3f518509d Marcin Wojtas 2014-07-10 7535 dev_err(&pdev->dev, "incorrect phy mode\n");
3f518509d Marcin Wojtas 2014-07-10 7536 err = phy_mode;
3f518509d Marcin Wojtas 2014-07-10 7537 goto err_free_netdev;
3f518509d Marcin Wojtas 2014-07-10 7538 }
3f518509d Marcin Wojtas 2014-07-10 7539
542897d98 Antoine Tenart 2017-08-30 7540 comphy = devm_of_phy_get(&pdev->dev, port_node, NULL);
542897d98 Antoine Tenart 2017-08-30 7541 if (IS_ERR(comphy)) {
542897d98 Antoine Tenart 2017-08-30 7542 if (PTR_ERR(comphy) == -EPROBE_DEFER) {
542897d98 Antoine Tenart 2017-08-30 7543 err = -EPROBE_DEFER;
542897d98 Antoine Tenart 2017-08-30 7544 goto err_free_netdev;
542897d98 Antoine Tenart 2017-08-30 7545 }
542897d98 Antoine Tenart 2017-08-30 7546 comphy = NULL;
542897d98 Antoine Tenart 2017-08-30 7547 }
542897d98 Antoine Tenart 2017-08-30 7548
3f518509d Marcin Wojtas 2014-07-10 7549 if (of_property_read_u32(port_node, "port-id", &id)) {
3f518509d Marcin Wojtas 2014-07-10 7550 err = -EINVAL;
3f518509d Marcin Wojtas 2014-07-10 7551 dev_err(&pdev->dev, "missing port-id value\n");
3f518509d Marcin Wojtas 2014-07-10 7552 goto err_free_netdev;
3f518509d Marcin Wojtas 2014-07-10 7553 }
3f518509d Marcin Wojtas 2014-07-10 7554
3f518509d Marcin Wojtas 2014-07-10 7555 dev->tx_queue_len = MVPP2_MAX_TXD;
3f518509d Marcin Wojtas 2014-07-10 7556 dev->watchdog_timeo = 5 * HZ;
3f518509d Marcin Wojtas 2014-07-10 7557 dev->netdev_ops = &mvpp2_netdev_ops;
3f518509d Marcin Wojtas 2014-07-10 7558 dev->ethtool_ops = &mvpp2_eth_tool_ops;
3f518509d Marcin Wojtas 2014-07-10 7559
3f518509d Marcin Wojtas 2014-07-10 7560 port = netdev_priv(dev);
591f4cfab Thomas Petazzoni 2017-08-03 7561 port->dev = dev;
09f839755 Thomas Petazzoni 2017-08-03 7562 port->ntxqs = ntxqs;
09f839755 Thomas Petazzoni 2017-08-03 7563 port->nrxqs = nrxqs;
213f428f5 Thomas Petazzoni 2017-08-03 7564 port->priv = priv;
213f428f5 Thomas Petazzoni 2017-08-03 7565 port->has_tx_irqs = has_tx_irqs;
3f518509d Marcin Wojtas 2014-07-10 7566
591f4cfab Thomas Petazzoni 2017-08-03 7567 err = mvpp2_queue_vectors_init(port, port_node);
591f4cfab Thomas Petazzoni 2017-08-03 7568 if (err)
3f518509d Marcin Wojtas 2014-07-10 7569 goto err_free_netdev;
3f518509d Marcin Wojtas 2014-07-10 7570
fd3651b2a Antoine Tenart 2017-09-01 7571 port->link_irq = of_irq_get_byname(port_node, "link");
fd3651b2a Antoine Tenart 2017-09-01 7572 if (port->link_irq == -EPROBE_DEFER) {
fd3651b2a Antoine Tenart 2017-09-01 7573 err = -EPROBE_DEFER;
fd3651b2a Antoine Tenart 2017-09-01 7574 goto err_deinit_qvecs;
fd3651b2a Antoine Tenart 2017-09-01 7575 }
fd3651b2a Antoine Tenart 2017-09-01 7576 if (port->link_irq <= 0)
fd3651b2a Antoine Tenart 2017-09-01 7577 /* the link irq is optional */
fd3651b2a Antoine Tenart 2017-09-01 7578 port->link_irq = 0;
fd3651b2a Antoine Tenart 2017-09-01 7579
3f518509d Marcin Wojtas 2014-07-10 7580 if (of_property_read_bool(port_node, "marvell,loopback"))
3f518509d Marcin Wojtas 2014-07-10 7581 port->flags |= MVPP2_F_LOOPBACK;
3f518509d Marcin Wojtas 2014-07-10 7582
3f518509d Marcin Wojtas 2014-07-10 7583 port->id = id;
59b9a31ed Thomas Petazzoni 2017-03-07 7584 if (priv->hw_version == MVPP21)
09f839755 Thomas Petazzoni 2017-08-03 7585 port->first_rxq = port->id * port->nrxqs;
59b9a31ed Thomas Petazzoni 2017-03-07 7586 else
59b9a31ed Thomas Petazzoni 2017-03-07 7587 port->first_rxq = port->id * priv->max_port_rxqs;
59b9a31ed Thomas Petazzoni 2017-03-07 7588
3f518509d Marcin Wojtas 2014-07-10 7589 port->phy_node = phy_node;
3f518509d Marcin Wojtas 2014-07-10 7590 port->phy_interface = phy_mode;
542897d98 Antoine Tenart 2017-08-30 7591 port->comphy = comphy;
3f518509d Marcin Wojtas 2014-07-10 7592
a786841df Thomas Petazzoni 2017-03-07 7593 if (priv->hw_version == MVPP21) {
a786841df Thomas Petazzoni 2017-03-07 7594 res = platform_get_resource(pdev, IORESOURCE_MEM, 2 + id);
3f518509d Marcin Wojtas 2014-07-10 7595 port->base = devm_ioremap_resource(&pdev->dev, res);
3f518509d Marcin Wojtas 2014-07-10 7596 if (IS_ERR(port->base)) {
3f518509d Marcin Wojtas 2014-07-10 7597 err = PTR_ERR(port->base);
fd3651b2a Antoine Tenart 2017-09-01 7598 goto err_free_irq;
3f518509d Marcin Wojtas 2014-07-10 7599 }
a786841df Thomas Petazzoni 2017-03-07 7600 } else {
a786841df Thomas Petazzoni 2017-03-07 7601 if (of_property_read_u32(port_node, "gop-port-id",
a786841df Thomas Petazzoni 2017-03-07 7602 &port->gop_id)) {
a786841df Thomas Petazzoni 2017-03-07 7603 err = -EINVAL;
a786841df Thomas Petazzoni 2017-03-07 7604 dev_err(&pdev->dev, "missing gop-port-id value\n");
591f4cfab Thomas Petazzoni 2017-08-03 7605 goto err_deinit_qvecs;
a786841df Thomas Petazzoni 2017-03-07 7606 }
a786841df Thomas Petazzoni 2017-03-07 7607
a786841df Thomas Petazzoni 2017-03-07 7608 port->base = priv->iface_base + MVPP22_GMAC_BASE(port->gop_id);
a786841df Thomas Petazzoni 2017-03-07 7609 }
3f518509d Marcin Wojtas 2014-07-10 7610
3f518509d Marcin Wojtas 2014-07-10 7611 /* Alloc per-cpu stats */
3f518509d Marcin Wojtas 2014-07-10 7612 port->stats = netdev_alloc_pcpu_stats(struct mvpp2_pcpu_stats);
3f518509d Marcin Wojtas 2014-07-10 7613 if (!port->stats) {
3f518509d Marcin Wojtas 2014-07-10 7614 err = -ENOMEM;
fd3651b2a Antoine Tenart 2017-09-01 7615 goto err_free_irq;
3f518509d Marcin Wojtas 2014-07-10 7616 }
3f518509d Marcin Wojtas 2014-07-10 7617
3ba8c81e1 Antoine Tenart 2017-09-02 @7618 mvpp2_port_copy_mac_addr(dev, priv, port_node, &mac_from);
3f518509d Marcin Wojtas 2014-07-10 7619
3f518509d Marcin Wojtas 2014-07-10 7620 port->tx_ring_size = MVPP2_MAX_TXD;
3f518509d Marcin Wojtas 2014-07-10 7621 port->rx_ring_size = MVPP2_MAX_RXD;
3f518509d Marcin Wojtas 2014-07-10 7622 SET_NETDEV_DEV(dev, &pdev->dev);
3f518509d Marcin Wojtas 2014-07-10 7623
3f518509d Marcin Wojtas 2014-07-10 7624 err = mvpp2_port_init(port);
3f518509d Marcin Wojtas 2014-07-10 7625 if (err < 0) {
3f518509d Marcin Wojtas 2014-07-10 7626 dev_err(&pdev->dev, "failed to init port %d\n", id);
3f518509d Marcin Wojtas 2014-07-10 7627 goto err_free_stats;
3f518509d Marcin Wojtas 2014-07-10 7628 }
269758214 Thomas Petazzoni 2017-03-07 7629
269758214 Thomas Petazzoni 2017-03-07 7630 mvpp2_port_periodic_xon_disable(port);
269758214 Thomas Petazzoni 2017-03-07 7631
269758214 Thomas Petazzoni 2017-03-07 7632 if (priv->hw_version == MVPP21)
269758214 Thomas Petazzoni 2017-03-07 7633 mvpp2_port_fc_adv_enable(port);
269758214 Thomas Petazzoni 2017-03-07 7634
269758214 Thomas Petazzoni 2017-03-07 7635 mvpp2_port_reset(port);
3f518509d Marcin Wojtas 2014-07-10 7636
edc660fa0 Marcin Wojtas 2015-08-06 7637 port->pcpu = alloc_percpu(struct mvpp2_port_pcpu);
edc660fa0 Marcin Wojtas 2015-08-06 7638 if (!port->pcpu) {
edc660fa0 Marcin Wojtas 2015-08-06 7639 err = -ENOMEM;
edc660fa0 Marcin Wojtas 2015-08-06 7640 goto err_free_txq_pcpu;
edc660fa0 Marcin Wojtas 2015-08-06 7641 }
edc660fa0 Marcin Wojtas 2015-08-06 7642
213f428f5 Thomas Petazzoni 2017-08-03 7643 if (!port->has_tx_irqs) {
edc660fa0 Marcin Wojtas 2015-08-06 7644 for_each_present_cpu(cpu) {
edc660fa0 Marcin Wojtas 2015-08-06 7645 port_pcpu = per_cpu_ptr(port->pcpu, cpu);
edc660fa0 Marcin Wojtas 2015-08-06 7646
edc660fa0 Marcin Wojtas 2015-08-06 7647 hrtimer_init(&port_pcpu->tx_done_timer, CLOCK_MONOTONIC,
edc660fa0 Marcin Wojtas 2015-08-06 7648 HRTIMER_MODE_REL_PINNED);
edc660fa0 Marcin Wojtas 2015-08-06 7649 port_pcpu->tx_done_timer.function = mvpp2_hr_timer_cb;
edc660fa0 Marcin Wojtas 2015-08-06 7650 port_pcpu->timer_scheduled = false;
edc660fa0 Marcin Wojtas 2015-08-06 7651
213f428f5 Thomas Petazzoni 2017-08-03 7652 tasklet_init(&port_pcpu->tx_done_tasklet,
213f428f5 Thomas Petazzoni 2017-08-03 7653 mvpp2_tx_proc_cb,
edc660fa0 Marcin Wojtas 2015-08-06 7654 (unsigned long)dev);
edc660fa0 Marcin Wojtas 2015-08-06 7655 }
213f428f5 Thomas Petazzoni 2017-08-03 7656 }
edc660fa0 Marcin Wojtas 2015-08-06 7657
186cd4d4e Antoine Tenart 2017-08-23 7658 features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
3f518509d Marcin Wojtas 2014-07-10 7659 dev->features = features | NETIF_F_RXCSUM;
3f518509d Marcin Wojtas 2014-07-10 7660 dev->hw_features |= features | NETIF_F_RXCSUM | NETIF_F_GRO;
3f518509d Marcin Wojtas 2014-07-10 7661 dev->vlan_features |= features;
3f518509d Marcin Wojtas 2014-07-10 7662
5777987e0 Jarod Wilson 2016-10-17 7663 /* MTU range: 68 - 9676 */
5777987e0 Jarod Wilson 2016-10-17 7664 dev->min_mtu = ETH_MIN_MTU;
5777987e0 Jarod Wilson 2016-10-17 7665 /* 9676 == 9700 - 20 and rounding to 8 */
5777987e0 Jarod Wilson 2016-10-17 7666 dev->max_mtu = 9676;
5777987e0 Jarod Wilson 2016-10-17 7667
3f518509d Marcin Wojtas 2014-07-10 7668 err = register_netdev(dev);
3f518509d Marcin Wojtas 2014-07-10 7669 if (err < 0) {
3f518509d Marcin Wojtas 2014-07-10 7670 dev_err(&pdev->dev, "failed to register netdev\n");
edc660fa0 Marcin Wojtas 2015-08-06 7671 goto err_free_port_pcpu;
3f518509d Marcin Wojtas 2014-07-10 7672 }
3f518509d Marcin Wojtas 2014-07-10 7673 netdev_info(dev, "Using %s mac address %pM\n", mac_from, dev->dev_addr);
3f518509d Marcin Wojtas 2014-07-10 7674
3f518509d Marcin Wojtas 2014-07-10 7675 priv->port_list[id] = port;
3f518509d Marcin Wojtas 2014-07-10 7676 return 0;
3f518509d Marcin Wojtas 2014-07-10 7677
edc660fa0 Marcin Wojtas 2015-08-06 7678 err_free_port_pcpu:
edc660fa0 Marcin Wojtas 2015-08-06 7679 free_percpu(port->pcpu);
3f518509d Marcin Wojtas 2014-07-10 7680 err_free_txq_pcpu:
09f839755 Thomas Petazzoni 2017-08-03 7681 for (i = 0; i < port->ntxqs; i++)
3f518509d Marcin Wojtas 2014-07-10 7682 free_percpu(port->txqs[i]->pcpu);
3f518509d Marcin Wojtas 2014-07-10 7683 err_free_stats:
3f518509d Marcin Wojtas 2014-07-10 7684 free_percpu(port->stats);
fd3651b2a Antoine Tenart 2017-09-01 7685 err_free_irq:
fd3651b2a Antoine Tenart 2017-09-01 7686 if (port->link_irq)
fd3651b2a Antoine Tenart 2017-09-01 7687 irq_dispose_mapping(port->link_irq);
591f4cfab Thomas Petazzoni 2017-08-03 7688 err_deinit_qvecs:
591f4cfab Thomas Petazzoni 2017-08-03 7689 mvpp2_queue_vectors_deinit(port);
3f518509d Marcin Wojtas 2014-07-10 7690 err_free_netdev:
ccb80393c Peter Chen 2016-08-01 7691 of_node_put(phy_node);
3f518509d Marcin Wojtas 2014-07-10 7692 free_netdev(dev);
3f518509d Marcin Wojtas 2014-07-10 7693 return err;
3f518509d Marcin Wojtas 2014-07-10 7694 }
3f518509d Marcin Wojtas 2014-07-10 7695
:::::: The code at line 7618 was first introduced by commit
:::::: 3ba8c81e15c11fc396d0b5d11adaf9db6ed39533 net: mvpp2: move the mac retrieval/copy logic into its own function
:::::: TO: Antoine Tenart <antoine.tenart@free-electrons.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51551 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Hannes Frederic Sowa @ 2017-09-05 13:12 UTC (permalink / raw)
To: Yang, Yi
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, e@erig.me
In-Reply-To: <20170905113848.GC92895-re2EX8HDrk21gSHoDXDV2kEOCMrvLtNR@public.gmane.org>
"Yang, Yi" <yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:
> On Tue, Sep 05, 2017 at 12:30:09PM +0200, Hannes Frederic Sowa wrote:
>> "Yang, Yi" <yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:
>>
>> > I'm not sure what new action you expect to bring here, I think group
>> > action is just for this, as you said it isn't only bound to NSH, you can
>> > start a new thread to discuss this. I don't think it is in scope of NSH.
>>
>> It is in scope of this discussion as you will provide a user space API
>> that makes the NSH context fields accessible from user space in a
>> certain way. If you commit to this, there is no way going back.
>
> We can change this later if we really find a better way to handle this
> because it isn't defined in include/uapi/linux/openvswitch.h, so I still
> have backdoor to do this if needed :-)
Sorry, I can't follow you.
It doesn't matter if something is defined in uapi headers, the
observable behavior matters. If you allow users to configure flows with
specific fields, it should not stop working at a future point in time.
>> I haven't yet grasped the idea on how those fields will be used in OVS
>> besides load balancing. Even for load balancing the tunnel itself
>> (vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough
>> entropy to do per-flow load balancing. What else is needed? Why a
>> context header for that? You just need multiple action chains and pick
>> one randomly.
>
> For our sfc use case in Opendaylight, we use context[0] for tunnel ID,
> context[1] for destination IP for reverse RSP, they are used to match
> and set in OpenFlow table, you can't limit users to use them in such
> ways.
So in your specific case you expect the masks to be completely stable
because you defined a protocol on top of NSH, understood. And that is
stable accross all possible paths. Understood as well.
> If you check GENEVE implementation, tun_metadata* can be set or matched
> as any other match field.
Yes, I wrote that in my previous mail. I wonder why NSH context metadata
is not in tun_metadata as well?
> Actually the most important information in NSH are just these context
> headers, you can't limit imagination of users by removing them from flow
> keys.
>
> My point is to bring miniflow into kernel data path to fix your concern,
> this will benefit your employer directly :-)
Okay, interesting. It will probably not help if you still have a hash of
a packet inside the flow table and use that for load balancing.
[...]
BTW I don't want to stop this patch, I am merely interested in how the
bigger picture will look like in the end.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH] connector: Delete an error message for a failed memory allocation in cn_queue_alloc_callback_entry()
From: Evgeniy Polyakov @ 2017-09-05 13:10 UTC (permalink / raw)
To: SF Markus Elfring, netdev@vger.kernel.org
Cc: LKML, kernel-janitors@vger.kernel.org
In-Reply-To: <7b206228-b3e9-5cb9-873c-75b5d8aae23b@users.sourceforge.net>
Hi everyone
27.08.2017, 22:25, "SF Markus Elfring" <elfring@users.sourceforge.net>:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 27 Aug 2017 21:18:37 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Looks good to me, thanks Markus.
There is virtually zero useful information in this print if we are in the situation, when kernel can not allocate
a few bytes to run connector queue.
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
kernel-janitors@ please queue this patch up
> ---
> drivers/connector/cn_queue.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
> index 1f8bf054d11c..e4f31d679f02 100644
> --- a/drivers/connector/cn_queue.c
> +++ b/drivers/connector/cn_queue.c
> @@ -40,10 +40,8 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const char *name,
> struct cn_callback_entry *cbq;
>
> cbq = kzalloc(sizeof(*cbq), GFP_KERNEL);
> - if (!cbq) {
> - pr_err("Failed to create new callback queue.\n");
> + if (!cbq)
> return NULL;
> - }
>
> atomic_set(&cbq->refcnt, 1);
>
> --
> 2.14.1
^ permalink raw reply
* [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode
From: Nikolay Aleksandrov @ 2017-09-05 12:48 UTC (permalink / raw)
To: netdev; +Cc: roopa, dsa, jiri, xiyou.wangcong, jhs, Nikolay Aleksandrov
Hi all,
This RFC adds a new mode for clsact which designates a device's egress
classifier as global per netns. The packets that are not classified for
a particular device will be classified using the global classifier.
We have needed a global classifier for some time now for various
purposes and setting the single bridge or loopback/vrf device as the
global classifier device is acceptable for us. Doing it this way avoids
the act/cls device and queue dependencies.
This is strictly an RFC patch just to show the intent, if we agree on
the details the proposed patch will have support for both ingress and
egress, and will be using a static key to avoid the fast path test when no
global classifier has been configured.
Example (need a modified tc that adds TCA_OPTIONS when using q_clsact):
$ tc qdisc add dev lo clsact global
$ tc filter add dev lo egress protocol ip u32 match ip dst 4.3.2.1/32 action drop
the last filter will be global for all devices that don't have a
specific egress_cl_list (i.e. have clsact configured).
Any comments and thoughts would be greatly appreciated.
Thanks!
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
include/linux/rtnetlink.h | 1 +
include/net/net_namespace.h | 3 +++
include/net/sch_generic.h | 1 +
net/core/dev.c | 36 ++++++++++++++++++++++++++++++++++--
net/sched/sch_ingress.c | 15 +++++++++++++--
5 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index dea59c8eec54..cb97973b8555 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -88,6 +88,7 @@ void net_dec_ingress_queue(void);
#ifdef CONFIG_NET_EGRESS
void net_inc_egress_queue(void);
void net_dec_egress_queue(void);
+int net_set_global_egress_cls_dev(struct net *net, struct net_device *dev);
#endif
void rtnetlink_init(void);
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 57faa375eab9..3fef53dfdbfc 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -149,6 +149,9 @@ struct net {
#endif
struct sock *diag_nlsk;
atomic_t fnhe_genid;
+#ifdef CONFIG_NET_EGRESS
+ struct net_device __rcu *global_egress_dev;
+#endif
} __randomize_layout;
#include <linux/seq_file_net.h>
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 135f5a2dd931..a37c37062446 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -69,6 +69,7 @@ struct Qdisc {
* qdisc_tree_decrease_qlen() should stop.
*/
#define TCQ_F_INVISIBLE 0x80 /* invisible by default in dump */
+#define TCQ_F_GLOBAL 0x100 /* device is used as global clsact dev */
u32 limit;
const struct Qdisc_ops *ops;
struct qdisc_size_table __rcu *stab;
diff --git a/net/core/dev.c b/net/core/dev.c
index 6f845e4fec17..cf883b2470a5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1718,6 +1718,31 @@ void net_dec_egress_queue(void)
static_key_slow_dec(&egress_needed);
}
EXPORT_SYMBOL_GPL(net_dec_egress_queue);
+
+int net_set_global_egress_cls_dev(struct net *net, struct net_device *dev)
+{
+ struct net_device *cur_dev;
+
+ ASSERT_RTNL();
+
+ cur_dev = rtnl_dereference(net->global_egress_dev);
+ if (dev) {
+ /* replace not allowed */
+ if (cur_dev)
+ return -EBUSY;
+ /* global cls devices should not change netns */
+ if (!(dev->features & NETIF_F_NETNS_LOCAL))
+ return -EINVAL;
+ }
+
+ /* set or clear based on dev */
+ rcu_assign_pointer(net->global_egress_dev, dev);
+ if (!dev)
+ synchronize_rcu_bh();
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(net_set_global_egress_cls_dev);
#endif
static struct static_key netstamp_needed __read_mostly;
@@ -3244,8 +3269,15 @@ sch_handle_egress(struct sk_buff *skb, int *ret, struct net_device *dev)
struct tcf_proto *cl = rcu_dereference_bh(dev->egress_cl_list);
struct tcf_result cl_res;
- if (!cl)
- return skb;
+ if (!cl) {
+ struct net_device *gdev;
+
+ gdev = rcu_dereference_bh(dev_net(dev)->global_egress_dev);
+ if (gdev)
+ cl = rcu_dereference_bh(gdev->egress_cl_list);
+ if (!cl)
+ return skb;
+ }
/* qdisc_skb_cb(skb)->pkt_len was already set by the caller. */
qdisc_bstats_cpu_update(cl->q, skb);
diff --git a/net/sched/sch_ingress.c b/net/sched/sch_ingress.c
index 44de4ee51ce9..a4871f138904 100644
--- a/net/sched/sch_ingress.c
+++ b/net/sched/sch_ingress.c
@@ -153,6 +153,9 @@ static int clsact_init(struct Qdisc *sch, struct nlattr *opt)
struct net_device *dev = qdisc_dev(sch);
int err;
+ net_inc_ingress_queue();
+ net_inc_egress_queue();
+
err = tcf_block_get(&q->ingress_block, &dev->ingress_cl_list);
if (err)
return err;
@@ -161,8 +164,12 @@ static int clsact_init(struct Qdisc *sch, struct nlattr *opt)
if (err)
return err;
- net_inc_ingress_queue();
- net_inc_egress_queue();
+ if (opt) {
+ err = net_set_global_egress_cls_dev(dev_net(dev), dev);
+ if (err)
+ return err;
+ sch->flags |= TCQ_F_GLOBAL;
+ }
sch->flags |= TCQ_F_CPUSTATS;
@@ -172,6 +179,10 @@ static int clsact_init(struct Qdisc *sch, struct nlattr *opt)
static void clsact_destroy(struct Qdisc *sch)
{
struct clsact_sched_data *q = qdisc_priv(sch);
+ struct net_device *dev = qdisc_dev(sch);
+
+ if (sch->flags & TCQ_F_GLOBAL)
+ WARN_ON_ONCE(net_set_global_egress_cls_dev(dev_net(dev), NULL));
tcf_block_put(q->egress_block);
tcf_block_put(q->ingress_block);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net] net: sched: don't use GFP_KERNEL under spin lock
From: Jiri Pirko @ 2017-09-05 12:52 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20170905115948.2fd38785@cakuba.netronome.com>
Tue, Sep 05, 2017 at 12:59:48PM CEST, kubakici@wp.pl wrote:
>Jiri, FWIW I also just noticed these, but they seem related to the
>earlier TC chain work?
What do you do to trigger this?
>
>unreferenced object 0xffff8807466f70c8 (size 64):
> comm "tc", pid 1812, jiffies 4294932641 (age 1537.192s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 a0 83 e1 31 07 88 ff ff ...........1....
> d8 70 6f 46 07 88 ff ff d8 70 6f 46 07 88 ff ff .poF.....poF....
> backtrace:
> [<ffffffffaa6b0118>] kmemleak_alloc+0x28/0x50
> [<ffffffffa89a89b6>] kmem_cache_alloc_trace+0x1e6/0x550
> [<ffffffffaa102827>] tcf_chain_create+0x97/0x460
> [<ffffffffaa102f67>] tcf_block_get+0x127/0x230
> [<ffffffffc03e8546>] ingress_init+0x76/0x110 [sch_ingress]
> [<ffffffffaa0fbb1c>] qdisc_create+0x2ec/0x1100
> [<ffffffffaa0fce1a>] tc_modify_qdisc+0x4ea/0x1ae0
> [<ffffffffaa0355dc>] rtnetlink_rcv_msg+0xa3c/0x1400
> [<ffffffffaa12e3cb>] netlink_rcv_skb+0x22b/0x4e0
> [<ffffffffaa024b55>] rtnetlink_rcv+0x15/0x20
> [<ffffffffaa12bddd>] netlink_unicast+0x47d/0x710
> [<ffffffffaa12caef>] netlink_sendmsg+0xa7f/0x1140
> [<ffffffffa9f15c52>] sock_sendmsg+0xe2/0x170
> [<ffffffffa9f188bd>] ___sys_sendmsg+0x72d/0xcc0
> [<ffffffffa9f1bfa2>] __sys_sendmsg+0xe2/0x260
> [<ffffffffa9f1c132>] SyS_sendmsg+0x12/0x20
>unreferenced object 0xffff88074db6c008 (size 64):
> comm "tc", pid 2097, jiffies 4294953636 (age 1453.212s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 60 a6 d1 31 07 88 ff ff ........`..1....
> 18 c0 b6 4d 07 88 ff ff 18 c0 b6 4d 07 88 ff ff ...M.......M....
> backtrace:
> [<ffffffffaa6b0118>] kmemleak_alloc+0x28/0x50
> [<ffffffffa89a89b6>] kmem_cache_alloc_trace+0x1e6/0x550
> [<ffffffffaa102827>] tcf_chain_create+0x97/0x460
> [<ffffffffaa102f67>] tcf_block_get+0x127/0x230
> [<ffffffffc03e8546>] ingress_init+0x76/0x110 [sch_ingress]
> [<ffffffffaa0fbb1c>] qdisc_create+0x2ec/0x1100
> [<ffffffffaa0fce1a>] tc_modify_qdisc+0x4ea/0x1ae0
> [<ffffffffaa0355dc>] rtnetlink_rcv_msg+0xa3c/0x1400
> [<ffffffffaa12e3cb>] netlink_rcv_skb+0x22b/0x4e0
> [<ffffffffaa024b55>] rtnetlink_rcv+0x15/0x20
> [<ffffffffaa12bddd>] netlink_unicast+0x47d/0x710
> [<ffffffffaa12caef>] netlink_sendmsg+0xa7f/0x1140
> [<ffffffffa9f15c52>] sock_sendmsg+0xe2/0x170
> [<ffffffffa9f188bd>] ___sys_sendmsg+0x72d/0xcc0
> [<ffffffffa9f1bfa2>] __sys_sendmsg+0xe2/0x260
> [<ffffffffa9f1c132>] SyS_sendmsg+0x12/0x20
>unreferenced object 0xffff880749f82a48 (size 64):
> comm "tc", pid 2381, jiffies 4294972986 (age 1375.812s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 c0 b7 31 31 07 88 ff ff ..........11....
> 58 2a f8 49 07 88 ff ff 58 2a f8 49 07 88 ff ff X*.I....X*.I....
> backtrace:
> [<ffffffffaa6b0118>] kmemleak_alloc+0x28/0x50
> [<ffffffffa89a89b6>] kmem_cache_alloc_trace+0x1e6/0x550
> [<ffffffffaa102827>] tcf_chain_create+0x97/0x460
> [<ffffffffaa102f67>] tcf_block_get+0x127/0x230
> [<ffffffffc03e8546>] ingress_init+0x76/0x110 [sch_ingress]
> [<ffffffffaa0fbb1c>] qdisc_create+0x2ec/0x1100
> [<ffffffffaa0fce1a>] tc_modify_qdisc+0x4ea/0x1ae0
> [<ffffffffaa0355dc>] rtnetlink_rcv_msg+0xa3c/0x1400
> [<ffffffffaa12e3cb>] netlink_rcv_skb+0x22b/0x4e0
> [<ffffffffaa024b55>] rtnetlink_rcv+0x15/0x20
> [<ffffffffaa12bddd>] netlink_unicast+0x47d/0x710
> [<ffffffffaa12caef>] netlink_sendmsg+0xa7f/0x1140
> [<ffffffffa9f15c52>] sock_sendmsg+0xe2/0x170
> [<ffffffffa9f188bd>] ___sys_sendmsg+0x72d/0xcc0
> [<ffffffffa9f1bfa2>] __sys_sendmsg+0xe2/0x260
> [<ffffffffa9f1c132>] SyS_sendmsg+0x12/0x20
>unreferenced object 0xffff8803fd855a08 (size 64):
> comm "tc", pid 2663, jiffies 4294992152 (age 1299.328s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 20 49 80 31 07 88 ff ff ........ I.1....
> 18 5a 85 fd 03 88 ff ff 18 5a 85 fd 03 88 ff ff .Z.......Z......
> backtrace:
> [<ffffffffaa6b0118>] kmemleak_alloc+0x28/0x50
> [<ffffffffa89a89b6>] kmem_cache_alloc_trace+0x1e6/0x550
> [<ffffffffaa102827>] tcf_chain_create+0x97/0x460
> [<ffffffffaa102f67>] tcf_block_get+0x127/0x230
> [<ffffffffc03e8546>] ingress_init+0x76/0x110 [sch_ingress]
> [<ffffffffaa0fbb1c>] qdisc_create+0x2ec/0x1100
> [<ffffffffaa0fce1a>] tc_modify_qdisc+0x4ea/0x1ae0
> [<ffffffffaa0355dc>] rtnetlink_rcv_msg+0xa3c/0x1400
> [<ffffffffaa12e3cb>] netlink_rcv_skb+0x22b/0x4e0
> [<ffffffffaa024b55>] rtnetlink_rcv+0x15/0x20
> [<ffffffffaa12bddd>] netlink_unicast+0x47d/0x710
> [<ffffffffaa12caef>] netlink_sendmsg+0xa7f/0x1140
> [<ffffffffa9f15c52>] sock_sendmsg+0xe2/0x170
> [<ffffffffa9f188bd>] ___sys_sendmsg+0x72d/0xcc0
> [<ffffffffa9f1bfa2>] __sys_sendmsg+0xe2/0x260
> [<ffffffffa9f1c132>] SyS_sendmsg+0x12/0x20
>unreferenced object 0xffff88071b096f28 (size 64):
> comm "tc", pid 2943, jiffies 4295013397 (age 1214.352s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 c0 37 e7 30 07 88 ff ff .........7.0....
> 38 6f 09 1b 07 88 ff ff 38 6f 09 1b 07 88 ff ff 8o......8o......
> backtrace:
> [<ffffffffaa6b0118>] kmemleak_alloc+0x28/0x50
> [<ffffffffa89a89b6>] kmem_cache_alloc_trace+0x1e6/0x550
> [<ffffffffaa102827>] tcf_chain_create+0x97/0x460
> [<ffffffffaa102f67>] tcf_block_get+0x127/0x230
> [<ffffffffc03e8546>] ingress_init+0x76/0x110 [sch_ingress]
> [<ffffffffaa0fbb1c>] qdisc_create+0x2ec/0x1100
> [<ffffffffaa0fce1a>] tc_modify_qdisc+0x4ea/0x1ae0
> [<ffffffffaa0355dc>] rtnetlink_rcv_msg+0xa3c/0x1400
> [<ffffffffaa12e3cb>] netlink_rcv_skb+0x22b/0x4e0
> [<ffffffffaa024b55>] rtnetlink_rcv+0x15/0x20
> [<ffffffffaa12bddd>] netlink_unicast+0x47d/0x710
> [<ffffffffaa12caef>] netlink_sendmsg+0xa7f/0x1140
> [<ffffffffa9f15c52>] sock_sendmsg+0xe2/0x170
> [<ffffffffa9f188bd>] ___sys_sendmsg+0x72d/0xcc0
> [<ffffffffa9f1bfa2>] __sys_sendmsg+0xe2/0x260
> [<ffffffffa9f1c132>] SyS_sendmsg+0x12/0x20
>unreferenced object 0xffff880731f66568 (size 64):
> comm "tc", pid 3263, jiffies 4295033366 (age 1134.480s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 95 64 65 07 88 ff ff ..........de....
> 78 65 f6 31 07 88 ff ff 78 65 f6 31 07 88 ff ff xe.1....xe.1....
> backtrace:
> [<ffffffffaa6b0118>] kmemleak_alloc+0x28/0x50
> [<ffffffffa89a89b6>] kmem_cache_alloc_trace+0x1e6/0x550
> [<ffffffffaa102827>] tcf_chain_create+0x97/0x460
> [<ffffffffaa102f67>] tcf_block_get+0x127/0x230
> [<ffffffffc03e8546>] ingress_init+0x76/0x110 [sch_ingress]
> [<ffffffffaa0fbb1c>] qdisc_create+0x2ec/0x1100
> [<ffffffffaa0fce1a>] tc_modify_qdisc+0x4ea/0x1ae0
> [<ffffffffaa0355dc>] rtnetlink_rcv_msg+0xa3c/0x1400
> [<ffffffffaa12e3cb>] netlink_rcv_skb+0x22b/0x4e0
> [<ffffffffaa024b55>] rtnetlink_rcv+0x15/0x20
> [<ffffffffaa12bddd>] netlink_unicast+0x47d/0x710
> [<ffffffffaa12caef>] netlink_sendmsg+0xa7f/0x1140
> [<ffffffffa9f15c52>] sock_sendmsg+0xe2/0x170
> [<ffffffffa9f188bd>] ___sys_sendmsg+0x72d/0xcc0
> [<ffffffffa9f1bfa2>] __sys_sendmsg+0xe2/0x260
> [<ffffffffa9f1c132>] SyS_sendmsg+0x12/0x20
^ permalink raw reply
* [PATCH v8 20/20] crypto: adapt api sample to use async. op wait
From: Gilad Ben-Yossef @ 2017-09-05 12:38 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Shaohua Li, Steve French, Theodore Y. Ts'o, Jaegeuk Kim,
Steffen Klassert, Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin, James Morris, Serge E. Hallyn, linux-crypto,
linux-doc, linux-kernel, keyrings, linux-arm-kernel,
linux-mediatek, linux-raid, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
Cc: Ofir Drang
In-Reply-To: <1504615144-29770-1-git-send-email-gilad@benyossef.com>
The code sample is waiting for an async. crypto op completion.
Adapt sample to use the new generic infrastructure to do the same.
This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
async op finishing.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
Documentation/crypto/api-samples.rst | 52 +++++++-----------------------------
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/Documentation/crypto/api-samples.rst b/Documentation/crypto/api-samples.rst
index 2531948..006827e 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -7,59 +7,27 @@ Code Example For Symmetric Key Cipher Operation
::
- struct tcrypt_result {
- struct completion completion;
- int err;
- };
-
/* tie all data structures together */
struct skcipher_def {
struct scatterlist sg;
struct crypto_skcipher *tfm;
struct skcipher_request *req;
- struct tcrypt_result result;
+ struct crypto_wait wait;
};
- /* Callback function */
- static void test_skcipher_cb(struct crypto_async_request *req, int error)
- {
- struct tcrypt_result *result = req->data;
-
- if (error == -EINPROGRESS)
- return;
- result->err = error;
- complete(&result->completion);
- pr_info("Encryption finished successfully\n");
- }
-
/* Perform cipher operation */
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
int enc)
{
- int rc = 0;
+ int rc;
if (enc)
- rc = crypto_skcipher_encrypt(sk->req);
+ rc = crypto_wait_req(crypto_skcipher_encrypt(sk->req), &sk->wait);
else
- rc = crypto_skcipher_decrypt(sk->req);
-
- switch (rc) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- rc = wait_for_completion_interruptible(
- &sk->result.completion);
- if (!rc && !sk->result.err) {
- reinit_completion(&sk->result.completion);
- break;
- }
- default:
- pr_info("skcipher encrypt returned with %d result %d\n",
- rc, sk->result.err);
- break;
- }
- init_completion(&sk->result.completion);
+ rc = crypto_wait_req(crypto_skcipher_decrypt(sk->req), &sk->wait);
+
+ if (rc)
+ pr_info("skcipher encrypt returned with result %d\n", rc);
return rc;
}
@@ -89,8 +57,8 @@ Code Example For Symmetric Key Cipher Operation
}
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- test_skcipher_cb,
- &sk.result);
+ crypto_req_done,
+ &sk.wait);
/* AES 256 with random key */
get_random_bytes(&key, 32);
@@ -122,7 +90,7 @@ Code Example For Symmetric Key Cipher Operation
/* We encrypt one block */
sg_init_one(&sk.sg, scratchpad, 16);
skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
- init_completion(&sk.result.completion);
+ crypto_init_wait(&sk.wait);
/* encrypt data */
ret = test_skcipher_encdec(&sk, 1);
--
2.1.4
^ permalink raw reply related
* [PATCH v8 20/20] crypto: adapt api sample to use async. op wait
From: Gilad Ben-Yossef @ 2017-09-05 12:38 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Shaohua Li, Steve French, Theodore Y. Ts'o, Jaegeuk Kim,
Steffen Klassert, Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar
Cc: Ofir Drang
In-Reply-To: <1504615144-29770-1-git-send-email-gilad@benyossef.com>
The code sample is waiting for an async. crypto op completion.
Adapt sample to use the new generic infrastructure to do the same.
This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
async op finishing.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
Documentation/crypto/api-samples.rst | 52 +++++++-----------------------------
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/Documentation/crypto/api-samples.rst b/Documentation/crypto/api-samples.rst
index 2531948..006827e 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -7,59 +7,27 @@ Code Example For Symmetric Key Cipher Operation
::
- struct tcrypt_result {
- struct completion completion;
- int err;
- };
-
/* tie all data structures together */
struct skcipher_def {
struct scatterlist sg;
struct crypto_skcipher *tfm;
struct skcipher_request *req;
- struct tcrypt_result result;
+ struct crypto_wait wait;
};
- /* Callback function */
- static void test_skcipher_cb(struct crypto_async_request *req, int error)
- {
- struct tcrypt_result *result = req->data;
-
- if (error == -EINPROGRESS)
- return;
- result->err = error;
- complete(&result->completion);
- pr_info("Encryption finished successfully\n");
- }
-
/* Perform cipher operation */
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
int enc)
{
- int rc = 0;
+ int rc;
if (enc)
- rc = crypto_skcipher_encrypt(sk->req);
+ rc = crypto_wait_req(crypto_skcipher_encrypt(sk->req), &sk->wait);
else
- rc = crypto_skcipher_decrypt(sk->req);
-
- switch (rc) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- rc = wait_for_completion_interruptible(
- &sk->result.completion);
- if (!rc && !sk->result.err) {
- reinit_completion(&sk->result.completion);
- break;
- }
- default:
- pr_info("skcipher encrypt returned with %d result %d\n",
- rc, sk->result.err);
- break;
- }
- init_completion(&sk->result.completion);
+ rc = crypto_wait_req(crypto_skcipher_decrypt(sk->req), &sk->wait);
+
+ if (rc)
+ pr_info("skcipher encrypt returned with result %d\n", rc);
return rc;
}
@@ -89,8 +57,8 @@ Code Example For Symmetric Key Cipher Operation
}
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- test_skcipher_cb,
- &sk.result);
+ crypto_req_done,
+ &sk.wait);
/* AES 256 with random key */
get_random_bytes(&key, 32);
@@ -122,7 +90,7 @@ Code Example For Symmetric Key Cipher Operation
/* We encrypt one block */
sg_init_one(&sk.sg, scratchpad, 16);
skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
- init_completion(&sk.result.completion);
+ crypto_init_wait(&sk.wait);
/* encrypt data */
ret = test_skcipher_encdec(&sk, 1);
--
2.1.4
^ 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