* [patch net-next] net: sched: cls_matchall: allow to delete filter
From: Jiri Pirko @ 2019-06-17 16:02 UTC (permalink / raw)
To: netdev; +Cc: davem, mlxsw, eli, jhs, xiyou.wangcong
From: Jiri Pirko <jiri@mellanox.com>
Currently user is unable to delete the filter. See following example:
$ tc filter add dev ens16np1 ingress pref 1 handle 1 matchall action drop
$ tc filter show dev ens16np1 ingress
filter protocol all pref 1 matchall chain 0
filter protocol all pref 1 matchall chain 0 handle 0x1
in_hw
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1
$ tc filter del dev ens16np1 ingress pref 1 handle 1 matchall action drop
RTNETLINK answers: Operation not supported
Implement tcf_proto_ops->delete() op and allow user to delete the filter.
Reported-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_matchall.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index 38c0a9f0f296..a30d2f8feb32 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -21,6 +21,7 @@ struct cls_mall_head {
unsigned int in_hw_count;
struct tc_matchall_pcnt __percpu *pf;
struct rcu_work rwork;
+ bool deleting;
};
static int mall_classify(struct sk_buff *skb, const struct tcf_proto *tp,
@@ -258,7 +259,11 @@ static int mall_change(struct net *net, struct sk_buff *in_skb,
static int mall_delete(struct tcf_proto *tp, void *arg, bool *last,
bool rtnl_held, struct netlink_ext_ack *extack)
{
- return -EOPNOTSUPP;
+ struct cls_mall_head *head = rtnl_dereference(tp->root);
+
+ head->deleting = true;
+ *last = true;
+ return 0;
}
static void mall_walk(struct tcf_proto *tp, struct tcf_walker *arg,
@@ -269,7 +274,7 @@ static void mall_walk(struct tcf_proto *tp, struct tcf_walker *arg,
if (arg->count < arg->skip)
goto skip;
- if (!head)
+ if (!head || head->deleting)
return;
if (arg->fn(tp, head, arg) < 0)
arg->stop = 1;
--
2.20.1
^ permalink raw reply related
* [patch net-next internal] net: sched: cls_matchall: allow to delete filter
From: Jiri Pirko @ 2019-06-17 16:02 UTC (permalink / raw)
To: netdev; +Cc: davem, mlxsw, eli, jhs, xiyou.wangcong
From: Jiri Pirko <jiri@mellanox.com>
Currently user is unable to delete the filter. See following example:
$ tc filter add dev ens16np1 ingress pref 1 handle 1 matchall action drop
$ tc filter show dev ens16np1 ingress
filter protocol all pref 1 matchall chain 0
filter protocol all pref 1 matchall chain 0 handle 0x1
in_hw
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1
$ tc filter del dev ens16np1 ingress pref 1 handle 1 matchall action drop
RTNETLINK answers: Operation not supported
Implement tcf_proto_ops->delete() op and allow user to delete the filter.
Reported-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_matchall.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index 38c0a9f0f296..a30d2f8feb32 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -21,6 +21,7 @@ struct cls_mall_head {
unsigned int in_hw_count;
struct tc_matchall_pcnt __percpu *pf;
struct rcu_work rwork;
+ bool deleting;
};
static int mall_classify(struct sk_buff *skb, const struct tcf_proto *tp,
@@ -258,7 +259,11 @@ static int mall_change(struct net *net, struct sk_buff *in_skb,
static int mall_delete(struct tcf_proto *tp, void *arg, bool *last,
bool rtnl_held, struct netlink_ext_ack *extack)
{
- return -EOPNOTSUPP;
+ struct cls_mall_head *head = rtnl_dereference(tp->root);
+
+ head->deleting = true;
+ *last = true;
+ return 0;
}
static void mall_walk(struct tcf_proto *tp, struct tcf_walker *arg,
@@ -269,7 +274,7 @@ static void mall_walk(struct tcf_proto *tp, struct tcf_walker *arg,
if (arg->count < arg->skip)
goto skip;
- if (!head)
+ if (!head || head->deleting)
return;
if (arg->fn(tp, head, arg) < 0)
arg->stop = 1;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] macb: Add support for SiFive FU540-C000
From: Andrew Lunn @ 2019-06-17 15:58 UTC (permalink / raw)
To: Yash Shah
Cc: davem, devicetree, netdev, linux-kernel, linux-riscv, robh+dt,
mark.rutland, nicolas.ferre, palmer, aou, paul.walmsley, ynezz,
sachin.ghadi
In-Reply-To: <1560745167-9866-3-git-send-email-yash.shah@sifive.com>
On Mon, Jun 17, 2019 at 09:49:27AM +0530, Yash Shah wrote:
> The management IP block is tightly coupled with the Cadence MACB IP
> block on the FU540, and manages many of the boundary signals from the
> MACB IP. This patch only controls the tx_clk input signal to the MACB
> IP. Future patches may add support for monitoring or controlling other
> IP boundary signals.
>
> Signed-off-by: Yash Shah <yash.shah@sifive.com>
> ---
> drivers/net/ethernet/cadence/Kconfig | 6 ++
> drivers/net/ethernet/cadence/macb_main.c | 129 +++++++++++++++++++++++++++++++
> 2 files changed, 135 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index b998401..d478fae 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -48,4 +48,10 @@ config MACB_PCI
> To compile this driver as a module, choose M here: the module
> will be called macb_pci.
>
> +config MACB_SIFIVE_FU540
> + bool "Cadence MACB/GEM support for SiFive FU540 SoC"
> + depends on MACB && GPIO_SIFIVE
> + help
> + Enable the Cadence MACB/GEM support for SiFive FU540 SoC.
> +
> endif # NET_VENDOR_CADENCE
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index c049410..275b5e8 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -10,6 +10,7 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> #include <linux/clk.h>
> +#include <linux/clk-provider.h>
> #include <linux/crc32.h>
> #include <linux/module.h>
> #include <linux/moduleparam.h>
> @@ -40,6 +41,15 @@
> #include <linux/pm_runtime.h>
> #include "macb.h"
>
> +/* This structure is only used for MACB on SiFive FU540 devices */
> +struct sifive_fu540_macb_mgmt {
> + void __iomem *reg;
> + unsigned long rate;
> + struct clk_hw hw;
> +};
> +
> +static struct sifive_fu540_macb_mgmt *mgmt;
> +
> #define MACB_RX_BUFFER_SIZE 128
> #define RX_BUFFER_MULTIPLE 64 /* bytes */
>
> @@ -3903,6 +3913,116 @@ static int at91ether_init(struct platform_device *pdev)
> return 0;
> }
>
> +static unsigned long fu540_macb_tx_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + return mgmt->rate;
> +}
> +
> +static long fu540_macb_tx_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + if (WARN_ON(rate < 2500000))
> + return 2500000;
> + else if (rate == 2500000)
> + return 2500000;
> + else if (WARN_ON(rate < 13750000))
> + return 2500000;
> + else if (WARN_ON(rate < 25000000))
> + return 25000000;
> + else if (rate == 25000000)
> + return 25000000;
> + else if (WARN_ON(rate < 75000000))
> + return 25000000;
> + else if (WARN_ON(rate < 125000000))
> + return 125000000;
> + else if (rate == 125000000)
> + return 125000000;
> +
> + WARN_ON(rate > 125000000);
> +
> + return 125000000;
> +}
> +
> +static int fu540_macb_tx_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + rate = fu540_macb_tx_round_rate(hw, rate, &parent_rate);
> + if (rate != 125000000)
> + iowrite32(1, mgmt->reg);
> + else
> + iowrite32(0, mgmt->reg);
> + mgmt->rate = rate;
> +
> + return 0;
> +}
> +
> +static const struct clk_ops fu540_c000_ops = {
> + .recalc_rate = fu540_macb_tx_recalc_rate,
> + .round_rate = fu540_macb_tx_round_rate,
> + .set_rate = fu540_macb_tx_set_rate,
> +};
> +
> +static int fu540_c000_clk_init(struct platform_device *pdev, struct clk **pclk,
> + struct clk **hclk, struct clk **tx_clk,
> + struct clk **rx_clk, struct clk **tsu_clk)
> +{
> + struct clk_init_data init;
> + int err = 0;
> +
> + err = macb_clk_init(pdev, pclk, hclk, tx_clk, rx_clk, tsu_clk);
> + if (err)
> + return err;
> +
> + mgmt = devm_kzalloc(&pdev->dev, sizeof(*mgmt), GFP_KERNEL);
> + if (!mgmt)
> + return -ENOMEM;
> +
> + init.name = "sifive-gemgxl-mgmt";
> + init.ops = &fu540_c000_ops;
> + init.flags = 0;
> + init.num_parents = 0;
> +
> + mgmt->rate = 0;
> + mgmt->hw.init = &init;
> +
> + *tx_clk = clk_register(NULL, &mgmt->hw);
> + if (IS_ERR(*tx_clk))
> + return PTR_ERR(*tx_clk);
> +
> + err = clk_prepare_enable(*tx_clk);
> + if (err)
> + dev_err(&pdev->dev, "failed to enable tx_clk (%u)\n", err);
> + else
> + dev_info(&pdev->dev, "Registered clk switch '%s'\n", init.name);
> +
> + return 0;
> +}
> +
> +static int fu540_c000_init(struct platform_device *pdev)
> +{
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res)
> + return -ENODEV;
> +
> + mgmt->reg = ioremap(res->start, resource_size(res));
> + if (!mgmt->reg)
> + return -ENOMEM;
> +
> + return macb_init(pdev);
> +}
> +
> +static const struct macb_config fu540_c000_config = {
> + .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO |
> + MACB_CAPS_GEM_HAS_PTP,
> + .dma_burst_length = 16,
> + .clk_init = fu540_c000_clk_init,
> + .init = fu540_c000_init,
> + .jumbo_max_len = 10240,
> +};
> +
> static const struct macb_config at91sam9260_config = {
> .caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
> .clk_init = macb_clk_init,
> @@ -3992,6 +4112,9 @@ static int at91ether_init(struct platform_device *pdev)
> { .compatible = "cdns,emac", .data = &emac_config },
> { .compatible = "cdns,zynqmp-gem", .data = &zynqmp_config},
> { .compatible = "cdns,zynq-gem", .data = &zynq_config },
> +#ifdef CONFIG_MACB_SIFIVE_FU540
> + { .compatible = "sifive,fu540-macb", .data = &fu540_c000_config },
> +#endif
This #ifdef should not be needed.
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, macb_dt_ids);
> @@ -4199,6 +4322,9 @@ static int macb_probe(struct platform_device *pdev)
>
> err_disable_clocks:
> clk_disable_unprepare(tx_clk);
> +#ifdef CONFIG_MACB_SIFIVE_FU540
> + clk_unregister(tx_clk);
> +#endif
So long as tx_clk is NULL, you can call clk_unregister(). So please
remove the #ifdef.
> clk_disable_unprepare(hclk);
> clk_disable_unprepare(pclk);
> clk_disable_unprepare(rx_clk);
> @@ -4233,6 +4359,9 @@ static int macb_remove(struct platform_device *pdev)
> pm_runtime_dont_use_autosuspend(&pdev->dev);
> if (!pm_runtime_suspended(&pdev->dev)) {
> clk_disable_unprepare(bp->tx_clk);
> +#ifdef CONFIG_MACB_SIFIVE_FU540
> + clk_unregister(bp->tx_clk);
> +#endif
Same here.
In general try to avoid #ifdef in C code.
Andrew
^ permalink raw reply
* [PATCH] net: lio_core: fix potential sign-extension overflow on large shift
From: Colin King @ 2019-06-17 15:53 UTC (permalink / raw)
To: Derek Chickles, Satanand Burla, Felix Manlunas, David S . Miller,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Left shifting the signed int value 1 by 31 bits has undefined behaviour
and the shift amount oq_no can be as much as 63. Fix this by widening
the int 1 to 1ULL.
Addresses-Coverity: ("Bad shift operation")
Fixes: f21fb3ed364b ("Add support of Cavium Liquidio ethernet adapters")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/cavium/liquidio/lio_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c b/drivers/net/ethernet/cavium/liquidio/lio_core.c
index 1c50c10b5a16..e78bdcee200f 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_core.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_core.c
@@ -964,7 +964,7 @@ static void liquidio_schedule_droq_pkt_handlers(struct octeon_device *oct)
if (droq->ops.poll_mode) {
droq->ops.napi_fn(droq);
- oct_priv->napi_mask |= (1 << oq_no);
+ oct_priv->napi_mask |= (1ULL << oq_no);
} else {
tasklet_schedule(&oct_priv->droq_tasklet);
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v3] ipv4: Support multipath hashing on inner IP pkts for GRE tunnel
From: David Ahern @ 2019-06-17 15:53 UTC (permalink / raw)
To: Ido Schimmel, Stephen Suryaputra; +Cc: netdev, nikolay
In-Reply-To: <20190617143932.GA9828@splinter>
On 6/17/19 8:39 AM, Ido Schimmel wrote:
>
> Do you plan to add IPv6 support? Would be good to have the same features
> in both stacks.
we really should be mandating equal support for all new changes like this.
>
> Also, we have tests for these sysctls under
> tools/testing/selftests/net/forwarding/router_multipath.sh
>
> Can you add a test for this change as well? You'll probably need to
> create a new file given the topology created by router_multipath.sh does
> not include tunnels.
>
> Thanks
>
^ permalink raw reply
* Re: [PATCH] bpf: hide do_bpf_send_signal when unused
From: Alexei Starovoitov @ 2019-06-17 15:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steven Rostedt, Ingo Molnar, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Yonghong Song, Martin KaFai Lau, Song Liu,
Matt Mullins, Network Development, bpf, LKML
In-Reply-To: <20190617125724.1616165-1-arnd@arndb.de>
On Mon, Jun 17, 2019 at 5:59 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> When CONFIG_MODULES is disabled, this function is never called:
>
> kernel/trace/bpf_trace.c:581:13: error: 'do_bpf_send_signal' defined but not used [-Werror=unused-function]
hmm. it should work just fine without modules.
the bug is somewhere else.
^ permalink raw reply
* [RFC PATCH] e1000e: e1000_workqueue can be static
From: kbuild test robot @ 2019-06-17 15:25 UTC (permalink / raw)
To: Detlev Casanova
Cc: kbuild-all, Jeff Kirsher, David S. Miller, intel-wired-lan,
netdev, linux-kernel, Detlev Casanova
In-Reply-To: <20190616145445.9637-1-detlev.casanova@gmail.com>
Fixes: ef431cc0a6a5 ("e1000e: Make watchdog use delayed work")
Signed-off-by: kbuild test robot <lkp@intel.com>
---
netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 0fc95fb..a1526e7 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -39,7 +39,7 @@ static int debug = -1;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
-struct workqueue_struct *e1000_workqueue;
+static struct workqueue_struct *e1000_workqueue;
static const struct e1000_info *e1000_info_tbl[] = {
[board_82571] = &e1000_82571_info,
^ permalink raw reply related
* Re: [PATCH] e1000e: Make watchdog use delayed work
From: kbuild test robot @ 2019-06-17 15:25 UTC (permalink / raw)
To: Detlev Casanova
Cc: kbuild-all, Jeff Kirsher, David S. Miller, intel-wired-lan,
netdev, linux-kernel, Detlev Casanova
In-Reply-To: <20190616145445.9637-1-detlev.casanova@gmail.com>
Hi Detlev,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on jkirsher-next-queue/dev-queue]
[also build test WARNING on v5.2-rc5 next-20190617]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Detlev-Casanova/e1000e-Make-watchdog-use-delayed-work/20190617-154840
base: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH 1/2] perf trace: Use pr_debug() instead of fprintf() for logging
From: Arnaldo Carvalho de Melo @ 2019-06-17 15:24 UTC (permalink / raw)
To: Leo Yan
Cc: Alexander Shishkin, Jiri Olsa, Namhyung Kim, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Yonghong Song,
linux-kernel, netdev, bpf
In-Reply-To: <20190617091140.24372-1-leo.yan@linaro.org>
Em Mon, Jun 17, 2019 at 05:11:39PM +0800, Leo Yan escreveu:
> In the function trace__syscall_info(), it explicitly checks verbose
> level and print out log with fprintf(). Actually, we can use
> pr_debug() to do the same thing for debug logging.
>
> This patch uses pr_debug() instead of fprintf() for debug logging; it
> includes a minor fixing for 'space before tab in indent', which
> dismisses git warning when apply it.
But those are not fprintf(stdout,), they explicitely redirect to the
output file that the user may have specified using 'perf trace --output
filename.trace' :-)
- Arnaldo
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/perf/builtin-trace.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index bd1f00e7a2eb..5cd74651db4c 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -1760,12 +1760,11 @@ static struct syscall *trace__syscall_info(struct trace *trace,
> * grep "NR -1 " /t/trace_pipe
> *
> * After generating some load on the machine.
> - */
> - if (verbose > 1) {
> - static u64 n;
> - fprintf(trace->output, "Invalid syscall %d id, skipping (%s, %" PRIu64 ") ...\n",
> - id, perf_evsel__name(evsel), ++n);
> - }
> + */
> + static u64 n;
> +
> + pr_debug("Invalid syscall %d id, skipping (%s, %" PRIu64 ")\n",
> + id, perf_evsel__name(evsel), ++n);
> return NULL;
> }
>
> @@ -1779,12 +1778,10 @@ static struct syscall *trace__syscall_info(struct trace *trace,
> return &trace->syscalls.table[id];
>
> out_cant_read:
> - if (verbose > 0) {
> - fprintf(trace->output, "Problems reading syscall %d", id);
> - if (id <= trace->syscalls.max && trace->syscalls.table[id].name != NULL)
> - fprintf(trace->output, "(%s)", trace->syscalls.table[id].name);
> - fputs(" information\n", trace->output);
> - }
> + pr_debug("Problems reading syscall %d", id);
> + if (id <= trace->syscalls.max && trace->syscalls.table[id].name != NULL)
> + pr_debug("(%s)", trace->syscalls.table[id].name);
> + pr_debug(" information\n");
> return NULL;
> }
>
> --
> 2.17.1
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH 6/6] net: macb: parameter added to cadence ethernet controller DT binding
From: Andrew Lunn @ 2019-06-17 15:21 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, f.fainelli, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1560642579-29803-1-git-send-email-pthombar@cadence.com>
On Sun, Jun 16, 2019 at 12:49:39AM +0100, Parshuram Thombare wrote:
> New parameters added to Cadence ethernet controller DT binding
> for USXGMII interface.
>
> Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> index 9c5e94482b5f..cd79ec9dddfb 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -25,6 +25,10 @@ Required properties:
> Optional elements: 'rx_clk' applies to cdns,zynqmp-gem
> Optional elements: 'tsu_clk'
> - clocks: Phandles to input clocks.
> +- serdes-rate External serdes rate.Mandatory for USXGMII mode.
> + 0 - 5G
> + 1 - 10G
Please use the values 5 and 10, not 0 and 1. This also needs a vendor
prefix.
Andrew
^ permalink raw reply
* Re: [PATCH 5/6] net: macb: add support for high speed interface
From: Andrew Lunn @ 2019-06-17 15:19 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, f.fainelli, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1560642512-28765-1-git-send-email-pthombar@cadence.com>
> switch (state->interface) {
> + case PHY_INTERFACE_MODE_NA:
I would not list PHY_INTERFACE_MODE_NA here.
> + case PHY_INTERFACE_MODE_USXGMII:
> + case PHY_INTERFACE_MODE_10GKR:
> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
> + phylink_set(mask, 10000baseCR_Full);
> + phylink_set(mask, 10000baseER_Full);
> + phylink_set(mask, 10000baseKR_Full);
> + phylink_set(mask, 10000baseLR_Full);
> + phylink_set(mask, 10000baseLRM_Full);
> + phylink_set(mask, 10000baseSR_Full);
> + phylink_set(mask, 10000baseT_Full);
> + phylink_set(mask, 5000baseT_Full);
> + phylink_set(mask, 2500baseX_Full);
> + phylink_set(mask, 1000baseX_Full);
> + }
> + /* Fall-through */
> case PHY_INTERFACE_MODE_SGMII:
> if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
> phylink_set(mask, 2500baseT_Full);
> @@ -594,17 +639,55 @@ static void gem_mac_config(struct phylink_config *pl_config, unsigned int mode,
> reg |= MACB_BIT(FD);
> macb_or_gem_writel(bp, NCFGR, reg);
>
> - if (state->speed == SPEED_2500) {
> - gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> - gem_readl(bp, NCFGR));
> - gem_writel(bp, NCR, GEM_BIT(TWO_PT_FIVE_GIG) |
> - gem_readl(bp, NCR));
> - } else if (state->speed == SPEED_1000) {
> - gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> - gem_readl(bp, NCFGR));
> - } else if (state->speed == SPEED_100) {
> - macb_writel(bp, NCFGR, MACB_BIT(SPD) |
> - macb_readl(bp, NCFGR));
> + if (bp->phy_interface == PHY_INTERFACE_MODE_USXGMII) {
> + u32 speed;
> +
> + switch (state->speed) {
> + case SPEED_10000:
> + if (bp->serdes_rate ==
> + MACB_SERDES_RATE_10_PT_3125Gbps) {
> + speed = HS_MAC_SPEED_10000M;
> + } else {
> + netdev_warn(netdev,
> + "10G not supported by HW");
> + netdev_warn(netdev, "Setting speed to 1G");
> + speed = HS_MAC_SPEED_1000M;
> + }
> + break;
> + case SPEED_5000:
> + speed = HS_MAC_SPEED_5000M;
> + break;
> + case SPEED_2500:
> + speed = HS_MAC_SPEED_2500M;
> + break;
> + case SPEED_1000:
> + speed = HS_MAC_SPEED_1000M;
> + break;
> + default:
> + case SPEED_100:
> + speed = HS_MAC_SPEED_100M;
> + break;
> + }
> +
> + gem_writel(bp, HS_MAC_CONFIG,
> + GEM_BFINS(HS_MAC_SPEED, speed,
> + gem_readl(bp, HS_MAC_CONFIG)));
> + gem_writel(bp, USX_CONTROL,
> + GEM_BFINS(USX_CTRL_SPEED, speed,
> + gem_readl(bp, USX_CONTROL)));
> + } else {
> + if (state->speed == SPEED_2500) {
> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> + gem_readl(bp, NCFGR));
> + gem_writel(bp, NCR, GEM_BIT(TWO_PT_FIVE_GIG) |
> + gem_readl(bp, NCR));
> + } else if (state->speed == SPEED_1000) {
> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> + gem_readl(bp, NCFGR));
> + } else if (state->speed == SPEED_100) {
> + macb_writel(bp, NCFGR, MACB_BIT(SPD) |
> + macb_readl(bp, NCFGR));
> + }
Maybe split this up into two helper functions?
Andrew
^ permalink raw reply
* Re: [PATCH v12 1/5] can: m_can: Create a m_can platform framework
From: Dan Murphy @ 2019-06-17 15:09 UTC (permalink / raw)
To: wg, mkl, davem; +Cc: linux-can, netdev, linux-kernel
In-Reply-To: <0f6c41c8-0071-ed3a-9e65-caf02a0fbefe@ti.com>
Marc
On 6/10/19 11:35 AM, Dan Murphy wrote:
> Bump
>
> On 6/6/19 8:16 AM, Dan Murphy wrote:
>> Marc
>>
>> Bump
>>
>> On 5/31/19 6:51 AM, Dan Murphy wrote:
>>> Marc
>>>
>>> On 5/15/19 3:54 PM, Dan Murphy wrote:
>>>> Marc
>>>>
>>>> On 5/9/19 11:11 AM, Dan Murphy wrote:
>>>>> Create a m_can platform framework that peripheral
>>>>> devices can register to and use common code and register sets.
>>>>> The peripheral devices may provide read/write and configuration
>>>>> support of the IP.
>>>>>
>>>>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>> ---
>>>>>
>>>>> v12 - Update the m_can_read/write functions to create a backtrace
>>>>> if the callback
>>>>> pointer is NULL. - https://lore.kernel.org/patchwork/patch/1052302/
>>>>>
>>>> Is this able to be merged now?
>>>
>>> ping
Wondering if there is anything else we need to do?
The part has officially shipped and we had hoped to have driver support
in Linux as part of the announcement.
Dan
>>>
>>>
>>>> Dan
>>>>
>>>> <snip>
^ permalink raw reply
* Re: [PATCH 0/6] net: macb patch set cover letter
From: Andrew Lunn @ 2019-06-17 15:08 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, f.fainelli, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1560642311-25585-1-git-send-email-pthombar@cadence.com>
> 5. 0005-net-macb-add-support-for-high-speed-interface
> This patch add support for 10G USXGMII PCS in fixed mode.
> Since emulated PHY used in fixed mode doesn't seems to
> support anything above 1G, additional parameter is used outside
> "fixed-link" node for selecting speed and "fixed-link"
> node speed is still set at 1G.
PHYLINK does support higher speeds for fixed-link.
Andrew
^ permalink raw reply
* RE: [PATCH 6/9] x86/bpf: Fix JIT frame pointer usage
From: David Laight @ 2019-06-17 15:07 UTC (permalink / raw)
To: 'Josh Poimboeuf'
Cc: 'Alexei Starovoitov', x86@kernel.org,
linux-kernel@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
netdev@vger.kernel.org, bpf@vger.kernel.org, Peter Zijlstra,
Song Liu, Kairui Song
In-Reply-To: <20190614170720.57yxtxvd4qee337l@treble>
From: Josh Poimboeuf
> Sent: 14 June 2019 18:07
...
> > I do remember a stack trace printer for x86 this didn't need
> > any annotation of the object code and didn't need frame pointers.
> > The only downside was that it had to 'guess' (ie scan the stack)
> > to get out of functions that couldn't return.
> > Basically it followed the control flow forwards tracking the
> > values of %sp and %bp until it found a return instuction.
> > All it has to do is detect loops and retry from the other
> > target of conditional branches.
>
> That actually sounds kind of cool, though I don't think we need that for
> the kernel.
No reason why not.
It would save most of the instrumentation the orc unwinder needs.
It isn't as though the performance of kernel tracebacks is that
important (printf and symbol lookup probably always dominates).
The only difficulty for x86 is quickly determining the size of
instructions.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 0/6] net: macb patch set cover letter
From: Andrew Lunn @ 2019-06-17 15:04 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, f.fainelli, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1560642311-25585-1-git-send-email-pthombar@cadence.com>
> 3. 003-net-macb-add-PHY-configuration-in-MACB-PCI-wrapper.patch
> This patch is to configure TI PHY DP83867 in SGMII mode from
> our MAC PCI wrapper driver.
> With this change there is no need of PHY driver and dp83867
> module must be disabled. Users wanting to setup DP83867 PHY
> in SGMII mode can disable dp83867.ko driver, else dp83867.ko
> overwrite this configuration and PHY is setup as per dp83867.ko.
This sounds very wrong. Why not make the dp83867 driver support SGMII?
Andrew
^ permalink raw reply
* Re: [PATCH 2/6] net: macb: add support for sgmii MAC-PHY interface
From: Andrew Lunn @ 2019-06-17 15:01 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, f.fainelli, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1560642409-27074-1-git-send-email-pthombar@cadence.com>
> @@ -159,6 +160,9 @@
> #define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
> #define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
> #define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
> +#define GEM_PCS_CTRL 0x0200 /* PCS Control */
> +#define GEM_PCS_STATUS 0x0204 /* PCS Status */
> +#define GEM_PCS_AN_LP_BASE 0x0214 /* PCS AN LP BASE*/
It looks like there are some space vs tab issues here and else where.
> static int gem_phylink_mac_link_state(struct phylink_config *pl_config,
> struct phylink_link_state *state)
> {
> + u32 status;
> struct net_device *netdev = to_net_dev(pl_config->dev);
> struct macb *bp = netdev_priv(netdev);
Reverse christmas tree please, here and everywhere you add new
variables.
>
> - state->speed = bp->speed;
> - state->duplex = bp->duplex;
> - state->link = bp->link;
> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
> + status = gem_readl(bp, PCS_STATUS);
> + state->an_complete = GEM_BFEXT(PCS_STATUS_AN_DONE, status);
> + status = gem_readl(bp, PCS_AN_LP_BASE);
> + switch (GEM_BFEXT(PCS_AN_LP_BASE_SPEED, status)) {
> + case 0:
> + state->speed = 10;
> + break;
> + case 1:
> + state->speed = 100;
> + break;
> + case 2:
> + state->speed = 1000;
> + break;
> + default:
> + break;
It would be nice to use SPEED_10, SPEED_100, etc.
> @@ -494,17 +551,23 @@ static void gem_mac_config(struct phylink_config *pl_config, unsigned int mode,
> reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
> if (macb_is_gem(bp))
> reg &= ~GEM_BIT(GBE);
> -
> if (state->duplex)
> reg |= MACB_BIT(FD);
> - if (state->speed == SPEED_100)
> - reg |= MACB_BIT(SPD);
> - if (state->speed == SPEED_1000 &&
> - bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
> - reg |= GEM_BIT(GBE);
> -
> macb_or_gem_writel(bp, NCFGR, reg);
>
> + if (state->speed == SPEED_2500) {
> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> + gem_readl(bp, NCFGR));
> + gem_writel(bp, NCR, GEM_BIT(TWO_PT_FIVE_GIG) |
> + gem_readl(bp, NCR));
> + } else if (state->speed == SPEED_1000) {
> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> + gem_readl(bp, NCFGR));
> + } else if (state->speed == SPEED_100) {
> + macb_writel(bp, NCFGR, MACB_BIT(SPD) |
> + macb_readl(bp, NCFGR));
> + }
Maybe a switch statement?
> @@ -4232,11 +4327,37 @@ static int macb_probe(struct platform_device *pdev)
> }
>
> err = of_get_phy_mode(np);
The following code would be more readable if you replaced err with
phy_mode, or interface.
> - if (err < 0)
> + if (err < 0) {
> /* not found in DT, MII by default */
> bp->phy_interface = PHY_INTERFACE_MODE_MII;
> - else
> + } else if (bp->caps & MACB_CAPS_MACB_IS_GEM_GXL) {
> + u32 interface_supported = 1;
> +
> + if (err == PHY_INTERFACE_MODE_SGMII ||
> + err == PHY_INTERFACE_MODE_1000BASEX ||
> + err == PHY_INTERFACE_MODE_2500BASEX) {
> + if (!(bp->caps & MACB_CAPS_PCS))
> + interface_supported = 0;
> + } else if (err == PHY_INTERFACE_MODE_GMII ||
> + err == PHY_INTERFACE_MODE_RGMII) {
> + if (!macb_is_gem(bp))
> + interface_supported = 0;
> + } else if (err != PHY_INTERFACE_MODE_RMII &&
> + err != PHY_INTERFACE_MODE_MII) {
> + /* Add new mode before this */
> + interface_supported = 0;
> + }
> +
> + if (!interface_supported) {
> + netdev_err(dev, "Phy mode %s not supported",
> + phy_modes(err));
> + goto err_out_free_netdev;
> + }
> +
> bp->phy_interface = err;
> + } else {
> + bp->phy_interface = err;
> + }
Andrew
^ permalink raw reply
* [PATCH] perf cs-etm: Improve completeness for kernel address space
From: Leo Yan @ 2019-06-17 15:00 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, linux-kernel, linux-arm-kernel, netdev,
bpf
Cc: Leo Yan, Mathieu Poirier, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Peter Zijlstra, Suzuki Poulouse, coresight
Arm and arm64 architecture reserve some memory regions prior to the
symbol '_stext' and these memory regions later will be used by device
module and BPF jit. The current code misses to consider these memory
regions thus any address in the regions will be taken as user space
mode, but perf cannot find the corresponding dso with the wrong CPU
mode so we misses to generate samples for device module and BPF
related trace data.
This patch parse the link scripts to get the memory size prior to start
address and reduce this size from 'etmq->etm->kernel_start', then can
get a fixed up kernel start address which contain memory regions for
device module and BPF. Finally, cs_etm__cpu_mode() can return right
mode for these memory regions and perf can successfully generate
samples.
The reason for parsing the link scripts is Arm architecture changes text
offset dependent on different platforms, which define multiple text
offsets in $kernel/arch/arm/Makefile. This offset is decided when build
kernel and the final value is extended in the link script, so we can
extract the used value from the link script. We use the same way to
parse arm64 link script as well. If fail to find the link script, the
pre start memory size is assumed as zero, in this case it has no any
change caused with this patch.
Below is detailed info for testing this patch:
- Build LLVM/Clang 8.0 or later version;
- Configure perf with ~/.perfconfig:
root@debian:~# cat ~/.perfconfig
# this file is auto-generated.
[llvm]
clang-path = /mnt/build/llvm-build/build/install/bin/clang
kbuild-dir = /mnt/linux-kernel/linux-cs-dev/
clang-opt = "-DLINUX_VERSION_CODE=0x50200 -g"
dump-obj = true
[trace]
show_zeros = yes
show_duration = no
no_inherit = yes
show_timestamp = no
show_arg_names = no
args_alignment = 40
show_prefix = yes
- Run 'perf trace' command with eBPF event:
root@debian:~# perf trace -e string \
-e $kernel/tools/perf/examples/bpf/augmented_raw_syscalls.c
- Read eBPF program memory mapping in kernel:
root@debian:~# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms
root@debian:~# cat /proc/kallsyms | grep -E "bpf_prog_.+_sys_[enter|exit]"
ffff000000086a84 t bpf_prog_f173133dc38ccf87_sys_enter [bpf]
ffff000000088618 t bpf_prog_c1bd85c092d6e4aa_sys_exit [bpf]
- Launch any program which accesses file system frequently so can hit
the system calls trace flow with eBPF event;
- Capture CoreSight trace data with filtering eBPF program:
root@debian:~# perf record -e cs_etm/@20070000.etr/ \
--filter 'filter 0xffff000000086a84/0x800' -a sleep 5s
- Annotate for symbol 'bpf_prog_f173133dc38ccf87_sys_enter':
root@debian:~# perf report
Then select 'branches' samples and press 'a' to annotate symbol
'bpf_prog_f173133dc38ccf87_sys_enter', press 'P' to print to the
bpf_prog_f173133dc38ccf87_sys_enter.annotation file:
root@debian:~# cat bpf_prog_f173133dc38ccf87_sys_enter.annotation
bpf_prog_f173133dc38ccf87_sys_enter() bpf_prog_f173133dc38ccf87_sys_enter
Event: branches
Percent int sys_enter(struct syscall_enter_args *args)
stp x29, x30, [sp, #-16]!
int key = 0;
mov x29, sp
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x19, x20, [sp, #-16]!
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x21, x22, [sp, #-16]!
stp x25, x26, [sp, #-16]!
return bpf_get_current_pid_tgid();
mov x25, sp
return bpf_get_current_pid_tgid();
mov x26, #0x0 // #0
sub sp, sp, #0x10
return bpf_map_lookup_elem(pids, &pid) != NULL;
add x19, x0, #0x0
mov x0, #0x0 // #0
mov x10, #0xfffffffffffffff8 // #-8
if (pid_filter__has(&pids_filtered, getpid()))
str w0, [x25, x10]
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
add x1, x25, #0x0
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
mov x10, #0xfffffffffffffff8 // #-8
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
add x1, x1, x10
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
mov x0, #0xffff8009ffffffff // #-140694538682369
movk x0, #0x6698, lsl #16
movk x0, #0x3e00
mov x10, #0xffffffffffff1040 // #-61376
if (syscall == NULL || !syscall->enabled)
movk x10, #0x1023, lsl #16
if (syscall == NULL || !syscall->enabled)
movk x10, #0x0, lsl #32
loop_iter_first()
3.69 → blr bpf_prog_f173133dc38ccf87_sys_enter
loop_iter_first()
add x7, x0, #0x0
loop_iter_first()
add x20, x7, #0x0
int size = probe_read_str(&augmented_filename->value, filename_len, filename_arg);
mov x0, #0x1 // #1
[...]
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/Makefile.config | 24 ++++++++++++++++++++++++
tools/perf/util/cs-etm.c | 26 +++++++++++++++++++++++++-
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 51dd00f65709..4776c2c1fb6d 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -418,6 +418,30 @@ ifdef CORESIGHT
endif
LDFLAGS += $(LIBOPENCSD_LDFLAGS)
EXTLIBS += $(OPENCSDLIBS)
+ ifneq ($(wildcard $(srctree)/arch/arm64/kernel/vmlinux.lds),)
+ # Extract info from lds:
+ # . = ((((((((0xffffffffffffffff)) - (((1)) << (48)) + 1) + (0)) + (0x08000000))) + (0x08000000))) + 0x00080000;
+ # ARM64_PRE_START_SIZE := (0x08000000 + 0x08000000 + 0x00080000)
+ ARM64_PRE_START_SIZE := $(shell egrep ' \. \= \({8}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/arm64/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{print "("$$6 "+" $$7 "+" $$8")"}' 2>/dev/null)
+ else
+ ARM64_PRE_START_SIZE := 0
+ endif
+ CFLAGS += -DARM64_PRE_START_SIZE="$(ARM64_PRE_START_SIZE)"
+ ifneq ($(wildcard $(srctree)/arch/arm/kernel/vmlinux.lds),)
+ # Extract info from lds:
+ # . = ((0xC0000000)) + 0x00208000;
+ # ARM_PRE_START_SIZE := 0x00208000
+ ARM_PRE_START_SIZE := $(shell egrep ' \. \= \({2}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/arm/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{print "("$$2")"}' 2>/dev/null)
+ else
+ ARM_PRE_START_SIZE := 0
+ endif
+ CFLAGS += -DARM_PRE_START_SIZE="$(ARM_PRE_START_SIZE)"
$(call detected,CONFIG_LIBOPENCSD)
ifdef CSTRACE_RAW
CFLAGS += -DCS_DEBUG_RAW
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 0c7776b51045..ae831f836c70 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -613,10 +613,34 @@ static void cs_etm__free(struct perf_session *session)
static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
{
struct machine *machine;
+ u64 fixup_kernel_start = 0;
+ const char *arch;
machine = etmq->etm->machine;
+ arch = perf_env__arch(machine->env);
- if (address >= etmq->etm->kernel_start) {
+ /*
+ * Since arm and arm64 specify some memory regions prior to
+ * 'kernel_start', kernel addresses can be less than 'kernel_start'.
+ *
+ * For arm architecture, the 16MB virtual memory space prior to
+ * 'kernel_start' is allocated to device modules, a PMD table if
+ * CONFIG_HIGHMEM is enabled and a PGD table.
+ *
+ * For arm64 architecture, the root PGD table, device module memory
+ * region and BPF jit region are prior to 'kernel_start'.
+ *
+ * To reflect the complete kernel address space, compensate these
+ * pre-defined regions for kernel start address.
+ */
+ if (!strcmp(arch, "arm64"))
+ fixup_kernel_start = etmq->etm->kernel_start -
+ ARM64_PRE_START_SIZE;
+ else if (!strcmp(arch, "arm"))
+ fixup_kernel_start = etmq->etm->kernel_start -
+ ARM_PRE_START_SIZE;
+
+ if (address >= fixup_kernel_start) {
if (machine__is_host(machine))
return PERF_RECORD_MISC_KERNEL;
else
--
2.17.1
^ permalink raw reply related
* RE: [PATCH v2 2/5] objtool: Fix ORC unwinding in non-JIT BPF generated code
From: David Laight @ 2019-06-17 14:57 UTC (permalink / raw)
To: 'Alexei Starovoitov', Josh Poimboeuf
Cc: x86@kernel.org, Alexei Starovoitov, linux-kernel@vger.kernel.org,
Daniel Borkmann, netdev@vger.kernel.org, bpf@vger.kernel.org,
Peter Zijlstra, Song Liu, Kairui Song, Steven Rostedt,
Thomas Gleixner, Borislav Petkov, Ingo Molnar
In-Reply-To: <20190614205841.s4utbpurntpr6aiq@ast-mbp.dhcp.thefacebook.com>
From: Alexei Starovoitov
> Sent: 14 June 2019 21:59
>
> On Fri, Jun 14, 2019 at 12:56:41PM -0500, Josh Poimboeuf wrote:
> > Objtool currently ignores ___bpf_prog_run() because it doesn't
> > understand the jump table. This results in the ORC unwinder not being
> > able to unwind through non-JIT BPF code.
> >
> > Luckily, the BPF jump table resembles a GCC switch jump table, which
> > objtool already knows how to read.
> >
> > Add generic support for reading any static local jump table array named
> > "jump_table", and rename the BPF variable accordingly, so objtool can
> > generate ORC data for ___bpf_prog_run().
> >
> > Fixes: d15d356887e7 ("perf/x86: Make perf callchains work without CONFIG_FRAME_POINTER")
> > Reported-by: Song Liu <songliubraving@fb.com>
> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> > kernel/bpf/core.c | 5 ++---
> > tools/objtool/check.c | 16 ++++++++++++++--
> > 2 files changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 7c473f208a10..aa546ef7dbdc 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -1299,7 +1299,7 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack)
> > {
> > #define BPF_INSN_2_LBL(x, y) [BPF_##x | BPF_##y] = &&x##_##y
> > #define BPF_INSN_3_LBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] = &&x##_##y##_##z
> > - static const void *jumptable[256] = {
> > + static const void *jump_table[256] = {
> > [0 ... 255] = &&default_label,
> > /* Now overwrite non-defaults ... */
> > BPF_INSN_MAP(BPF_INSN_2_LBL, BPF_INSN_3_LBL),
> > @@ -1315,7 +1315,7 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack)
> > #define CONT_JMP ({ insn++; goto select_insn; })
> >
> > select_insn:
> > - goto *jumptable[insn->code];
> > + goto *jump_table[insn->code];
> >
> > /* ALU */
> > #define ALU(OPCODE, OP) \
> > @@ -1558,7 +1558,6 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack)
> > BUG_ON(1);
> > return 0;
> > }
> > -STACK_FRAME_NON_STANDARD(___bpf_prog_run); /* jump table */
> >
> > #define PROG_NAME(stack_size) __bpf_prog_run##stack_size
> > #define DEFINE_BPF_PROG_RUN(stack_size) \
> > diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> > index 172f99195726..8341c2fff14f 100644
> > --- a/tools/objtool/check.c
> > +++ b/tools/objtool/check.c
> > @@ -18,6 +18,8 @@
> >
> > #define FAKE_JUMP_OFFSET -1
> >
> > +#define JUMP_TABLE_SYM_PREFIX "jump_table."
>
> since external tool will be looking at it should it be named
> "bpf_jump_table." to avoid potential name conflicts?
> Or even more unique name?
> Like "bpf_interpreter_jump_table." ?
If external code might need to process such symbols then
jump_table_bpf_interpreter would (probably) make the symbols
easier to locate.
Oh, and blue is a good colour :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH RFC 0/6] DPAA2 MAC Driver
From: Andrew Lunn @ 2019-06-17 14:46 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Russell King - ARM Linux admin, hkallweit1@gmail.com,
f.fainelli@gmail.com, davem@davemloft.net, netdev@vger.kernel.org,
Alexandru Marginean, Ioana Ciocoi Radulescu
In-Reply-To: <VI1PR0402MB2800BBC003EA7C572FBEF09DE0EE0@VI1PR0402MB2800.eurprd04.prod.outlook.com>
On Fri, Jun 14, 2019 at 03:26:50PM +0000, Ioana Ciornei wrote:
> > Subject: Re: [PATCH RFC 0/6] DPAA2 MAC Driver
> >
> > On Fri, Jun 14, 2019 at 02:55:47AM +0300, Ioana Ciornei wrote:
> > > After today's discussion with Russell King about what phylink exposes
> > > in
> > > .mac_config(): https://marc.info/?l=linux-netdev&m=156043794316709&w=2
> > > I am submitting for initial review the dpaa2-mac driver model.
> > >
> > > At the moment, pause frame support is missing so inherently all the
> > > USXGMII modes that rely on backpressure applied by the PHY in rate
> > > adaptation between network side and system side don't work properly.
> > >
> > > As next steps, the driver will have to be integrated with the SFP bus
> > > so commands such as 'ethtool --dump-module-eeprom' will have to work
> > > through the current callpath through firmware.
> >
> > From what I understand having read the doc patch, would it be fair to say
> > that every operation that is related to the link state has to be passed from
> > the ETH driver to the firmware, and then from the firmware back to the
> > kernel to the MAC driver?
>
> That is correct.
>
> >
> > Does this mean that "ethtool --dump-module-eeprom" goes through this
> > process as well - eth driver into firmware, which then gets forwarded out of
> > the formware on the MAC side, via phylink to the SFP cage?
> >
> > If that is true, what is the proposal - to forward a copy of the EEPROM on
> > module insertion into the firmware, so that it is stored there when anyone
> > requests it? What about the diagnostic monitoring that is real-time?
> >
>
> At the moment, we do not have a proposal that could solve all these issues.
> We thought about a solution where the eth driver issues a command to the firmware that then issues an IRQ to the mac driver which could retrieve and then pass back the information.
> This doesn't seem too feasible since the ethernet driver should be waiting for the data to arrive back from the firmware while in an ethtool callback.
>
>
> > Or is the SFP cage entirely handled by firmware?
>
> No, the SFP cage is not handled by firmware.
Hi Ioana
At the moment, you seem to be in a bad middle ground. The firmware
cannot do everything, so you want Linux and PHYLINK to do some
bits. But Linux expects to do everything, have full control of the
hardware. And it is not fitting together.
Maybe you need to step back and look at the overall architecture. And
then decide which way you want to go to get out of the middle
ground. There are good examples of the firmware controlling
everything, and the driver just using the high level ethtool API calls
to report state. And there are good examples of low levels of the
hardware, the MDIO bus so Linux can control the PHYs, the i2c bus and
GPIOs for the SFP cage, etc being exposed so PHYLINK can control
everything.
To have a sensible architecture and driver implementation you need to
go one way or the other. All or nothing.
Andrew
^ permalink raw reply
* Re: general protection fault in sctp_sched_prio_sched
From: Marcelo Ricardo Leitner @ 2019-06-17 14:43 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, davem, linux-kernel, linux-sctp, lucien.xin, netdev,
nhorman, syzkaller-bugs, vyasevich
In-Reply-To: <20190617134913.GL3436@localhost.localdomain>
On Mon, Jun 17, 2019 at 10:49:13AM -0300, Marcelo Ricardo Leitner wrote:
> Hi,
>
> On Sun, Jun 16, 2019 at 11:38:03PM +0800, Hillf Danton wrote:
> >
> > Hello Syzbot
> >
> > On Sat, 15 Jun 2019 16:36:06 -0700 (PDT) syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> ...
> > Check prio_head and bail out if it is not valid.
> >
> > Thanks
> > Hillf
> > ----->8---
> > ---
> > net/sctp/stream_sched_prio.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/net/sctp/stream_sched_prio.c b/net/sctp/stream_sched_prio.c
> > index 2245083..db25a43 100644
> > --- a/net/sctp/stream_sched_prio.c
> > +++ b/net/sctp/stream_sched_prio.c
> > @@ -135,6 +135,8 @@ static void sctp_sched_prio_sched(struct sctp_stream *stream,
> > struct sctp_stream_priorities *prio, *prio_head;
> >
> > prio_head = soute->prio_head;
> > + if (!prio_head)
> > + return;
> >
> > /* Nothing to do if already scheduled */
> > if (!list_empty(&soute->prio_list))
> > --
>
> Thanks but this is not a good fix for this. It will cause the stream
> to never be scheduled.
>
> The problem happens because of the fault injection that happened a bit
> before the crash, in here:
>
> int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
> {
> struct sctp_stream_out_ext *soute;
>
> soute = kzalloc(sizeof(*soute), GFP_KERNEL);
> if (!soute)
> return -ENOMEM;
> SCTP_SO(stream, sid)->ext = soute; <---- [A]
>
> return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
> ^^^^^^^^^^^^---- [B] failed
> }
>
> This causes the 1st sendmsg to bail out with the error. When the 2nd
> one gets in, it will:
>
> sctp_sendmsg_to_asoc()
> {
> ...
> if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> ^^^^^--- [C]
> err = sctp_stream_init_ext(&asoc->stream, sinfo->sinfo_stream);
> if (err)
> goto err;
> }
>
> [A] leaves ext initialized, despite the failed in [B]. Then in [C], it
> will not try to initialize again.
>
> We need to either uninitialize ->ext as error handling for [B], or
> improve the check on [C].
The former one, please. This should be enough (untested):
diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index 93ed07877337..25946604af85 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -153,13 +153,20 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
{
struct sctp_stream_out_ext *soute;
+ int ret;
soute = kzalloc(sizeof(*soute), GFP_KERNEL);
if (!soute)
return -ENOMEM;
SCTP_SO(stream, sid)->ext = soute;
- return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
+ ret = sctp_sched_init_sid(stream, sid, GFP_KERNEL);
+ if (ret) {
+ kfree(SCTP_SO(stream, sid)->ext);
+ SCTP_SO(stream, sid)->ext = NULL;
+ }
+
+ return ret;
}
void sctp_stream_free(struct sctp_stream *stream)
^ permalink raw reply related
* Re: [PATCH net-next] vhost_net: disable zerocopy by default
From: Michael S. Tsirkin @ 2019-06-17 14:43 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel, huhai
In-Reply-To: <20190617092054.12299-1-jasowang@redhat.com>
On Mon, Jun 17, 2019 at 05:20:54AM -0400, Jason Wang wrote:
> Vhost_net was known to suffer from HOL[1] issues which is not easy to
> fix. Several downstream disable the feature by default. What's more,
> the datapath was split and datacopy path got the support of batching
> and XDP support recently which makes it faster than zerocopy part for
> small packets transmission.
>
> It looks to me that disable zerocopy by default is more
> appropriate. It cold be enabled by default again in the future if we
> fix the above issues.
>
> [1] https://patchwork.kernel.org/patch/3787671/
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/vhost/net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 2d9df786a9d3..21e0805e5e60 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -36,7 +36,7 @@
>
> #include "vhost.h"
>
> -static int experimental_zcopytx = 1;
> +static int experimental_zcopytx = 0;
> module_param(experimental_zcopytx, int, 0444);
> MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
> " 1 -Enable; 0 - Disable");
> --
> 2.18.1
^ permalink raw reply
* Re: [PATCH net-next v3] ipv4: Support multipath hashing on inner IP pkts for GRE tunnel
From: Ido Schimmel @ 2019-06-17 14:39 UTC (permalink / raw)
To: Stephen Suryaputra; +Cc: netdev, nikolay, dsahern
In-Reply-To: <20190613183858.9892-1-ssuryaextr@gmail.com>
On Thu, Jun 13, 2019 at 02:38:58PM -0400, Stephen Suryaputra wrote:
> Multipath hash policy value of 0 isn't distributing since the outer IP
> dest and src aren't varied eventhough the inner ones are. Since the flow
> is on the inner ones in the case of tunneled traffic, hashing on them is
> desired.
>
> This is done mainly for IP over GRE, hence only tested for that. But
> anything else supported by flow dissection should work.
>
> v2: Use skb_flow_dissect_flow_keys() directly so that other tunneling
> can be supported through flow dissection (per Nikolay Aleksandrov).
> v3: Remove accidental inclusion of ports in the hash keys and clarify
> the documentation (Nikolay Alexandrov).
> Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
Hi,
Do you plan to add IPv6 support? Would be good to have the same features
in both stacks.
Also, we have tests for these sysctls under
tools/testing/selftests/net/forwarding/router_multipath.sh
Can you add a test for this change as well? You'll probably need to
create a new file given the topology created by router_multipath.sh does
not include tunnels.
Thanks
^ permalink raw reply
* [PATCH] net: hns3: Add missing newline at end of file
From: Geert Uytterhoeven @ 2019-06-17 14:38 UTC (permalink / raw)
To: Yisen Zhuang, Salil Mehta, David S . Miller
Cc: netdev, linux-kernel, Geert Uytterhoeven
"git diff" says:
\ No newline at end of file
after modifying the file.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile b/drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile
index 6193f8fa7cf34aa1..53804d95ea900e03 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile
@@ -6,4 +6,4 @@
ccflags-y := -I $(srctree)/drivers/net/ethernet/hisilicon/hns3
obj-$(CONFIG_HNS3_HCLGEVF) += hclgevf.o
-hclgevf-objs = hclgevf_main.o hclgevf_cmd.o hclgevf_mbx.o
\ No newline at end of file
+hclgevf-objs = hclgevf_main.o hclgevf_cmd.o hclgevf_mbx.o
--
2.17.1
^ permalink raw reply related
* Re: [PATCH RFC 3/6] dpaa2-mac: add MC API for the DPMAC object
From: Andrew Lunn @ 2019-06-17 14:28 UTC (permalink / raw)
To: Ioana Ciornei
Cc: linux@armlinux.org.uk, hkallweit1@gmail.com, f.fainelli@gmail.com,
davem@davemloft.net, netdev@vger.kernel.org, Alexandru Marginean,
Ioana Ciocoi Radulescu
In-Reply-To: <VI1PR0402MB28002EE1DB0B3FB39B907052E0EE0@VI1PR0402MB2800.eurprd04.prod.outlook.com>
On Fri, Jun 14, 2019 at 02:06:05PM +0000, Ioana Ciornei wrote:
> > Subject: Re: [PATCH RFC 3/6] dpaa2-mac: add MC API for the DPMAC object
> >
> > > +/**
> > > + * dpmac_set_link_state() - Set the Ethernet link status
> > > + * @mc_io: Pointer to opaque I/O object
> > > + * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
> > > + * @token: Token of DPMAC object
> > > + * @link_state: Link state configuration
> > > + *
> > > + * Return: '0' on Success; Error code otherwise.
> > > + */
> > > +int dpmac_set_link_state(struct fsl_mc_io *mc_io,
> > > + u32 cmd_flags,
> > > + u16 token,
> > > + struct dpmac_link_state *link_state) {
> > > + struct dpmac_cmd_set_link_state *cmd_params;
> > > + struct fsl_mc_command cmd = { 0 };
> > > +
> > > + /* prepare command */
> > > + cmd.header =
> > mc_encode_cmd_header(DPMAC_CMDID_SET_LINK_STATE,
> > > + cmd_flags,
> > > + token);
> > > + cmd_params = (struct dpmac_cmd_set_link_state *)cmd.params;
> > > + cmd_params->options = cpu_to_le64(link_state->options);
> > > + cmd_params->rate = cpu_to_le32(link_state->rate);
> > > + dpmac_set_field(cmd_params->state, STATE, link_state->up);
> > > + dpmac_set_field(cmd_params->state, STATE_VALID,
> > > + link_state->state_valid);
> > > + cmd_params->supported = cpu_to_le64(link_state->supported);
> > > + cmd_params->advertising = cpu_to_le64(link_state->advertising);
> >
> > I don't understand what supported and advertising mean in the context of a
> > MAC. PHY yes, but MAC?
>
> It's still in the context of the PHY.
If this is for the PHY why are you not using DPNI? That is the object
which represents the PHY.
> As stated in the previous reply, the MAC can do pause, asym pause
> but not half duplex or EEE.
I'm very surprised it cannot do EEE! I hope the firmware is getting
the auto-neg advertisement correct.
Andrew
^ permalink raw reply
* Re: [PATCH v2 0/2] Add macb support for SiFive FU540-C000
From: Paul Walmsley @ 2019-06-17 14:20 UTC (permalink / raw)
To: Troy Benjegerdes
Cc: Andreas Schwab, Mark Rutland, devicetree, Albert Ou, netdev,
Palmer Dabbelt, Linux Kernel Mailing List, nicolas.ferre,
Sachin Ghadi, Yash Shah, robh+dt, ynezz, linux-riscv, davem,
Jim Jacobsen
In-Reply-To: <F48A4F7F-0B0D-4191-91AD-DC51686D1E78@sifive.com>
On Mon, 17 Jun 2019, Troy Benjegerdes wrote:
> Have we documented this tx clock switch register in something with a
> direct URL link (rather than a PDF)?
The SiFive FU540 user manual PDF is the canonical public reference:
https://static.dev.sifive.com/FU540-C000-v1.0.pdf
This practice aligns with other SoC vendors, who also release PDFs.
The relevant Ethernet documentation, including register maps, is in
Chapter 19.
- Paul
^ 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