* Re: [PATCH v2] neighbour: confirm neigh entries when ARP packet is received
From: Stephen Hemminger @ 2018-09-11 18:12 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: David S. Miller, Roopa Prabhu, Alexey Dobriyan, Eric Dumazet,
Jim Westfall, Wolfgang Bumiller, Vasily Khoruzhick, Kees Cook,
Ihar Hrachyshka, netdev, linux-kernel
In-Reply-To: <20180911180406.31283-1-vasilykh@arista.com>
On Tue, 11 Sep 2018 11:04:06 -0700
Vasily Khoruzhick <vasilykh@arista.com> wrote:
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index aa19d86937af..56a554597db5 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -1180,6 +1180,12 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
> lladdr = neigh->ha;
> }
>
> + /* Update confirmed timestamp for neighbour entry after we
> + * received ARP packet even if it doesn't change IP to MAC binding.
> + */
> + if (new & NUD_CONNECTED)
> + neigh->confirmed = jiffies;
You might want to do:
if ((new & NUD_CONNECTED) && neigh->confirmed != jiffies)
neigh->confirmed = jiffies;
This avoid poisoning the cacheline with unnecessary write.
^ permalink raw reply
* Re: [PATCH net-next v3 17/17] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-09-11 13:17 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, davem, gregkh,
Jason A. Donenfeld
In-Reply-To: <20180911010838.8818-19-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 5539 bytes --]
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180911-185037
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/vfp/vfphw.S: Assembler messages:
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c0' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c1' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c2' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c3' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c4' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c5' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c6' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c7' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c8' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c9' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c10' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c11' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c12' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c13' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c14' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c15' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c0' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c1' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c2' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c3' in ARM mode
vim +299 arch/arm/vfp/vfphw.S
^1da177e Linus Torvalds 2005-04-16 285
93ed3970 Catalin Marinas 2008-08-28 286 ENTRY(vfp_get_double)
07f33a03 Catalin Marinas 2009-07-24 287 tbl_branch r0, r3, #3
^1da177e Linus Torvalds 2005-04-16 288 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
07f33a03 Catalin Marinas 2009-07-24 289 1: fmrrd r0, r1, d\dr
6ebbf2ce Russell King 2014-06-30 290 ret lr
07f33a03 Catalin Marinas 2009-07-24 291 .org 1b + 8
^1da177e Linus Torvalds 2005-04-16 292 .endr
25ebee02 Catalin Marinas 2007-09-25 293 #ifdef CONFIG_VFPv3
25ebee02 Catalin Marinas 2007-09-25 294 @ d16 - d31 registers
25ebee02 Catalin Marinas 2007-09-25 295 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
07f33a03 Catalin Marinas 2009-07-24 296 1: mrrc p11, 3, r0, r1, c\dr @ fmrrd r0, r1, d\dr
6ebbf2ce Russell King 2014-06-30 297 ret lr
07f33a03 Catalin Marinas 2009-07-24 298 .org 1b + 8
25ebee02 Catalin Marinas 2007-09-25 @299 .endr
25ebee02 Catalin Marinas 2007-09-25 300 #endif
^1da177e Linus Torvalds 2005-04-16 301
25ebee02 Catalin Marinas 2007-09-25 302 @ virtual register 16 (or 32 if VFPv3) for compare with zero
^1da177e Linus Torvalds 2005-04-16 303 mov r0, #0
^1da177e Linus Torvalds 2005-04-16 304 mov r1, #0
6ebbf2ce Russell King 2014-06-30 305 ret lr
93ed3970 Catalin Marinas 2008-08-28 306 ENDPROC(vfp_get_double)
^1da177e Linus Torvalds 2005-04-16 307
93ed3970 Catalin Marinas 2008-08-28 308 ENTRY(vfp_put_double)
07f33a03 Catalin Marinas 2009-07-24 309 tbl_branch r2, r3, #3
^1da177e Linus Torvalds 2005-04-16 310 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
07f33a03 Catalin Marinas 2009-07-24 311 1: fmdrr d\dr, r0, r1
6ebbf2ce Russell King 2014-06-30 312 ret lr
07f33a03 Catalin Marinas 2009-07-24 313 .org 1b + 8
^1da177e Linus Torvalds 2005-04-16 314 .endr
25ebee02 Catalin Marinas 2007-09-25 315 #ifdef CONFIG_VFPv3
25ebee02 Catalin Marinas 2007-09-25 316 @ d16 - d31 registers
25ebee02 Catalin Marinas 2007-09-25 317 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
138de1c4 Russell King 2010-05-27 318 1: mcrr p11, 3, r0, r1, c\dr @ fmdrr r0, r1, d\dr
6ebbf2ce Russell King 2014-06-30 319 ret lr
07f33a03 Catalin Marinas 2009-07-24 320 .org 1b + 8
25ebee02 Catalin Marinas 2007-09-25 @321 .endr
:::::: The code at line 299 was first introduced by commit
:::::: 25ebee020bd34d1f4c5678538204f0b10bf9f6d5 [ARM] 4583/1: ARMv7: Add VFPv3 support
:::::: TO: Catalin Marinas <catalin.marinas@arm.com>
:::::: CC: Russell King <rmk+kernel@arm.linux.org.uk>
---
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: 23776 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3][can-next] can: rcar_can: Fix erroneous registration
From: Simon Horman @ 2018-09-11 13:31 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
Sergei Shtylyov, Chris Paterson, linux-can, netdev,
Geert Uytterhoeven, Biju Das, linux-renesas-soc
In-Reply-To: <1536576195-11520-2-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Sep 10, 2018 at 11:43:13AM +0100, Fabrizio Castro wrote:
> Assigning 2 to "renesas,can-clock-select" tricks the driver into
> registering the CAN interface, even though we don't want that.
> This patch improves one of the checks to prevent that from happening.
>
> Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Simon Horman @ 2018-09-11 13:31 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
David S. Miller, Sergei Shtylyov, linux-can, linux-kernel, netdev,
devicetree, Geert Uytterhoeven, Chris Paterson, Biju Das,
linux-renesas-soc
In-Reply-To: <1536576195-11520-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Sep 10, 2018 at 11:43:14AM +0100, Fabrizio Castro wrote:
> Document RZ/G2M (r8a774a1) SoC specific bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> v1->v2:
> * dropped "renesas,rzg-gen2-can" and fixed "clocks" property description
> as per Geert's comments.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH net 0/2] nfp: flower: fixes for flower offload
From: Jakub Kicinski @ 2018-09-11 13:38 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
Hi!
Two fixes for flower matching and tunnel encap. Pieter fixes
VLAN matching if the entire VLAN id is masked out and match
is only performed on the PCP field. Louis adds validation of
tunnel flags for encap, most importantly we should not offload
actions on IPv6 tunnels if it's not supported.
Louis Peens (1):
nfp: flower: reject tunnel encap with ipv6 outer headers for
offloading
Pieter Jansen van Vuuren (1):
nfp: flower: fix vlan match by checking both vlan id and vlan pcp
drivers/net/ethernet/netronome/nfp/flower/action.c | 6 ++++++
drivers/net/ethernet/netronome/nfp/flower/main.h | 1 +
drivers/net/ethernet/netronome/nfp/flower/match.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/offload.c | 11 +++++++++++
4 files changed, 19 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
* [PATCH net 1/2] nfp: flower: fix vlan match by checking both vlan id and vlan pcp
From: Jakub Kicinski @ 2018-09-11 13:38 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Pieter Jansen van Vuuren
In-Reply-To: <20180911133845.14214-1-jakub.kicinski@netronome.com>
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Previously we only checked if the vlan id field is present when trying
to match a vlan tag. The vlan id and vlan pcp field should be treated
independently.
Fixes: 5571e8c9f241 ("nfp: extend flower matching capabilities")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/main.h | 1 +
drivers/net/ethernet/netronome/nfp/flower/match.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/offload.c | 11 +++++++++++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.h b/drivers/net/ethernet/netronome/nfp/flower/main.h
index 85f8209bf007..81d941ab895c 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.h
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.h
@@ -70,6 +70,7 @@ struct nfp_app;
#define NFP_FL_FEATS_GENEVE BIT(0)
#define NFP_FL_NBI_MTU_SETTING BIT(1)
#define NFP_FL_FEATS_GENEVE_OPT BIT(2)
+#define NFP_FL_FEATS_VLAN_PCP BIT(3)
#define NFP_FL_FEATS_LAG BIT(31)
struct nfp_fl_mask_id {
diff --git a/drivers/net/ethernet/netronome/nfp/flower/match.c b/drivers/net/ethernet/netronome/nfp/flower/match.c
index a0c72f277faa..17acb8cc6044 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/match.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/match.c
@@ -56,7 +56,7 @@ nfp_flower_compile_meta_tci(struct nfp_flower_meta_tci *frame,
FLOW_DISSECTOR_KEY_VLAN,
target);
/* Populate the tci field. */
- if (flow_vlan->vlan_id) {
+ if (flow_vlan->vlan_id || flow_vlan->vlan_priority) {
tmp_tci = FIELD_PREP(NFP_FLOWER_MASK_VLAN_PRIO,
flow_vlan->vlan_priority) |
FIELD_PREP(NFP_FLOWER_MASK_VLAN_VID,
diff --git a/drivers/net/ethernet/netronome/nfp/flower/offload.c b/drivers/net/ethernet/netronome/nfp/flower/offload.c
index 2edab01c3beb..bd19624f10cf 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/offload.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c
@@ -192,6 +192,17 @@ nfp_flower_calculate_key_layers(struct nfp_app *app,
key_size += sizeof(struct nfp_flower_mac_mpls);
}
+ if (dissector_uses_key(flow->dissector, FLOW_DISSECTOR_KEY_VLAN)) {
+ struct flow_dissector_key_vlan *flow_vlan;
+
+ flow_vlan = skb_flow_dissector_target(flow->dissector,
+ FLOW_DISSECTOR_KEY_VLAN,
+ flow->mask);
+ if (!(priv->flower_ext_feats & NFP_FL_FEATS_VLAN_PCP) &&
+ flow_vlan->vlan_priority)
+ return -EOPNOTSUPP;
+ }
+
if (dissector_uses_key(flow->dissector,
FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
struct flow_dissector_key_ipv4_addrs *mask_ipv4 = NULL;
--
2.17.1
^ permalink raw reply related
* [PATCH net 2/2] nfp: flower: reject tunnel encap with ipv6 outer headers for offloading
From: Jakub Kicinski @ 2018-09-11 13:38 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Louis Peens
In-Reply-To: <20180911133845.14214-1-jakub.kicinski@netronome.com>
From: Louis Peens <louis.peens@netronome.com>
This fixes a bug where ipv6 tunnels would report that it is
getting offloaded to hardware but would actually be rejected
by hardware.
Fixes: b27d6a95a70d ("nfp: compile flower vxlan tunnel set actions")
Signed-off-by: Louis Peens <louis.peens@netronome.com>
Reviewed-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/action.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/action.c b/drivers/net/ethernet/netronome/nfp/flower/action.c
index 9044496803e6..46ba0cf257c6 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/action.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
@@ -52,6 +52,7 @@
#define NFP_FL_TUNNEL_CSUM cpu_to_be16(0x01)
#define NFP_FL_TUNNEL_KEY cpu_to_be16(0x04)
#define NFP_FL_TUNNEL_GENEVE_OPT cpu_to_be16(0x0800)
+#define NFP_FL_SUPPORTED_TUNNEL_INFO_FLAGS IP_TUNNEL_INFO_TX
#define NFP_FL_SUPPORTED_IPV4_UDP_TUN_FLAGS (NFP_FL_TUNNEL_CSUM | \
NFP_FL_TUNNEL_KEY | \
NFP_FL_TUNNEL_GENEVE_OPT)
@@ -741,11 +742,16 @@ nfp_flower_loop_action(struct nfp_app *app, const struct tc_action *a,
nfp_fl_push_vlan(psh_v, a);
*a_len += sizeof(struct nfp_fl_push_vlan);
} else if (is_tcf_tunnel_set(a)) {
+ struct ip_tunnel_info *ip_tun = tcf_tunnel_info(a);
struct nfp_repr *repr = netdev_priv(netdev);
+
*tun_type = nfp_fl_get_tun_from_act_l4_port(repr->app, a);
if (*tun_type == NFP_FL_TUNNEL_NONE)
return -EOPNOTSUPP;
+ if (ip_tun->mode & ~NFP_FL_SUPPORTED_TUNNEL_INFO_FLAGS)
+ return -EOPNOTSUPP;
+
/* Pre-tunnel action is required for tunnel encap.
* This checks for next hop entries on NFP.
* If none, the packet falls back before applying other actions.
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] nfp: report FW vNIC stats in interface stats
From: Jakub Kicinski @ 2018-09-11 13:44 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
Report in standard netdev stats drops and errors as well as
RX multicast from the FW vNIC counters.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 17a4785e8f4c..1aac55d66404 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -3167,6 +3167,7 @@ static void nfp_net_stat64(struct net_device *netdev,
struct nfp_net *nn = netdev_priv(netdev);
int r;
+ /* Collect software stats */
for (r = 0; r < nn->max_r_vecs; r++) {
struct nfp_net_r_vector *r_vec = &nn->r_vecs[r];
u64 data[3];
@@ -3192,6 +3193,14 @@ static void nfp_net_stat64(struct net_device *netdev,
stats->tx_bytes += data[1];
stats->tx_errors += data[2];
}
+
+ /* Add in device stats */
+ stats->multicast += nn_readq(nn, NFP_NET_CFG_STATS_RX_MC_FRAMES);
+ stats->rx_dropped += nn_readq(nn, NFP_NET_CFG_STATS_RX_DISCARDS);
+ stats->rx_errors += nn_readq(nn, NFP_NET_CFG_STATS_RX_ERRORS);
+
+ stats->tx_dropped += nn_readq(nn, NFP_NET_CFG_STATS_TX_DISCARDS);
+ stats->tx_errors += nn_readq(nn, NFP_NET_CFG_STATS_TX_ERRORS);
}
static int nfp_net_set_features(struct net_device *netdev,
--
2.17.1
^ permalink raw reply related
* Re: Overlayfs @ Containers and checkpoint/restart micro-conference at LPC2018
From: Vivek Goyal @ 2018-09-11 13:52 UTC (permalink / raw)
To: Christian Brauner
Cc: Amir Goldstein, Stephane Graber, containers, Miklos Szeredi,
Netdev, overlayfs, lxc-users, LSM List, lxc-devel, linux-fsdevel,
zhangyi (F)
In-Reply-To: <20180909091549.yekfuds633afhrgw@mailbox.org>
On Sun, Sep 09, 2018 at 11:18:54AM +0200, Christian Brauner wrote:
[..]
> My team hast just started to be more involved with shifts development a
> few months back. Overlayfs is definitely an inspiration and we even once
> thought about making shifts an extension of overlayfs.
> Seth Forshee on my team is currently actively working on shifts and
> getting a POC ready.
> When he has a POC based on James' patchset there will be an RFC that
> will go to fsdevel and all parties of interest.
> There will also be an update on shifts development during the microconf.
> So even more reason for developers from overlayfs to stop by.
So we need both shiftfs and overlayfs in container deployments, right?
shiftfs to make sure each container can run in its own user namespace
and uid/gid mappings can be setup on the fly and overlayfs to provide
union of multiple layers and copy on write filesystem. I am assuming that
shiftfs is working on top of overlayfs here?
Doing shifting at VFS level using mount API was another idea discussed
at last plumbers. I saw David Howells was pushing all the new mount
API patches. Not sure if he ever got time to pursue shifting at VFS
level.
BTW, now we have metadata only copy up patches in overlayfs as
well(4.19-rc). That speeds up chown operation with overlayfs,
needed for changing ownership of files in images for making sure
they work fine with user namespaces. In my simple testing in a VM,
a fedora image was taking around 30 seconds to chown. With metadata
only copy up that time drops to around 2-3 seconds. So till shiftfs
or shiting at VFS level gets merged, it can be used as a stop gap
solution.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH] wil6210: remove set but not used variable 'start'
From: merez-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-09-11 19:04 UTC (permalink / raw)
To: YueHaibing
Cc: Kalle Valo, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wil6210-Rm6X0d1/PG5y9aJCnZT0Uw, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1536669139-14848-1-git-send-email-yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On 2018-09-11 15:32, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/wil6210/pm.c: In function
> 'wil_suspend_keep_radio_on':
> drivers/net/wireless/ath/wil6210/pm.c:193:16: warning:
> variable 'start' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Maya Erez <merez-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv3 iproute2] bridge/mdb: fix missing new line when show bridge mdb
From: Hangbin Liu @ 2018-09-11 14:04 UTC (permalink / raw)
To: netdev; +Cc: Phil Sutter, Stephen Hemminger, David Ahern, Hangbin Liu
In-Reply-To: <1536118423-20604-1-git-send-email-liuhangbin@gmail.com>
The bridge mdb show is broken on current iproute2. e.g.
]# bridge mdb show
34: br0 veth0_br 224.1.1.2 temp 34: br0 veth0_br 224.1.1.1 temp
After fix:
]# bridge mdb show
34: br0 veth0_br 224.1.1.2 temp
34: br0 veth0_br 224.1.1.1 temp
v2: Use json print lib as Stephen suggested.
v3: No need to use is_json_context() as Phil pointed out.
Reported-by: Ying Xu <yinxu@redhat.com>
Fixes: c7c1a1ef51aea ("bridge: colorize output and use JSON print library")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
bridge/mdb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/bridge/mdb.c b/bridge/mdb.c
index f38dc67..2f24b01 100644
--- a/bridge/mdb.c
+++ b/bridge/mdb.c
@@ -107,6 +107,10 @@ static void br_print_router_ports(FILE *f, struct rtattr *attr,
fprintf(f, "%s ", port_ifname);
}
}
+
+ if (!show_stats)
+ print_string(PRINT_FP, NULL, "\n", NULL);
+
close_json_array(PRINT_JSON, NULL);
}
@@ -164,6 +168,8 @@ static void print_mdb_entry(FILE *f, int ifindex, const struct br_mdb_entry *e,
print_string(PRINT_ANY, "timer", " %s",
format_timer(timer));
}
+
+ print_string(PRINT_FP, NULL, "\n", NULL);
close_json_object();
}
--
2.5.5
^ permalink raw reply related
* Inquiry 11-09-2018
From: Invictus Group @ 2018-09-11 12:28 UTC (permalink / raw)
To: netdev
Hello,
This is Ms Julian Smith and i am from Invictus Group Co.,LTD in United Kingdom.
We are glad to know about your company from the web and we are interested in your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Julian Smith
Purchasing Manager
^ permalink raw reply
* Re: [RFC PATCH bpf-next v2 0/4] Implement bpf queue/stack maps
From: Mauricio Vasquez @ 2018-09-11 14:48 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Daniel Borkmann, Network Development,
Joe Stringer
In-Reply-To: <CAADnVQLLUf5wTj+8jtMr=y4KdgdkTJ+9EmcPp7zhJfmNTB0RdA@mail.gmail.com>
On 09/10/2018 08:04 PM, Alexei Starovoitov wrote:
> On Fri, Sep 7, 2018 at 1:40 PM, Mauricio Vasquez
> <mauricio.vasquez@polito.it> wrote:
>> I read the Joe's proposal and using that for this problem looks like a nice
>> solution.
>>
>> I think a good trade-off for now would be to go ahead with a queue/stack map
>> without preallocating support (or maybe include it having always in mind
>> that this issue has to be solved in the near future) and then, as a
>> separated work, try to use Joe's proposal in the map helpers.
>>
>> What do you think?
> the problem with such approach is that it would mean that
> non-prealloc stack/queue api will be different from future one
> after verifier will get smarter.
> The alternative would be to support by-value api only.
> Meaning let stack/queue support value_size = 1,2,4,8 byte only.
> Then bpf_push|pop_elem() helper will be by-value
> instead of returning a pointer.
> No rcu callback issues and implementation on the kernel
> side can be much simpler.
> I think simple array of value_size elems with head/tail indices
> will be enough.
> Once we have Joe's verifier improvements
> we can add alloc/free bpf object management facility
> and use 8-byte stack/queue mapas a stack of pointers.
> I think decoupling memory operations alloc/free from
> stack push/pop would be additional benefit of such design.
>
I agree, this suffices our requirements and avoid RCU issues.
Will spin a V3 implementing it this week.
^ permalink raw reply
* Re: [PATCH v3 00/15] soc: octeontx2: Add RVU admin function driver
From: Arnd Bergmann @ 2018-09-11 20:05 UTC (permalink / raw)
To: Sunil Kovvuri
Cc: Linux Kernel Mailing List, Olof Johansson, Linux ARM, linux-soc,
Andrew Lunn, David Miller, Networking, sgoutham
In-Reply-To: <CA+sq2CeOSY9VLEY6ruGceo+NkwtfDuivy9joMkx9P3JTPyZxZQ@mail.gmail.com>
On Tue, Sep 11, 2018 at 6:28 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
>
> On Tue, Sep 11, 2018 at 7:07 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, Sep 11, 2018 at 2:37 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> > >
> > > Didn't receive any feedback for the v3 patch series over a week's time.
> > > Can you please pick up these patches to merge into arm-soc ?
> >
> > I would still prefer to see the whole thing as part of drivers/net/
> > instead of drivers/soc,
> > and reviewed in full on the netdev side, including the parts that are
> > not ethernet specific.
> >
> > Arnd
>
> Hmm.. I agree that there are many networking terms used in the driver
> but it's not a
> networking driver, it's just a HW configuration driver which includes
> how HW should
> parse the packet. This driver doesn't fit into drivers/net.
Who says it doesn't fit?
> Let's say if netdev driver in drivers/net/ethernet doesn't make use of
> crypto feature
> then i guess netdev maintainers would reject any patches which configure crypto
> block. Also as i have been saying there are other scenarios as well.
> Future silicons may add support for other features into this resource
> virtualization unit's domain.
> An example would be compression. Any patches which do compression
> related HW configuration
> might be rejected by netdev maintainers, cause they are no way related
> to networking.
>
> I will keep netdev mailing list in all the patch submissions but
> moving this driver into drivers/net
> doesn't sound right, from it's functionality perspective.
Have you discussed this with the network maintainers? I agree that
it's not a perfect fit, but IMHO it would be better to keep everything
in one place than to split the code location into separate ddirectories
for management, networking and crypto. If we find one place for it,
then I think drivers/net/ethernet is the best since the purpose of that
(combined) hardware is ultimately to interface with ethernet.
If the network folks say they don't want it there, we can take the
management bits into drivers/soc as you suggest.
Arnd
^ permalink raw reply
* Re: Overlayfs @ Containers and checkpoint/restart micro-conference at LPC2018
From: James Bottomley @ 2018-09-11 15:13 UTC (permalink / raw)
To: Vivek Goyal, Christian Brauner
Cc: containers, Miklos Szeredi, zhangyi (F), Netdev, overlayfs,
lxc-users, LSM List, lxc-devel, linux-fsdevel
In-Reply-To: <20180911135259.GB27845@redhat.com>
On Tue, 2018-09-11 at 09:52 -0400, Vivek Goyal wrote:
> On Sun, Sep 09, 2018 at 11:18:54AM +0200, Christian Brauner wrote:
> [..]
> > My team hast just started to be more involved with shifts
> > development a few months back. Overlayfs is definitely an
> > inspiration and we even once thought about making shifts an
> > extension of overlayfs. Seth Forshee on my team is currently
> > actively working on shifts and getting a POC ready.
> > When he has a POC based on James' patchset there will be an RFC
> > that will go to fsdevel and all parties of interest.
> > There will also be an update on shifts development during the
> > microconf. So even more reason for developers from overlayfs to
> > stop by.
>
> So we need both shiftfs and overlayfs in container deployments,
> right?
Well, no; only docker style containers need some form of overlay graph
driver, but even there it doesn't have to be the overlayfs one. When I
build unprivileged containers, I never use overlays so for me having to
use it will be problematic as it would be even in docker for the non-
overlayfs graph drivers.
Perhaps we should consider this when we look at the use cases.
> shiftfs to make sure each container can run in its own user namespace
> and uid/gid mappings can be setup on the fly and overlayfs to provide
> union of multiple layers and copy on write filesystem. I am assuming
> that shiftfs is working on top of overlayfs here?
>
> Doing shifting at VFS level using mount API was another idea
> discussed at last plumbers. I saw David Howells was pushing all the
> new mount API patches. Not sure if he ever got time to pursue
> shifting at VFS level.
I wasn't party to the conversation, but when I discussed it with Ted
(who wants something similar for a feature changing bind mount) we need
the entire VFS api to be struct path based instead of dentry/inode
based. That's the way it's going, but we'd need to get to the end
point so we have a struct vfsmnt available for every VFS call.
> BTW, now we have metadata only copy up patches in overlayfs as
> well(4.19-rc). That speeds up chown operation with overlayfs,
> needed for changing ownership of files in images for making sure
> they work fine with user namespaces. In my simple testing in a VM,
> a fedora image was taking around 30 seconds to chown. With metadata
> only copy up that time drops to around 2-3 seconds. So till shiftfs
> or shiting at VFS level gets merged, it can be used as a stop gap
> solution.
Most of the snapshot based filesystem (btrfs, xfs) do this without any
need for overlayfs.
James
^ permalink raw reply
* Re: [PATCH] cxgb4: fix abort_req_rss6 struct
From: Jason Gunthorpe @ 2018-09-11 15:19 UTC (permalink / raw)
To: Steve Wise; +Cc: netdev, dledford, davem, linux-rdma
In-Reply-To: <1e9f55943699dcc2bc921000ee7ee5353cbf7480.1535742195.git.swise@opengridcomputing.com>
On Fri, Aug 31, 2018 at 11:52:00AM -0700, Steve Wise wrote:
> Remove the incorrect WR_HDR field which can cause a misinterpretation
> of this CPL by ULDs.
>
> Fixes: a3cdaa69e4ae ("cxgb4: Adds CPL support for Shared Receive Queues")
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> ---
>
> Dave, Doug, and Jason,
>
> I request this merge through the rdma repo since the only user of this
> structure is iw_cxgb4.
Applied to for-rc, thanks
Jason
^ permalink raw reply
* Re: [PATCHv2 iproute2] bridge/mdb: fix missing new line when show bridge mdb
From: Stephen Hemminger @ 2018-09-11 15:30 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, David Ahern, Phil Sutter
In-Reply-To: <1536629195-12540-1-git-send-email-liuhangbin@gmail.com>
On Tue, 11 Sep 2018 09:26:35 +0800
Hangbin Liu <liuhangbin@gmail.com> wrote:
> + if (!is_json_context() && !show_stats)
> + print_string(PRINT_FP, NULL, "\n", NULL);
I just added print_nl to json_print which does what you want.
^ permalink raw reply
* Re: [PATCHv3 iproute2] bridge/mdb: fix missing new line when show bridge mdb
From: Stephen Hemminger @ 2018-09-11 15:31 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, Phil Sutter, David Ahern
In-Reply-To: <1536674690-15756-1-git-send-email-liuhangbin@gmail.com>
On Tue, 11 Sep 2018 22:04:50 +0800
Hangbin Liu <liuhangbin@gmail.com> wrote:
> The bridge mdb show is broken on current iproute2. e.g.
> ]# bridge mdb show
> 34: br0 veth0_br 224.1.1.2 temp 34: br0 veth0_br 224.1.1.1 temp
>
> After fix:
> ]# bridge mdb show
> 34: br0 veth0_br 224.1.1.2 temp
> 34: br0 veth0_br 224.1.1.1 temp
>
> v2: Use json print lib as Stephen suggested.
> v3: No need to use is_json_context() as Phil pointed out.
>
> Reported-by: Ying Xu <yinxu@redhat.com>
> Fixes: c7c1a1ef51aea ("bridge: colorize output and use JSON print library")
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> bridge/mdb.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/bridge/mdb.c b/bridge/mdb.c
> index f38dc67..2f24b01 100644
> --- a/bridge/mdb.c
> +++ b/bridge/mdb.c
> @@ -107,6 +107,10 @@ static void br_print_router_ports(FILE *f, struct rtattr *attr,
> fprintf(f, "%s ", port_ifname);
> }
> }
> +
> + if (!show_stats)
> + print_string(PRINT_FP, NULL, "\n", NULL);
> +
> close_json_array(PRINT_JSON, NULL);
> }
>
> @@ -164,6 +168,8 @@ static void print_mdb_entry(FILE *f, int ifindex, const struct br_mdb_entry *e,
> print_string(PRINT_ANY, "timer", " %s",
> format_timer(timer));
> }
> +
> + print_string(PRINT_FP, NULL, "\n", NULL);
This can now just be:
print_nl();
The problem with print_string(PRINT_FP, NULL, "\n", NULL) is that it doesn't handle oneline
mode correctly.
^ permalink raw reply
* Re: Overlayfs @ Containers and checkpoint/restart micro-conference at LPC2018
From: Vivek Goyal @ 2018-09-11 15:36 UTC (permalink / raw)
To: James Bottomley
Cc: Christian Brauner, containers, Miklos Szeredi, zhangyi (F),
Netdev, overlayfs, lxc-users, LSM List, lxc-devel, linux-fsdevel
In-Reply-To: <1536678820.3174.11.camel@HansenPartnership.com>
On Tue, Sep 11, 2018 at 08:13:40AM -0700, James Bottomley wrote:
> On Tue, 2018-09-11 at 09:52 -0400, Vivek Goyal wrote:
> > On Sun, Sep 09, 2018 at 11:18:54AM +0200, Christian Brauner wrote:
> > [..]
> > > My team hast just started to be more involved with shifts
> > > development a few months back. Overlayfs is definitely an
> > > inspiration and we even once thought about making shifts an
> > > extension of overlayfs. Seth Forshee on my team is currently
> > > actively working on shifts and getting a POC ready.
> > > When he has a POC based on James' patchset there will be an RFC
> > > that will go to fsdevel and all parties of interest.
> > > There will also be an update on shifts development during the
> > > microconf. So even more reason for developers from overlayfs to
> > > stop by.
> >
> > So we need both shiftfs and overlayfs in container deployments,
> > right?
>
> Well, no; only docker style containers need some form of overlay graph
> driver, but even there it doesn't have to be the overlayfs one. When I
> build unprivileged containers, I never use overlays so for me having to
> use it will be problematic as it would be even in docker for the non-
> overlayfs graph drivers.
Hi James,
Ok. For us, overlayfs is now default for docker containers as it was
much faster as compared to devicemapper and vfs (due to page cache
sharing). So please keep in mind overlayfs graph driver use case
as well while designing a solution.
For non docker containers, I am assuming all the image is in one directory
so no union is required. Also these probably are read-only containers
or this image directory is not shared with other containers for it to
work.
>
> Perhaps we should consider this when we look at the use cases.
>
> > shiftfs to make sure each container can run in its own user namespace
> > and uid/gid mappings can be setup on the fly and overlayfs to provide
> > union of multiple layers and copy on write filesystem. I am assuming
> > that shiftfs is working on top of overlayfs here?
> >
> > Doing shifting at VFS level using mount API was another idea
> > discussed at last plumbers. I saw David Howells was pushing all the
> > new mount API patches. Not sure if he ever got time to pursue
> > shifting at VFS level.
>
> I wasn't party to the conversation, but when I discussed it with Ted
> (who wants something similar for a feature changing bind mount) we need
> the entire VFS api to be struct path based instead of dentry/inode
> based. That's the way it's going, but we'd need to get to the end
> point so we have a struct vfsmnt available for every VFS call.
Ok, thanks. So mappings will be per mount and available in vfsmnt and
hence pass around path so that one can get to vfsmnt (instead of
dentry/inode). Makes sense.
>
> > BTW, now we have metadata only copy up patches in overlayfs as
> > well(4.19-rc). That speeds up chown operation with overlayfs,
> > needed for changing ownership of files in images for making sure
> > they work fine with user namespaces. In my simple testing in a VM,
> > a fedora image was taking around 30 seconds to chown. With metadata
> > only copy up that time drops to around 2-3 seconds. So till shiftfs
> > or shiting at VFS level gets merged, it can be used as a stop gap
> > solution.
>
> Most of the snapshot based filesystem (btrfs, xfs) do this without any
> need for overlayfs.
Right. But they don't share page cache yet (same with devicemapper). So
till we get page cache sharing in these file systems, overlayfs still
has the advantage of being able to launch many more containers using
same image with smaller memory requirements (and its faster too as image
does not have to be read from disk).
Thanks
Vivek
^ permalink raw reply
* Re: unexpected GRO/veth behavior
From: Eric Dumazet @ 2018-09-11 15:42 UTC (permalink / raw)
To: Paolo Abeni, Eric Dumazet, netdev; +Cc: Toshiaki Makita
In-Reply-To: <3ab5755e75cfe2bfaeeb133b53512da43cfdb8b0.camel@redhat.com>
On 09/11/2018 04:44 AM, Paolo Abeni wrote:
> On Tue, 2018-09-11 at 03:27 -0700, Eric Dumazet wrote:
>> On 09/10/2018 11:54 PM, Paolo Abeni wrote:
>>> I *think* we can hit a similar condition with a tun device in IFF_NAPI
>>> mode.
>>
>> Why ?
>>
>> tun_get_user() does not attach skb to a socket, that would be quite useless since skb
>>
>
> I think we can hit this code path:
>
> tun_get_user() -> tun_alloc_skb() -> sock_alloc_send_pskb() ->
> skb_set_owner_w()
>
> Than later napi and GRO.
>
No we can not.
Please look again.
^ permalink raw reply
* Editing 6
From: Aaron @ 2018-09-11 9:49 UTC (permalink / raw)
To: netdev
Hi,
If you have photos for editing, please send email to: hansrekan@outlook.com
We have 12 in house image editors and we can help you for cutting out your
photos, or path the photos.
Includes retouching if needed.
Used for products photos or portrait photos, catalog photos.
You may drop us one photo, we can send you the testing work.
Thanks,
Aaron Williams
Email: hansrekan@outlook.com
^ permalink raw reply
* Re: [PATCH net-next v3 17/17] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-11 20:53 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, David Miller, Greg Kroah-Hartman
In-Reply-To: <201809112045.A5D7cAAW%fengguang.wu@intel.com>
Hi friendly kbuild test robot,
On Tue, Sep 11, 2018 at 7:02 AM kbuild test robot <lkp@intel.com> wrote:
> I love your patch! Yet something to improve:
> make ARCH=um SUBARCH=i386
I've now fixed this problem and it will be in v4.
Regards,
Jason, a human
^ permalink raw reply
* Editing 2
From: Aaron @ 2018-09-11 6:42 UTC (permalink / raw)
To: netdev
Hi,
If you have photos for editing, please send email to: hansrekan@outlook.com
We have 12 in house image editors and we can help you for cutting out your
photos, or path the photos.
Includes retouching if needed.
Used for products photos or portrait photos, catalog photos.
You may drop us one photo, we can send you the testing work.
Thanks,
Aaron Williams
Email: hansrekan@outlook.com
^ permalink raw reply
* Re: [PATCH net-next v3 17/17] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-11 21:05 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, David Miller, Greg Kroah-Hartman
In-Reply-To: <201809112140.Y6V2OTor%fengguang.wu@intel.com>
Hello again Mr. Ro Bot,
On Tue, Sep 11, 2018 at 7:17 AM kbuild test robot <lkp@intel.com> wrote:
> I love your patch! Yet something to improve:
> All errors (new ones prefixed by >>):
> arch/arm/vfp/vfphw.S: Assembler messages:
> >> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c0' in ARM mode
> >> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c1' in ARM mode
> :::::: The code at line 299 was first introduced by commit
> :::::: 25ebee020bd34d1f4c5678538204f0b10bf9f6d5 [ARM] 4583/1: ARMv7: Add VFPv3 support
I've also fixed this for v4 of the submission. Sorry about that.
Jason
^ permalink raw reply
* Re: [PATCH net-next v3 17/17] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-11 21:08 UTC (permalink / raw)
To: Andrew Lunn; +Cc: LKML, Netdev, David Miller, Greg Kroah-Hartman
In-Reply-To: <20180911133017.GJ30395@lunn.ch>
Hello Andrew,
On Tue, Sep 11, 2018 at 7:30 AM Andrew Lunn <andrew@lunn.ch> wrote:
> I don't know if any of the crypto people are reviewing the networking
> code, but i don't think there are many networking people reviewing the
> crypto code.
>
> So please can you put the change log between versions for the
> networking code here, where we can easily see it.
All submissions >v1 have had a changelog in the 00/17 commit.
> I see you have yet again completely ignored my request to either
> 1) Remove the inline
> 2) Argue why it should be kept.
Most uses of inline are this way after checking the compiler output on
several platforms. (Generally my build-run-test cycle is actually
build-IDAPro-run-test.) If you feel that's been done too liberally,
I'm happy to spend time rechecking each use case.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox