* [PATCH net-next 02/12] net: mvpp2: rename the IRQs to match the hardware
From: Antoine Tenart @ 2018-09-19 9:27 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180919092711.22296-1-antoine.tenart@bootlin.com>
This patch renames the IRQs in the Marvell PPv2 driver as their current
names match the way they are used in software. But this will change in
the future, and those IRQs have nothing to do with Rx/Tx interrupts
(this can be configured). The new binding also describe more interrupts
as some where left out.
The old binding support is kept for backward compatibility.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 +
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 60 ++++++++++++++-----
2 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 2f8d8202d1d2..43f9d8372b28 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -613,6 +613,7 @@
/* Port flags */
#define MVPP2_F_LOOPBACK BIT(0)
+#define MVPP2_F_DT_COMPAT BIT(1)
/* Marvell tag types */
enum mvpp2_tag_type {
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 8bf81d11ff98..69ab80911756 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4001,7 +4001,10 @@ static int mvpp2_multi_queue_vectors_init(struct mvpp2_port *port,
v->sw_thread_id = i;
v->sw_thread_mask = BIT(i);
- snprintf(irqname, sizeof(irqname), "tx-cpu%d", i);
+ if (port->flags & MVPP2_F_DT_COMPAT)
+ snprintf(irqname, sizeof(irqname), "tx-cpu%d", i);
+ else
+ snprintf(irqname, sizeof(irqname), "hif%d", i);
if (queue_mode == MVPP2_QDIST_MULTI_MODE) {
v->first_rxq = i * MVPP2_DEFAULT_RXQ;
@@ -4011,7 +4014,9 @@ static int mvpp2_multi_queue_vectors_init(struct mvpp2_port *port,
v->first_rxq = 0;
v->nrxqs = port->nrxqs;
v->type = MVPP2_QUEUE_VECTOR_SHARED;
- strncpy(irqname, "rx-shared", sizeof(irqname));
+
+ if (port->flags & MVPP2_F_DT_COMPAT)
+ strncpy(irqname, "rx-shared", sizeof(irqname));
}
if (port_node)
@@ -4207,24 +4212,47 @@ static int mvpp2_port_init(struct mvpp2_port *port)
return err;
}
-/* Checks if the port DT description has the TX interrupts
- * described. On PPv2.1, there are no such interrupts. On PPv2.2,
- * there are available, but we need to keep support for old DTs.
+static bool mvpp22_port_has_legacy_tx_irqs(struct device_node *port_node,
+ unsigned long *flags)
+{
+ char *irqs[5] = { "rx-shared", "tx-cpu0", "tx-cpu1", "tx-cpu2",
+ "tx-cpu3" };
+ int i;
+
+ for (i = 0; i < 5; i++)
+ if (of_property_match_string(port_node, "interrupt-names",
+ irqs[i]) < 0)
+ return false;
+
+ *flags |= MVPP2_F_DT_COMPAT;
+ return true;
+}
+
+/* Checks if the port dt description has the required Tx interrupts:
+ * - PPv2.1: there are no such interrupts.
+ * - PPv2.2:
+ * - The old DTs have: "rx-shared", "tx-cpuX" with X in [0...3]
+ * - The new ones have: "hifX" with X in [0..8]
+ *
+ * All those variants are supported to keep the backward compatibility.
*/
-static bool mvpp2_port_has_tx_irqs(struct mvpp2 *priv,
- struct device_node *port_node)
+static bool mvpp2_port_has_irqs(struct mvpp2 *priv,
+ struct device_node *port_node,
+ unsigned long *flags)
{
- char *irqs[5] = { "rx-shared", "tx-cpu0", "tx-cpu1",
- "tx-cpu2", "tx-cpu3" };
- int ret, i;
+ char name[5];
+ int i;
if (priv->hw_version == MVPP21)
return false;
- for (i = 0; i < 5; i++) {
- ret = of_property_match_string(port_node, "interrupt-names",
- irqs[i]);
- if (ret < 0)
+ if (mvpp22_port_has_legacy_tx_irqs(port_node, flags))
+ return true;
+
+ for (i = 0; i < MVPP2_MAX_THREADS; i++) {
+ snprintf(name, 5, "hif%d", i);
+ if (of_property_match_string(port_node, "interrupt-names",
+ name) < 0)
return false;
}
@@ -4602,6 +4630,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
struct phylink *phylink;
char *mac_from = "";
unsigned int ntxqs, nrxqs;
+ unsigned long flags = 0;
bool has_tx_irqs;
u32 id;
int features;
@@ -4609,7 +4638,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
int err, i, cpu;
if (port_node) {
- has_tx_irqs = mvpp2_port_has_tx_irqs(priv, port_node);
+ has_tx_irqs = mvpp2_port_has_irqs(priv, port_node, &flags);
} else {
has_tx_irqs = true;
queue_mode = MVPP2_QDIST_MULTI_MODE;
@@ -4665,6 +4694,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
port->nrxqs = nrxqs;
port->priv = priv;
port->has_tx_irqs = has_tx_irqs;
+ port->flags = flags;
err = mvpp2_queue_vectors_init(port, port_node);
if (err)
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 01/12] net: mvpp2: increase the number of s/w threads to 9
From: Antoine Tenart @ 2018-09-19 9:27 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180919092711.22296-1-antoine.tenart@bootlin.com>
This patch sets the number of s/w threads to 9, its maximum value,
instead of 8. This is not a fix as only 4 of the s/w threads were used
so far, but more could be used in the future.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 67b9e81b7c02..2f8d8202d1d2 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -662,7 +662,7 @@ enum mvpp2_prs_l3_cast {
#define MVPP21_ADDR_SPACE_SZ 0
#define MVPP22_ADDR_SPACE_SZ SZ_64K
-#define MVPP2_MAX_THREADS 8
+#define MVPP2_MAX_THREADS 9
#define MVPP2_MAX_QVECS MVPP2_MAX_THREADS
/* GMAC MIB Counters register definitions */
--
2.17.1
^ permalink raw reply related
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Marcelo Ricardo Leitner @ 2018-09-19 3:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Johannes Berg
In-Reply-To: <20180918131212.20266-4-johannes@sipsolutions.net>
On Tue, Sep 18, 2018 at 03:12:11PM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> In one of my previous patches in this area I introduced code
> to pass out just the error message to store in the extack, for
> use in NLA_REJECT.
>
> Change this code now to set both the error message and the bad
> attribute pointer, and carry around a boolean indicating that
> the values have been set.
>
> This will be used in the next patch to allow recursive validation
> of nested policies, while preserving the innermost error message
> rather than overwriting it with a generic out-level message.
Did you consider indicating the message level, and only overwrite the
message that is already in there if the new message level is higher
than the current one?
This way the first to set an Error message will have it, and Warning
messages would be overwritten by such if needed. But it also would
cause the first warning to be held, and not the last one, as it does
today. We want the first error, but the last warning otherwise.
It would not be possible to overwrite if new_msglvl >= cur_msglvl
because then it would trigger the initial issue again, so some extra
logic would be needed to solve this.
Marcelo
^ permalink raw reply
* Re: [PATCH net 0/2] ipv6: fix issues on accessing fib6_metrics
From: David Miller @ 2018-09-19 3:17 UTC (permalink / raw)
To: weiwan; +Cc: netdev, edumazet, dsahern, xiyou.wangcong, sd
In-Reply-To: <20180918204500.106240-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Tue, 18 Sep 2018 13:44:58 -0700
> From: Wei Wang <weiwan@google.com>
>
> The latest fix on the memory leak of fib6_metrics still causes
> use-after-free.
> This patch series first revert the previous fix and propose a new fix
> that is more inline with ipv4 logic and is tested to fix the
> use-after-free issue reported.
Series applied.
^ permalink raw reply
* Re: [PATCH net] sfp: fix oops with ethtool -m
From: David Miller @ 2018-09-19 3:15 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1g2IFB-0000LN-AU@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 18 Sep 2018 16:48:53 +0100
> If a network interface is created prior to the SFP socket being
> available, ethtool can request module information. This unfortunately
> leads to an oops:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000008
> pgd = (ptrval)
> [00000008] *pgd=7c400831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 17 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1480 Comm: ethtool Not tainted 4.19.0-rc3 #138
> Hardware name: Broadcom Northstar Plus SoC
> PC is at sfp_get_module_info+0x8/0x10
> LR is at dev_ethtool+0x218c/0x2afc
>
> Fix this by not filling in the network device's SFP bus pointer until
> SFP is fully bound, thereby avoiding the core calling into the SFP bus
> code.
>
> Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages")
> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v3 net-next] ravb: do not write 1 to reserved bits
From: David Miller @ 2018-09-19 3:10 UTC (permalink / raw)
To: horms+renesas; +Cc: sergei.shtylyov, magnus.damm, netdev, linux-renesas-soc
In-Reply-To: <20180918102226.8017-1-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 18 Sep 2018 12:22:26 +0200
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> EtherAVB hardware requires 0 to be written to status register bits in
> order to clear them, however, care must be taken not to:
>
> 1. Clear other bits, by writing zero to them
> 2. Write one to reserved bits
>
> This patch corrects the ravb driver with respect to the second point above.
> This is done by defining reserved bit masks for the affected registers and,
> after auditing the code, ensure all sites that may write a one to a
> reserved bit use are suitably masked.
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
I've decided to apply this to 'net', let me know if this is a problem.
^ permalink raw reply
* [PATCH iproute2-next] iplink: add ipvtap support
From: Hangbin Liu @ 2018-09-19 3:03 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, David Ahern, Phil Sutter, Sainath Grandhi,
Davide Caratti, Hangbin Liu
IPVLAN and IPVTAP are using the same functions and parameters. So we can
just add a new link_util with id ipvtap. Others are the same.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
ip/iplink.c | 4 ++--
ip/iplink_ipvlan.c | 28 ++++++++++++++++++----------
man/man8/ip-link.8.in | 4 ++++
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/ip/iplink.c b/ip/iplink.c
index 0ba5f1a..d99c49e 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -120,8 +120,8 @@ void iplink_usage(void)
"TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |\n"
" bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |\n"
" gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan |\n"
- " vti | nlmon | team_slave | bond_slave | ipvlan | geneve |\n"
- " bridge_slave | vrf | macsec | netdevsim | rmnet }\n");
+ " vti | nlmon | team_slave | bond_slave | bridge_slave |\n"
+ " ipvlan | ipvtap | geneve | vrf | macsec | netdevsim | rmnet }\n");
}
exit(-1);
}
diff --git a/ip/iplink_ipvlan.c b/ip/iplink_ipvlan.c
index 8889808..baae767 100644
--- a/ip/iplink_ipvlan.c
+++ b/ip/iplink_ipvlan.c
@@ -1,4 +1,4 @@
-/* iplink_ipvlan.c IPVLAN device support
+/* iplink_ipvlan.c IPVLAN/IPVTAP device support
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -18,15 +18,15 @@
#include "utils.h"
#include "ip_common.h"
-static void ipvlan_explain(FILE *f)
+static void print_explain(struct link_util *lu, FILE *f)
{
fprintf(f,
- "Usage: ... ipvlan [ mode MODE ] [ FLAGS ]\n"
+ "Usage: ... %s [ mode MODE ] [ FLAGS ]\n"
"\n"
"MODE: l3 | l3s | l2\n"
"FLAGS: bridge | private | vepa\n"
- "(first values are the defaults if nothing is specified).\n"
- );
+ "(first values are the defaults if nothing is specified).\n",
+ lu->id);
}
static int ipvlan_parse_opt(struct link_util *lu, int argc, char **argv,
@@ -61,12 +61,12 @@ static int ipvlan_parse_opt(struct link_util *lu, int argc, char **argv,
} else if (matches(*argv, "bridge") == 0 && !mflag_given) {
mflag_given = true;
} else if (matches(*argv, "help") == 0) {
- ipvlan_explain(stderr);
+ print_explain(lu, stderr);
return -1;
} else {
- fprintf(stderr, "ipvlan: unknown option \"%s\"?\n",
- *argv);
- ipvlan_explain(stderr);
+ fprintf(stderr, "%s: unknown option \"%s\"?\n",
+ lu->id, *argv);
+ print_explain(lu, stderr);
return -1;
}
argc--;
@@ -113,7 +113,7 @@ static void ipvlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
static void ipvlan_print_help(struct link_util *lu, int argc, char **argv,
FILE *f)
{
- ipvlan_explain(f);
+ print_explain(lu, f);
}
struct link_util ipvlan_link_util = {
@@ -123,3 +123,11 @@ struct link_util ipvlan_link_util = {
.print_opt = ipvlan_print_opt,
.print_help = ipvlan_print_help,
};
+
+struct link_util ipvtap_link_util = {
+ .id = "ipvtap",
+ .maxattr = IFLA_IPVLAN_MAX,
+ .parse_opt = ipvlan_parse_opt,
+ .print_opt = ipvlan_print_opt,
+ .print_help = ipvlan_print_help,
+};
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 38e4ee6..9f345f9 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -215,6 +215,7 @@ ip-link \- network device configuration
.BR vti " |"
.BR nlmon " |"
.BR ipvlan " |"
+.BR ipvtap " |"
.BR lowpan " |"
.BR geneve " |"
.BR vrf " |"
@@ -329,6 +330,9 @@ Link types:
.BR ipvlan
- Interface for L3 (IPv6/IPv4) based VLANs
.sp
+.BR ipvtap
+- Interface for L3 (IPv6/IPv4) based VLANs and TAP
+.sp
.BR lowpan
- Interface for 6LoWPAN (IPv6) over IEEE 802.15.4 / Bluetooth
.sp
--
2.5.5
^ permalink raw reply related
* Re: [pull request][RESEND net 0/3] Mellanox, mlx5 fixes 2018-09-17
From: David Miller @ 2018-09-19 3:00 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180918034928.28651-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 17 Sep 2018 20:49:25 -0700
> Sorry about the previous submission of this series which was mistakenly
> marked for net-next, here I am resending with 'net' mark.
>
> This series provides three fixes to mlx5 core and mlx5e netdevice
> driver.
>
> Please pull and let me know if there's any problem.
Puled.
> For -stable v4.16:
> ('net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ')
Queued up.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: slicoss: remove duplicated include from slic.h
From: David Miller @ 2018-09-19 2:58 UTC (permalink / raw)
To: yuehaibing; +Cc: LinoSanfilippo, linux-kernel, netdev
In-Reply-To: <20180918030914.23592-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 18 Sep 2018 11:09:14 +0800
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: emac: fix fixed-link setup for the RTL8363SB switch
From: David Miller @ 2018-09-19 2:56 UTC (permalink / raw)
To: chunkeey; +Cc: netdev, ivan
In-Reply-To: <20180917152240.18177-1-chunkeey@gmail.com>
From: Christian Lamparter <chunkeey@gmail.com>
Date: Mon, 17 Sep 2018 17:22:40 +0200
> On the Netgear WNDAP620, the emac ethernet isn't receiving nor
> xmitting any frames from/to the RTL8363SB (identifies itself
> as a RTL8367RB).
>
> This is caused by the emac hardware not knowing the forced link
> parameters for speed, duplex, pause, etc.
>
> This begs the question, how this was working on the original
> driver code, when it was necessary to set the phy_address and
> phy_map to 0xffffffff. But I guess without access to the old
> PPC405/440/460 hardware, it's not possible to know.
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] selftests: pmtu: properly redirect stderr to /dev/null
From: David Miller @ 2018-09-19 2:54 UTC (permalink / raw)
To: sd; +Cc: netdev, sbrivio
In-Reply-To: <132b14cab49cd959d9cf6e6607b01c383db2d984.1537190905.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Mon, 17 Sep 2018 15:30:06 +0200
> The cleanup function uses "$CMD 2 > /dev/null", which doesn't actually
> send stderr to /dev/null, so when the netns doesn't exist, the error
> message is shown. Use "2> /dev/null" instead, so that those messages
> disappear, as was intended.
>
> Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied.
^ permalink raw reply
* Re: bpfilter breaks IPT_SO_GET_INFO
From: Dmitry Vyukov @ 2018-09-19 8:29 UTC (permalink / raw)
To: Michal Kubecek
Cc: Alexei Starovoitov, David Miller, Daniel Borkmann, netdev, LKML,
syzkaller, NetFilter, Fabian Vogt, Takashi Iwai
In-Reply-To: <20180919071847.GE3876@unicorn.suse.cz>
On Wed, Sep 19, 2018 at 9:18 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
> On Mon, Sep 17, 2018 at 03:36:21PM +0200, Dmitry Vyukov wrote:
>> Hi,
>>
>> I am having some problem with upstream kernel and bpfilter. The
>> manifestation is that IPT_SO_GET_INFO on an ipv4 socket works, then
>> something (that I can't fully localize but can reproduce) happens and
>> then IPT_SO_GET_INFO starts permanently returning 256.
> ...
>> Now the litmus program always fails with:
>>
>> getsockopt(3, SOL_IP, 0x40 /* IP_??? */,
>> "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., [84])
>> = 256
>>
>> I am currently on upstream commit
>> 28619527b8a712590c93d0a9e24b4425b9376a8c, my .config is attached. I
>> don't know what is bpfilter, I see it mentions some umh, if it
>> requires some additional setup I don't it, i.e. I don't install any
>> userspace modules/helpers.
>
> This looks similar to the fallback issue described here:
>
> https://bugzilla.suse.com/show_bug.cgi?id=1106751#c1
>
> Unfortunately I didn't have time to look into it more closely yet.
+Takashi
But I already have CONFIG_BPFILTER_UMH=y in my config, so it does not
help completely.
Also in my case it is working initially, but breaks after I run the
second program.
^ permalink raw reply
* Re: [RFC PATCH bpf-next v3 1/7] bpf: rename stack trace map
From: Mauricio Vasquez @ 2018-09-19 2:53 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, Yonghong Song
In-Reply-To: <20180918230551.7rh3wytacry7i3wl@ast-mbp>
On 09/18/2018 06:05 PM, Alexei Starovoitov wrote:
> On Tue, Sep 18, 2018 at 06:52:34AM +0200, Mauricio Vasquez B wrote:
>> In the following patches queue and stack maps (FIFO and LIFO
>> datastructures) will be implemented. In order to avoid confusion and
>> a possible name clash rename stackmap.c to stacktracemap.c and
>> stack_map_ops to stack_trace_map_ops
>>
>> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
>> ---
>> include/linux/bpf_types.h | 2
>> kernel/bpf/Makefile | 2
>> kernel/bpf/stackmap.c | 624 --------------------------------------------
>> kernel/bpf/stacktracemap.c | 624 ++++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 626 insertions(+), 626 deletions(-)
>> delete mode 100644 kernel/bpf/stackmap.c
>> create mode 100644 kernel/bpf/stacktracemap.c
> Just new file for stack/queue will be enough. I understand that unfortunate name confusion,
> but this is too late. It will cause all sorts of headaches in fixes that go to net/stable.
>
>
Ok, will only rename stack_map_ops to stack_trace_map_ops then.
^ permalink raw reply
* Re: [PATCH][net-next] veth: rename pcpu_vstats as pcpu_lstats
From: David Miller @ 2018-09-19 2:52 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1537181215-13213-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Mon, 17 Sep 2018 18:46:55 +0800
> struct pcpu_vstats and pcpu_lstats have same members and
> usage, and pcpu_lstats is used in many files, so rename
> pcpu_vstats as pcpu_lstats to reduce duplicate definition
>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] netlink: add ethernet address policy types
From: David Miller @ 2018-09-19 2:51 UTC (permalink / raw)
To: johannes; +Cc: netdev, marcelo.leitner, mkubecek, johannes.berg
In-Reply-To: <20180917095729.11185-2-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 17 Sep 2018 11:57:29 +0200
> From: Johannes Berg <johannes.berg@intel.com>
>
> Commonly, ethernet addresses are just using a policy of
> { .len = ETH_ALEN }
> which leaves userspace free to send more data than it should,
> which may hide bugs.
>
> Introduce NLA_EXACT_LEN which checks for exact size, rejecting
> the attribute if it's not exactly that length. Also add
> NLA_EXACT_LEN_WARN which requires the minimum length and will
> warn on longer attributes, for backward compatibility.
>
> Use these to define NLA_POLICY_ETH_ADDR (new strict policy) and
> NLA_POLICY_ETH_ADDR_COMPAT (compatible policy with warning);
> these are used like this:
>
> static const struct nla_policy <name>[...] = {
> [NL_ATTR_NAME] = NLA_POLICY_ETH_ADDR,
> ...
> };
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> v2: add only NLA_EXACT_LEN/NLA_EXACT_LEN_WARN and build on top
> of that for ethernet address validation, so it can be extended
> for other types (e.g. IPv6 addresses)
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] netlink: add NLA_REJECT policy type
From: David Miller @ 2018-09-19 2:51 UTC (permalink / raw)
To: johannes; +Cc: netdev, marcelo.leitner, mkubecek, johannes.berg
In-Reply-To: <20180917095729.11185-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 17 Sep 2018 11:57:28 +0200
> From: Johannes Berg <johannes.berg@intel.com>
>
> In some situations some netlink attributes may be used for output
> only (kernel->userspace) or may be reserved for future use. It's
> then helpful to be able to prevent userspace from using them in
> messages sent to the kernel, since they'd otherwise be ignored and
> any future will become impossible if this happens.
>
> Add NLA_REJECT to the policy which does nothing but reject (with
> EINVAL) validation of any messages containing this attribute.
> Allow for returning a specific extended ACK error message in the
> validation_data pointer.
>
> While at it clear up the documentation a bit - the NLA_BITFIELD32
> documentation was added to the list of len field descriptions.
>
> Also, use NL_SET_BAD_ATTR() in one place where it's open-coded.
>
> The specific case I have in mind now is a shared nested attribute
> containing request/response data, and it would be pointless and
> potentially confusing to have userspace include response data in
> the messages that actually contain a request.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> v2: preserve behaviour of overwriting the extack message, with
> either the generic or the specific one now
Applied.
^ permalink raw reply
* Re: [PATCH net 0/2] net: stmmac: Coalesce and tail addr fixes
From: David Miller @ 2018-09-19 2:48 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, f.fainelli, narmstrong, jbrunet, martin.blumenstingl,
Joao.Pinto, peppe.cavallaro, alexandre.torgue
In-Reply-To: <cover.1537171752.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Mon, 17 Sep 2018 09:22:55 +0100
> The fix for coalesce timer and a fix in tail address setting that impacts
> XGMAC2 operation.
>
> The series is:
> Tested-by: Jerome Brunet <jbrunet@baylibre.com>
> on a113 s400 board (single queue)
Series applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v2 03/10] net: sched: extend Qdisc with rcu
From: David Miller @ 2018-09-19 2:45 UTC (permalink / raw)
To: vladbu
Cc: netdev, jhs, xiyou.wangcong, jiri, stephen, ktkhai,
nicolas.dichtel, gregkh, mark.rutland, leon, paulmck, fw, dsahern,
christian, lucien.xin, jakub.kicinski, jbenc
In-Reply-To: <1537168660-24032-4-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 17 Sep 2018 10:17:33 +0300
> +struct Qdisc *qdisc_lookup_rcu(struct net_device *dev, u32 handle)
> +{
> + struct Qdisc *q;
> + struct netdev_queue *nq;
Reverse christmas tree for the local variables, please.
^ permalink raw reply
* Re: [net-next 00/14][pull request] 40GbE Intel Wired LAN Driver Updates 2018-09-18
From: David Miller @ 2018-09-19 2:42 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180918223731.31876-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 18 Sep 2018 15:37:17 -0700
> This series contains changes to i40evf so that it becomes a more
> generic virtual function driver for current and future silicon.
>
> While doing the rename of i40evf to a more generic name of iavf,
> we also put the driver on a severe diet due to how much of the
> code was unneeded or was unused. The outcome is a lean and mean
> virtual function driver that continues to work on existing 40GbE
> (i40e) virtual devices and prepped for future supported devices,
> like the 100GbE (ice) virtual devices.
>
> This solves 2 issues we saw coming or were already present, the
> first was constant code duplication happening with i40e/i40evf,
> when much of the duplicate code in the i40evf was not used or was
> not needed. The second was to remove the future confusion of why
> future VF devices that were not considered "40GbE" only devices
> were supported by i40evf.
>
> The thought is that iavf will be the virtual function driver for
> all future devices, so it should have a "generic" name to properly
> represent that it is the VF driver for multiple generations of
> devices.
>
> The last patch in this series is unreleated to the iavf conversion
> and just has to do with a MODULE_LICENSE correction.
>
> Known Caveats:
> Existing user space configurations may have to change, but the module
> alias in patch 1 helps a bit here.
Ok, let's see how this goes.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] net: apm: xgene: force XGene enet driver to re-balance IRQ usage
From: Eric Dumazet @ 2018-09-19 2:32 UTC (permalink / raw)
To: Florian Fainelli, ahs3, Lendacky, Thomas, David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
isubramanian@apm.com, kchudgar@apm.com, qnguyen@apm.com
In-Reply-To: <0e0f3aa6-9b6e-edd5-226f-2e23de9b5a0f@gmail.com>
On 09/18/2018 05:03 PM, Florian Fainelli wrote:
> On 09/18/2018 04:56 PM, Eric Dumazet wrote:
>>
>>
>> On 09/18/2018 04:27 PM, Eric Dumazet wrote:
>>>
>>
>>> I remember one of the napi_complete_done() change had to be reverted,
>>> for some obscure reason.
>>
>>
>>
>> That was not exactly a revert, :
>
> This is what I have so far for the drivers that both use
> napi_complete_done() without checking the return value and implement a
> ndo_poll_controller() callback:
>
> https://github.com/ffainelli/linux/commits/napi-check
In fact, there is still to explain what the bug is.
napi_complete_done() return value can be ignored, unless drivers
have to disable IRQ in their interrupt handler, using the following
construct :
if (napi_schedule_prep(napi)) {
.... disable interrupt ....
__napi_schedule_irqoff(napi);
}
It _can_ be used by other drivers to not rearm interrupts needlessly.
The bug discussed in this thread (re-balance IRQ usage) is of the same kind than
the one fixed in commit d7aba644ffdebf756e51e26a2229055211838e89 ("amd-xgbe: Enable IRQs only if napi_complete_done() is true")
^ permalink raw reply
* 答复: [PATCH][net-next] netlink: avoid to allocate full skb when sending to many devices
From: Li,Rongqing @ 2018-09-19 1:19 UTC (permalink / raw)
To: Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <3f01dd84-32c5-f674-75ac-a93a90f32bf7@gmail.com>
> On 09/17/2018 10:26 PM, Li RongQing wrote:
> > if skb->head is vmalloc address, when this skb is delivered, full
> > allocation for this skb is required, if there are many devices, the
> > ---
> > net/netlink/af_netlink.c | 14 ++++++++------
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> >
>
> This looks very broken to me.
>
> Only the original skb (given as an argument to __netlink_deliver_tap()) is
> guaranteed to not disappear while the loop is performed.
>
> (There is no skb_clone() after the first netlink_to_full_skb())
>
Thank you;
I will rework it
-RongQing
^ permalink raw reply
* Re: [PATCH net-next v5 03/20] zinc: ChaCha20 generic C implementation and selftest
From: Jason A. Donenfeld @ 2018-09-19 2:02 UTC (permalink / raw)
To: Eric Biggers
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <20180919010816.GD74746@gmail.com>
On Wed, Sep 19, 2018 at 3:08 AM Eric Biggers <ebiggers@kernel.org> wrote:
> Does this consistently perform as well as an implementation that organizes the
> operations such that the quarterrounds for all columns/diagonals are
> interleaved? As-is, there are tight dependencies in QUARTER_ROUND() (as well as
> in the existing chacha20_block() in lib/chacha20.c, for that matter), so we're
> heavily depending on the compiler to do the needed interleaving so as to not get
> potentially disastrous performance. Making it explicit could be a good idea.
It does perform as well, and the compiler outputs good code, even on
older compilers. Notably that's all a single statement (via the comma
operator).
> > +}
> > +
> > +static void chacha20_generic(u8 *out, const u8 *in, u32 len, const u32 key[8],
> > + const u32 counter[4])
> > +{
> > + __le32 buf[CHACHA20_BLOCK_WORDS];
> > + u32 x[] = {
> > + EXPAND_32_BYTE_K,
> > + key[0], key[1], key[2], key[3],
> > + key[4], key[5], key[6], key[7],
> > + counter[0], counter[1], counter[2], counter[3]
> > + };
> > +
> > + if (out != in)
> > + memmove(out, in, len);
> > +
> > + while (len >= CHACHA20_BLOCK_SIZE) {
> > + chacha20_block_generic(buf, x);
> > + crypto_xor(out, (u8 *)buf, CHACHA20_BLOCK_SIZE);
> > + len -= CHACHA20_BLOCK_SIZE;
> > + out += CHACHA20_BLOCK_SIZE;
> > + }
> > + if (len) {
> > + chacha20_block_generic(buf, x);
> > + crypto_xor(out, (u8 *)buf, len);
> > + }
> > +}
>
> If crypto_xor_cpy() is used instead of crypto_xor(), and 'in' is incremented
> along with 'out', then the memmove() is not needed.
Nice idea, thanks. Implemented.
Jason
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Jakub Kicinski @ 2018-09-19 1:55 UTC (permalink / raw)
To: Y Song
Cc: magnus.karlsson, Björn Töpel, Alexei Starovoitov,
Daniel Borkmann, netdev
In-Reply-To: <CAH3MdRU8jKBdpNK6Uq3NRyeb2ih6tgWJOAKW_pQFm0QQ0kuvpw@mail.gmail.com>
On Tue, 18 Sep 2018 10:22:11 -0700, Y Song wrote:
> > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > + * not know if the device has more tx queues than rx, or the opposite.
> > + * This might also change during run time.
> > + */
> > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > + u16 queue_id)
> > +{
> > + if (queue_id < dev->real_num_rx_queues)
> > + dev->_rx[queue_id].umem = umem;
> > + if (queue_id < dev->real_num_tx_queues)
> > + dev->_tx[queue_id].umem = umem;
> > +}
> > +
> > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > + u16 queue_id)
> > +{
> > + if (queue_id < dev->real_num_rx_queues)
> > + return dev->_rx[queue_id].umem;
> > + if (queue_id < dev->real_num_tx_queues)
> > + return dev->_tx[queue_id].umem;
> > +
> > + return NULL;
> > +}
> > +
> > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > +{
> > + /* Zero out the entry independent on how many queues are configured
> > + * at this point in time, as it might be used in the future.
> > + */
> > + if (queue_id < dev->num_rx_queues)
> > + dev->_rx[queue_id].umem = NULL;
> > + if (queue_id < dev->num_tx_queues)
> > + dev->_tx[queue_id].umem = NULL;
> > +}
> > +
>
> I am sure whether the following scenario can happen or not.
> Could you clarify?
> 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> 2. num_tx_queues is changed to 5
> 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> and dev->_rx[8].umum = 0.
> 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> dev->_rx[8].umem = umem2
> 5. num_tx_queues is changed to 10
> Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> a problem?
Plus IIRC the check of qid vs real_num_[rt]x_queues in xsk_bind() is
not under rtnl_lock so it doesn't count for much. Why not do all the
checks against num_[rt]x_queues here, instead of real_..?
^ permalink raw reply
* Re: bpfilter breaks IPT_SO_GET_INFO
From: Michal Kubecek @ 2018-09-19 7:18 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Alexei Starovoitov, David Miller, Daniel Borkmann, netdev, LKML,
syzkaller, netfilter-devel, Fabian Vogt
In-Reply-To: <CACT4Y+YS55tk5xoPmscBXcgSbLrgWFSLAz1MUEjby0XT8eanmQ@mail.gmail.com>
On Mon, Sep 17, 2018 at 03:36:21PM +0200, Dmitry Vyukov wrote:
> Hi,
>
> I am having some problem with upstream kernel and bpfilter. The
> manifestation is that IPT_SO_GET_INFO on an ipv4 socket works, then
> something (that I can't fully localize but can reproduce) happens and
> then IPT_SO_GET_INFO starts permanently returning 256.
...
> Now the litmus program always fails with:
>
> getsockopt(3, SOL_IP, 0x40 /* IP_??? */,
> "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., [84])
> = 256
>
> I am currently on upstream commit
> 28619527b8a712590c93d0a9e24b4425b9376a8c, my .config is attached. I
> don't know what is bpfilter, I see it mentions some umh, if it
> requires some additional setup I don't it, i.e. I don't install any
> userspace modules/helpers.
This looks similar to the fallback issue described here:
https://bugzilla.suse.com/show_bug.cgi?id=1106751#c1
Unfortunately I didn't have time to look into it more closely yet.
Michal Kubecek
^ permalink raw reply
* [PATCH RFT net-next 2/2] net: phy: marvell: Avoid unnecessary soft reset
From: Florian Fainelli @ 2018-09-19 1:35 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Andrew Lunn, nbd, cphealy,
harini.katakam, afleming, agust, arnd, asmirnov, avi.kp.137,
avorontsov, baijiaju1990, benh, charles-antoine.couret,
clemens.gruber, colin.king, cyril, david.thomson, ddaney,
dongsheng.wang, dwmw2, eha, houjingj, jeff, Jingju.Hou,
Jisheng.Zhang, johan, Kapil.Juneja, kim.phillips, linyunsheng,
madalin.
In-Reply-To: <20180919013505.11347-1-f.fainelli@gmail.com>
The BMCR.RESET bit on Marvell PHYs appears to be acting as a commit
operation, so we try to hit that bit which disrupts the link, only when
an actual register programming required a change.
Determine from marvell_set_polarity()'s return code whether the register value
was changed and if it was, propagate that to the logic that hits the software
reset bit. This avoids doing unnecessary soft reset if the PHY is configured in
the same state it was previously.
Since m88e1111_config_aneg() likely just hit the software reset bit
blindly without checking whether this is necessary, eliminate that
function and make it use the generic marvell_config_aneg() function
instead.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/marvell.c | 63 +++++++++++++--------------------------
1 file changed, 21 insertions(+), 42 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index f7c69ca34056..24fc4a73c300 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -265,7 +265,7 @@ static int marvell_set_polarity(struct phy_device *phydev, int polarity)
return err;
}
- return 0;
+ return val != reg;
}
static int marvell_set_downshift(struct phy_device *phydev, bool enable,
@@ -287,12 +287,15 @@ static int marvell_set_downshift(struct phy_device *phydev, bool enable,
static int marvell_config_aneg(struct phy_device *phydev)
{
+ int changed = 0;
int err;
err = marvell_set_polarity(phydev, phydev->mdix_ctrl);
if (err < 0)
return err;
+ changed = err;
+
err = phy_write(phydev, MII_M1111_PHY_LED_CONTROL,
MII_M1111_PHY_LED_DIRECT);
if (err < 0)
@@ -302,7 +305,7 @@ static int marvell_config_aneg(struct phy_device *phydev)
if (err < 0)
return err;
- if (phydev->autoneg != AUTONEG_ENABLE) {
+ if (phydev->autoneg != AUTONEG_ENABLE || changed) {
/* A write to speed/duplex bits (that is performed by
* genphy_config_aneg() call above) must be followed by
* a software reset. Otherwise, the write has no effect.
@@ -350,42 +353,6 @@ static int m88e1101_config_aneg(struct phy_device *phydev)
return marvell_config_aneg(phydev);
}
-static int m88e1111_config_aneg(struct phy_device *phydev)
-{
- int err;
-
- /* The Marvell PHY has an errata which requires
- * that certain registers get written in order
- * to restart autonegotiation
- */
- err = genphy_soft_reset(phydev);
-
- err = marvell_set_polarity(phydev, phydev->mdix_ctrl);
- if (err < 0)
- return err;
-
- err = phy_write(phydev, MII_M1111_PHY_LED_CONTROL,
- MII_M1111_PHY_LED_DIRECT);
- if (err < 0)
- return err;
-
- err = genphy_config_aneg(phydev);
- if (err < 0)
- return err;
-
- if (phydev->autoneg != AUTONEG_ENABLE) {
- /* A write to speed/duplex bits (that is performed by
- * genphy_config_aneg() call above) must be followed by
- * a software reset. Otherwise, the write has no effect.
- */
- err = genphy_soft_reset(phydev);
- if (err < 0)
- return err;
- }
-
- return 0;
-}
-
#ifdef CONFIG_OF_MDIO
/* Set and/or override some configuration registers based on the
* marvell,reg-init property stored in the of_node for the phydev.
@@ -479,6 +446,7 @@ static int m88e1121_config_aneg_rgmii_delays(struct phy_device *phydev)
static int m88e1121_config_aneg(struct phy_device *phydev)
{
+ int changed = 0;
int err = 0;
if (phy_interface_is_rgmii(phydev)) {
@@ -487,15 +455,26 @@ static int m88e1121_config_aneg(struct phy_device *phydev)
return err;
}
- err = genphy_soft_reset(phydev);
+ err = marvell_set_polarity(phydev, phydev->mdix_ctrl);
if (err < 0)
return err;
- err = marvell_set_polarity(phydev, phydev->mdix_ctrl);
+ changed = err;
+
+ err = genphy_config_aneg(phydev);
if (err < 0)
return err;
- return genphy_config_aneg(phydev);
+ if (phydev->autoneg != AUTONEG_ENABLE || changed) {
+ /* A software reset is used to ensure a "commit" of the
+ * changes is done.
+ */
+ err = genphy_soft_reset(phydev);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
}
static int m88e1318_config_aneg(struct phy_device *phydev)
@@ -2067,7 +2046,7 @@ static struct phy_driver marvell_drivers[] = {
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
.config_init = &m88e1111_config_init,
- .config_aneg = &m88e1111_config_aneg,
+ .config_aneg = &marvell_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
--
2.17.1
^ 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