* Re: [PATCH 04/15 net-next,v2] net: sched: add tcf_block_setup()
From: Jakub Kicinski @ 2019-07-05 22:58 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-5-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:32 +0200, Pablo Neira Ayuso wrote:
> @@ -1052,12 +1145,19 @@ static int tcf_block_offload_cmd(struct tcf_block *block,
> struct netlink_ext_ack *extack)
> {
> struct tc_block_offload bo = {};
> + int err;
>
> bo.command = command;
> bo.binder_type = ei->binder_type;
> bo.block = block;
> bo.extack = extack;
> - return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_BLOCK, &bo);
> + INIT_LIST_HEAD(&bo.cb_list);
> +
> + err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_BLOCK, &bo);
> + if (err < 0)
> + return err;
> +
> + return tcf_block_setup(block, &bo);
If this fails nothing will undo the old ndo call, no?
> }
>
> static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
^ permalink raw reply
* Re: [net-next, PATCH, v2] net: netsec: Sync dma for device on buffer allocation
From: David Miller @ 2019-07-05 22:45 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh, ard.biesheuvel, arnd
In-Reply-To: <1562251569-16506-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 4 Jul 2019 17:46:09 +0300
> Quoting Arnd,
>
> We have to do a sync_single_for_device /somewhere/ before the
> buffer is given to the device. On a non-cache-coherent machine with
> a write-back cache, there may be dirty cache lines that get written back
> after the device DMA's data into it (e.g. from a previous memset
> from before the buffer got freed), so you absolutely need to flush any
> dirty cache lines on it first.
>
> Since the coherency is configurable in this device make sure we cover
> all configurations by explicitly syncing the allocated buffer for the
> device before refilling it's descriptors
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
>
> Changes since V1:
> - Make the code more readable
Ooops, I applied v1. Could you please send me any changes still necessary
relative to that?
Thanks.
^ permalink raw reply
* Re: [PATCH 12/15 net-next,v2] net: flow_offload: make flow block callback list per-driver
From: Jakub Kicinski @ 2019-07-05 22:42 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-13-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:40 +0200, Pablo Neira Ayuso wrote:
> diff --git a/drivers/net/ethernet/netronome/nfp/abm/cls.c b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> index 96b89a7c468b..a42f92318b7a 100644
> --- a/drivers/net/ethernet/netronome/nfp/abm/cls.c
> +++ b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> @@ -262,9 +262,12 @@ static int nfp_abm_setup_tc_block_cb(enum tc_setup_type type,
> }
> }
>
> +static LIST_HEAD(nfp_abm_vf_block_cb_list);
s/_vf//
> int nfp_abm_setup_cls_block(struct net_device *netdev, struct nfp_repr *repr,
> struct flow_block_offload *f)
> {
> - return flow_block_setup_offload(f, nfp_abm_setup_tc_block_cb,
> + return flow_block_setup_offload(f, &nfp_abm_block_cb_list,
> + nfp_abm_setup_tc_block_cb,
> repr, repr, true);
> }
> diff --git a/drivers/net/ethernet/netronome/nfp/bpf/main.c b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> index 3897cc4f7a7e..5316d85261c0 100644
> --- a/drivers/net/ethernet/netronome/nfp/bpf/main.c
> +++ b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> @@ -160,6 +160,8 @@ static int nfp_bpf_setup_tc_block_cb(enum tc_setup_type type,
> return 0;
> }
>
> +static LIST_HEAD(nfp_bfp_block_cb_list);
s/bfp/bpf/
> static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
> enum tc_setup_type type, void *type_data)
> {
> @@ -168,6 +170,7 @@ static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
> switch (type) {
> case TC_SETUP_BLOCK:
> return flow_block_setup_offload(type_data,
> + &nfp_bfp_block_cb_list,
> nfp_bpf_setup_tc_block_cb,
> nn, nn, true);
> default:
^ permalink raw reply
* Re: [PATCH] net: netsec: Sync dma for device on buffer allocation
From: David Miller @ 2019-07-05 22:42 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh, ard.biesheuvel, arnd
In-Reply-To: <1562249469-14807-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 4 Jul 2019 17:11:09 +0300
> Quoting Arnd,
>
> We have to do a sync_single_for_device /somewhere/ before the
> buffer is given to the device. On a non-cache-coherent machine with
> a write-back cache, there may be dirty cache lines that get written back
> after the device DMA's data into it (e.g. from a previous memset
> from before the buffer got freed), so you absolutely need to flush any
> dirty cache lines on it first.
>
> Since the coherency is configurable in this device make sure we cover
> all configurations by explicitly syncing the allocated buffer for the
> device before refilling it's descriptors
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Please make it explicit in your Subject lines which tree a patch is
for, in this case it should have been "[PATCH net-next] ".
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: hns3: some cleanups & bugfixes
From: David Miller @ 2019-07-05 22:39 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1562249068-40176-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Thu, 4 Jul 2019 22:04:19 +0800
> This patch-set includes cleanups and bugfixes for
> the HNS3 ethernet controller driver.
>
> [patch 1/9] fixes VF's broadcast promisc mode not enabled after
> initializing.
>
> [patch 2/9] adds hints for fibre port not support flow control.
>
> [patch 3/9] fixes a port capbility updating issue.
>
> [patch 4/9 - 9/9] adds some cleanups for HNS3 driver.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] r8152: set RTL8152_UNPLUG only for real disconnection
From: David Miller @ 2019-07-05 22:38 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-288-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Thu, 4 Jul 2019 17:36:32 +0800
> Set the flag of RTL8152_UNPLUG if and only if the device is unplugged.
> Some error codes sometimes don't mean the real disconnection of usb device.
> For those situations, set the flag of RTL8152_UNPLUG causes the driver skips
> some flows of disabling the device, and it let the device stay at incorrect
> state.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH 04/15 net-next,v2] net: sched: add tcf_block_setup()
From: Jakub Kicinski @ 2019-07-05 22:31 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-5-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:32 +0200, Pablo Neira Ayuso wrote:
> +static int tcf_block_bind(struct tcf_block *block, struct tc_block_offload *bo)
> +{
> + struct tcf_block_cb *block_cb, *next;
> + int err, i = 0;
> +
> + list_for_each_entry(block_cb, &bo->cb_list, global_list) {
> + err = tcf_block_playback_offloads(block, block_cb->cb,
> + block_cb->cb_priv, true,
> + tcf_block_offload_in_use(block),
> + bo->extack);
> + if (err)
> + goto err_unroll;
> +
> + list_add(&block_cb->list, &block->cb_list);
> + i++;
> + }
> + list_splice(&bo->cb_list, &tcf_block_cb_list);
> +
> + return 0;
> +
> +err_unroll:
> + list_for_each_entry_safe(block_cb, next, &bo->cb_list, global_list) {
> + if (i-- > 0) {
> + list_del(&block_cb->list);
> + tcf_block_playback_offloads(block, block_cb->cb,
> + block_cb->cb_priv, false,
> + tcf_block_offload_in_use(block),
> + NULL);
> + }
> + kfree(block_cb);
Is this not a tcf_block_cb_free() on purpose?
> + }
> +
> + return err;
> +}
^ permalink raw reply
* Re: [PATCH][net-next] net: remove unused parameter from skb_checksum_try_convert
From: David Miller @ 2019-07-05 22:30 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1562231006-16341-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Thu, 4 Jul 2019 17:03:26 +0800
> the check parameter is never used
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/8] mlxsw: Enable/disable PTP shapers
From: David Miller @ 2019-07-05 22:29 UTC (permalink / raw)
To: idosch; +Cc: netdev, richardcochran, jiri, petrm, shalomt, mlxsw, idosch
In-Reply-To: <20190704070740.302-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 4 Jul 2019 10:07:32 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Shalom says:
>
> In order to get more accurate hardware time stamping in Spectrum-1, the
> driver needs to apply a shaper on the port for speeds lower than 40Gbps.
> This shaper is called a PTP shaper and it is applied on hierarchy 0,
> which is the port hierarchy. This shaper may affect the shaper rates of
> all hierarchies.
>
> This patchset adds the ability to enable or disable the PTP shaper on
> the port in two scenarios:
> 1. When the user wants to enable/disable the hardware time stamping
> 2. When the port is brought up or down (including port speed change)
>
> Patch #1 adds the QEEC.ptps field that is used for enabling or disabling
> the PTP shaper on a port.
>
> Patch #2 adds a note about disabling the PTP shaper when calling to
> mlxsw_sp_port_ets_maxrate_set().
>
> Patch #3 adds the QPSC register that is responsible for configuring the
> PTP shaper parameters per speed.
>
> Patch #4 sets the PTP shaper parameters during the ptp_init().
>
> Patch #5 adds new operation for getting the port's speed.
>
> Patch #6 enables/disables the PTP shaper when turning on or off the
> hardware time stamping.
>
> Patch #7 enables/disables the PTP shaper when the port's status has
> changed (including port speed change).
>
> Patch #8 applies the PTP shaper enable/disable logic by filling the PTP
> shaper parameters array.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: socionext: remove set but not used variable 'pkts'
From: David Miller @ 2019-07-05 22:28 UTC (permalink / raw)
To: yuehaibing
Cc: jaswinder.singh, ast, ilias.apalodimas, daniel, jakub.kicinski,
hawk, netdev, xdp-newbies, bpf, kernel-janitors
In-Reply-To: <20190704033745.1758-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 4 Jul 2019 03:37:45 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/socionext/netsec.c: In function 'netsec_clean_tx_dring':
> drivers/net/ethernet/socionext/netsec.c:637:15: warning:
> variable 'pkts' set but not used [-Wunused-but-set-variable]
>
> It is not used since commit ba2b232108d3 ("net: netsec: add XDP support")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net: ethernet: allwinner: Remove unneeded memset
From: David Miller @ 2019-07-05 22:26 UTC (permalink / raw)
To: hariprasad.kelam
Cc: maxime.ripard, wens, ynezz, f.fainelli, andrew, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190704025906.GA20005@hari-Inspiron-1545>
From: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Date: Thu, 4 Jul 2019 08:29:06 +0530
> Remove unneeded memset as alloc_etherdev is using kvzalloc which uses
> __GFP_ZERO flag
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Applied.
^ permalink raw reply
* Re: linux-next: Tree for Jun 28 (kernel/bpf/cgroup.c)
From: Randy Dunlap @ 2019-07-05 22:23 UTC (permalink / raw)
To: Stephen Rothwell, Linux Next Mailing List
Cc: Linux Kernel Mailing List, netdev@vger.kernel.org, Daniel Mack,
Daniel Borkmann, Song Liu, Yonghong Song, bpf, Martin KaFai Lau,
Alexei Starovoitov
In-Reply-To: <74534ab8-a397-ac4f-dd02-9b3618d7c4cd@infradead.org>
On 6/28/19 1:52 PM, Randy Dunlap wrote:
> On 6/28/19 3:38 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20190627:
>>
>
> on i386:
>
> ld: kernel/bpf/cgroup.o: in function `cg_sockopt_func_proto':
> cgroup.c:(.text+0x2906): undefined reference to `bpf_sk_storage_delete_proto'
> ld: cgroup.c:(.text+0x2939): undefined reference to `bpf_sk_storage_get_proto'
> ld: kernel/bpf/cgroup.o: in function `__cgroup_bpf_run_filter_setsockopt':
> cgroup.c:(.text+0x85e4): undefined reference to `lock_sock_nested'
> ld: cgroup.c:(.text+0x8af2): undefined reference to `release_sock'
> ld: kernel/bpf/cgroup.o: in function `__cgroup_bpf_run_filter_getsockopt':
> cgroup.c:(.text+0x8fd6): undefined reference to `lock_sock_nested'
> ld: cgroup.c:(.text+0x94e4): undefined reference to `release_sock'
>
>
> Full randconfig file is attached.
>
These build errors still happen in linux-next of 20190705...
--
~Randy
^ permalink raw reply
* Re: [Patch net 0/3] hsr: a few bug fixes
From: David Miller @ 2019-07-05 22:22 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, arvid.brodin
In-Reply-To: <20190704002114.29004-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 3 Jul 2019 17:21:11 -0700
> This patchset contains 3 bug fixes for hsr triggered by a syzbot
> reproducer, please check each patch for details.
>
> Cc: Arvid Brodin <arvid.brodin@alten.se>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: add test_tcp_rtt to .gitignore
From: Daniel Borkmann @ 2019-07-05 22:21 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, bpf; +Cc: davem, ast, Andrii Nakryiko
In-Reply-To: <20190703200952.159728-1-sdf@google.com>
On 07/03/2019 10:09 PM, Stanislav Fomichev wrote:
> Forgot to add it in the original patch.
>
> Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> Reported-by: Andrii Nakryiko <andriin@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: fix test_align liveliness expectations
From: Daniel Borkmann @ 2019-07-05 22:21 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, bpf; +Cc: davem, ast
In-Reply-To: <20190703212907.189141-1-sdf@google.com>
On 07/03/2019 11:29 PM, Stanislav Fomichev wrote:
> Commit 2589726d12a1 ("bpf: introduce bounded loops") caused a change
> in the way some registers liveliness is reported in the test_align.
> Add missing "_w" to a couple of tests. Note, there are no offset
> changes!
>
> Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipv4: Multipath hashing on inner L3 needs to consider inner IPv6 pkts
From: David Miller @ 2019-07-05 22:19 UTC (permalink / raw)
To: ssuryaextr; +Cc: netdev, idosch, nikolay, dsahern
In-Reply-To: <20190703151934.9567-2-ssuryaextr@gmail.com>
From: Stephen Suryaputra <ssuryaextr@gmail.com>
Date: Wed, 3 Jul 2019 11:19:32 -0400
> Commit 363887a2cdfe ("ipv4: Support multipath hashing on inner IP pkts
> for GRE tunnel") supports multipath policy value of 2, Layer 3 or inner
> Layer 3 if present, but it only considers inner IPv4. There is a use
> case of IPv6 over GRE over IPv4, thus add the ability to hash on inner
> IPv6 addresses.
>
> Fixes: 363887a2cdfe ("ipv4: Support multipath hashing on inner IP pkts for GRE tunnel")
> Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
The wording in this commit message is very confusing.
If you say "IPv6 over GRE over IPv4" then IPv6 is the outer protocol
type, not the inner one.
You need to clarify or reword this commit message so that it is
understandable and matches the logic.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: Jakub Kicinski @ 2019-07-05 22:10 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190705195213.22041-9-antoine.tenart@bootlin.com>
On Fri, 5 Jul 2019 21:52:13 +0200, Antoine Tenart wrote:
> This patch adds support for PTP Hardware Clock (PHC) to the Ocelot
> switch for both PTP 1-step and 2-step modes.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> @@ -596,11 +606,50 @@ static int ocelot_port_xmit(struct sk_buff *skb, struct net_device *dev)
>
> dev->stats.tx_packets++;
> dev->stats.tx_bytes += skb->len;
> - dev_kfree_skb_any(skb);
> +
> + if (ocelot->ptp && shinfo->tx_flags & SKBTX_HW_TSTAMP &&
> + port->ptp_cmd == IFH_REW_OP_TWO_STEP_PTP) {
> + struct ocelot_skb *oskb =
> + kzalloc(sizeof(struct ocelot_skb), GFP_KERNEL);
I think this is the TX path, you can't use GFP_KERNEL here.
> +
> + oskb->skb = skb;
> + oskb->id = port->ts_id % 4;
> + port->ts_id++;
> +
> + list_add_tail(&oskb->head, &port->skbs);
> + } else {
> + dev_kfree_skb_any(skb);
> + }
>
> return NETDEV_TX_OK;
> }
> +static int ocelot_hwstamp_set(struct ocelot_port *port, struct ifreq *ifr)
> +{
> + struct ocelot *ocelot = port->ocelot;
> + struct hwtstamp_config cfg;
> +
> + if (copy_from_user(&cfg, ifr->ifr_data, sizeof(cfg)))
> + return -EFAULT;
> +
> + /* reserved for future extensions */
> + if (cfg.flags)
> + return -EINVAL;
> +
> + /* Tx type sanity check */
> + switch (cfg.tx_type) {
> + case HWTSTAMP_TX_ON:
> + port->ptp_cmd = IFH_REW_OP_TWO_STEP_PTP;
> + break;
> + case HWTSTAMP_TX_ONESTEP_SYNC:
> + /* IFH_REW_OP_ONE_STEP_PTP updates the correctional field, we
> + * need to update the origin time.
> + */
> + port->ptp_cmd = IFH_REW_OP_ORIGIN_PTP;
> + break;
> + case HWTSTAMP_TX_OFF:
> + port->ptp_cmd = 0;
> + break;
> + default:
> + return -ERANGE;
> + }
> +
> + mutex_lock(&ocelot->ptp_lock);
> +
> + switch (cfg.rx_filter) {
> + case HWTSTAMP_FILTER_NONE:
> + break;
> + case HWTSTAMP_FILTER_ALL:
> + case HWTSTAMP_FILTER_SOME:
> + case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
> + case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
> + case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
> + case HWTSTAMP_FILTER_NTP_ALL:
> + case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
> + case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
> + case HWTSTAMP_FILTER_PTP_V2_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
> + cfg.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
> + break;
> + default:
> + mutex_unlock(&ocelot->ptp_lock);
> + return -ERANGE;
> + }
No device reconfig, so the PTP RX stamping is always enabled? Perhaps
consider setting
ocelot->hwtstamp_config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT
at probe?
> + /* Commit back the result & save it */
> + memcpy(&ocelot->hwtstamp_config, &cfg, sizeof(cfg));
> + mutex_unlock(&ocelot->ptp_lock);
> +
> + return copy_to_user(ifr->ifr_data, &cfg, sizeof(cfg)) ? -EFAULT : 0;
> +}
> +
> +static int ocelot_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> +{
> + struct ocelot_port *port = netdev_priv(dev);
> + struct ocelot *ocelot = port->ocelot;
> +
> + /* The function is only used for PTP operations for now */
> + if (!ocelot->ptp)
> + return -EOPNOTSUPP;
> +
> + switch (cmd) {
> + case SIOCSHWTSTAMP:
> + return ocelot_hwstamp_set(port, ifr);
> + case SIOCGHWTSTAMP:
> + return ocelot_hwstamp_get(port, ifr);
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> static const struct net_device_ops ocelot_port_netdev_ops = {
> .ndo_open = ocelot_port_open,
> .ndo_stop = ocelot_port_stop,
> @@ -933,6 +1073,7 @@ static const struct net_device_ops ocelot_port_netdev_ops = {
> .ndo_set_features = ocelot_set_features,
> .ndo_get_port_parent_id = ocelot_get_port_parent_id,
> .ndo_setup_tc = ocelot_setup_tc,
> + .ndo_do_ioctl = ocelot_ioctl,
> };
>
> static void ocelot_get_strings(struct net_device *netdev, u32 sset, u8 *data)
> @@ -1014,12 +1155,42 @@ static int ocelot_get_sset_count(struct net_device *dev, int sset)
> return ocelot->num_stats;
> }
>
> +static int ocelot_get_ts_info(struct net_device *dev,
> + struct ethtool_ts_info *info)
> +{
> + struct ocelot_port *ocelot_port = netdev_priv(dev);
> + struct ocelot *ocelot = ocelot_port->ocelot;
> + int ret;
> +
> + if (!ocelot->ptp)
> + return -EOPNOTSUPP;
Hmm.. why does software timestamping depend on PTP?
> + ret = ethtool_op_get_ts_info(dev, info);
> + if (ret)
> + return ret;
> +
> + info->phc_index = ocelot->ptp_clock ?
> + ptp_clock_index(ocelot->ptp_clock) : -1;
> + info->so_timestamping |= SOF_TIMESTAMPING_TX_SOFTWARE |
> + SOF_TIMESTAMPING_RX_SOFTWARE |
> + SOF_TIMESTAMPING_SOFTWARE |
> + SOF_TIMESTAMPING_TX_HARDWARE |
> + SOF_TIMESTAMPING_RX_HARDWARE |
> + SOF_TIMESTAMPING_RAW_HARDWARE;
> + info->tx_types = BIT(HWTSTAMP_TX_OFF) | BIT(HWTSTAMP_TX_ON) |
> + BIT(HWTSTAMP_TX_ONESTEP_SYNC);
> + info->rx_filters = BIT(HWTSTAMP_FILTER_NONE) | BIT(HWTSTAMP_FILTER_ALL);
> +
> + return 0;
> +}
> +
> static const struct ethtool_ops ocelot_ethtool_ops = {
> .get_strings = ocelot_get_strings,
> .get_ethtool_stats = ocelot_get_ethtool_stats,
> .get_sset_count = ocelot_get_sset_count,
> .get_link_ksettings = phy_ethtool_get_link_ksettings,
> .set_link_ksettings = phy_ethtool_set_link_ksettings,
> + .get_ts_info = ocelot_get_ts_info,
> };
>
> static int ocelot_port_attr_stp_state_set(struct ocelot_port *ocelot_port,
^ permalink raw reply
* Re: [PATCH bpf-next 3/3] xdp: Add devmap_hash map type for looking up devices by hashed index
From: Y Song @ 2019-07-05 22:04 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, David Miller,
Jesper Dangaard Brouer, Jakub Kicinski, Björn Töpel
In-Reply-To: <156234940855.2378.3580468359411972045.stgit@alrua-x1>
On Fri, Jul 5, 2019 at 11:14 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> From: Toke Høiland-Jørgensen <toke@redhat.com>
>
> A common pattern when using xdp_redirect_map() is to create a device map
> where the lookup key is simply ifindex. Because device maps are arrays,
> this leaves holes in the map, and the map has to be sized to fit the
> largest ifindex, regardless of how many devices actually are actually
> needed in the map.
>
> This patch adds a second type of device map where the key is looked up
> using a hashmap, instead of being used as an array index. This allows maps
> to be densely packed, so they can be smaller.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
> include/linux/bpf.h | 7 +
> include/linux/bpf_types.h | 1
> include/trace/events/xdp.h | 3
> include/uapi/linux/bpf.h | 7 +
> kernel/bpf/devmap.c | 192 +++++++++++++++++++++++++++++++
> kernel/bpf/verifier.c | 2
> net/core/filter.c | 9 +
> tools/bpf/bpftool/map.c | 1
> tools/include/uapi/linux/bpf.h | 7 +
> tools/lib/bpf/libbpf_probes.c | 1
> tools/testing/selftests/bpf/test_maps.c | 16 +++
> 11 files changed, 237 insertions(+), 9 deletions(-)
Could you break this patch into multiple commits for easy backporting
and easy syncing to libbpf repo?
For example, you can break it into 4 patches:
. kernel patch
. sync uapi bpf.h
. tools/lib/bpf/libbpf_probes.c
. other tools changes.
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index bfdb54dd2ad1..f9a506147c8a 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -713,6 +713,7 @@ struct xdp_buff;
> struct sk_buff;
>
> struct bpf_dtab_netdev *__dev_map_lookup_elem(struct bpf_map *map, u32 key);
> +struct bpf_dtab_netdev *__dev_map_hash_lookup_elem(struct bpf_map *map, u32 key);
> void __dev_map_flush(struct bpf_map *map);
> int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
> struct net_device *dev_rx);
> @@ -799,6 +800,12 @@ static inline struct net_device *__dev_map_lookup_elem(struct bpf_map *map,
> return NULL;
> }
>
> +static inline struct net_device *__dev_map_hash_lookup_elem(struct bpf_map *map,
> + u32 key)
> +{
> + return NULL;
> +}
> +
> static inline void __dev_map_flush(struct bpf_map *map)
> {
> }
> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> index eec5aeeeaf92..36a9c2325176 100644
> --- a/include/linux/bpf_types.h
> +++ b/include/linux/bpf_types.h
> @@ -62,6 +62,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY_OF_MAPS, array_of_maps_map_ops)
> BPF_MAP_TYPE(BPF_MAP_TYPE_HASH_OF_MAPS, htab_of_maps_map_ops)
> #ifdef CONFIG_NET
> BPF_MAP_TYPE(BPF_MAP_TYPE_DEVMAP, dev_map_ops)
> +BPF_MAP_TYPE(BPF_MAP_TYPE_DEVMAP_HASH, dev_map_hash_ops)
> BPF_MAP_TYPE(BPF_MAP_TYPE_SK_STORAGE, sk_storage_map_ops)
> #if defined(CONFIG_BPF_STREAM_PARSER)
> BPF_MAP_TYPE(BPF_MAP_TYPE_SOCKMAP, sock_map_ops)
[...]
^ permalink raw reply
* Re: [PATCH net-next v2 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: Richard Cochran @ 2019-07-05 22:02 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, alexandre.belloni, UNGLinuxDriver, ralf, paul.burton,
jhogan, netdev, linux-mips, thomas.petazzoni, allan.nielsen
In-Reply-To: <20190705195213.22041-9-antoine.tenart@bootlin.com>
On Fri, Jul 05, 2019 at 09:52:13PM +0200, Antoine Tenart wrote:
> +static irqreturn_t ocelot_ptp_rdy_irq_handler(int irq, void *arg)
> +{
> + struct ocelot *ocelot = arg;
> +
> + do {
> + /* Check if a timestamp can be retrieved */
> + if (!(val & SYS_PTP_STATUS_PTP_MESS_VLD))
> + break;
As in my reply on v1, I suggest adding a sanity check on this ISR's
infinite loop.
> + } while (true);
> +
> + return IRQ_HANDLED;
> +}
Thanks,
Richard
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2019-07-05
From: David Miller @ 2019-07-05 22:01 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20190705084610.3646-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 5 Jul 2019 10:46:01 +0200
> 1) A lot of work to remove indirections from the xfrm code.
> From Florian Westphal.
>
> 2) Fix a WARN_ON with ipv6 that triggered because of a
> forgotten break statement. From Florian Westphal.
>
> 3) Remove xfrmi_init_net, it is not needed.
> From Li RongQing.
>
> Please pull or let me know if there are problems.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next] Enable zext optimization for more RV64G ALU ops
From: Daniel Borkmann @ 2019-07-05 22:01 UTC (permalink / raw)
To: Luke Nelson, linux-kernel
Cc: Luke Nelson, Song Liu, Jiong Wang, Xi Wang, Björn Töpel,
Palmer Dabbelt, Albert Ou, Alexei Starovoitov, Martin KaFai Lau,
Song Liu, Yonghong Song, netdev, linux-riscv, bpf
In-Reply-To: <20190705001803.30094-1-luke.r.nels@gmail.com>
On 07/05/2019 02:18 AM, Luke Nelson wrote:
> commit 66d0d5a854a6 ("riscv: bpf: eliminate zero extension code-gen")
> added the new zero-extension optimization for some BPF ALU operations.
>
> Since then, bugs in the JIT that have been fixed in the bpf tree require
> this optimization to be added to other operations: commit 1e692f09e091
> ("bpf, riscv: clear high 32 bits for ALU32 add/sub/neg/lsh/rsh/arsh"),
> and commit fe121ee531d1 ("bpf, riscv: clear target register high 32-bits
> for and/or/xor on ALU32")
>
> Now that these have been merged to bpf-next, the zext optimization can
> be enabled for the fixed operations.
>
> Cc: Song Liu <liu.song.a23@gmail.com>
> Cc: Jiong Wang <jiong.wang@netronome.com>
> Cc: Xi Wang <xi.wang@gmail.com>
> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCHv2] tools bpftool: Fix json dump crash on powerpc
From: Daniel Borkmann @ 2019-07-05 22:00 UTC (permalink / raw)
To: Quentin Monnet, Jakub Kicinski, Jiri Olsa
Cc: Jiri Olsa, Alexei Starovoitov, Michael Petlan, netdev, bpf,
Martin KaFai Lau
In-Reply-To: <83d18af0-8efa-c8d5-3d99-01aed29915df@netronome.com>
On 07/05/2019 07:26 PM, Quentin Monnet wrote:
> 2019-07-05 10:24 UTC-0700 ~ Jakub Kicinski <jakub.kicinski@netronome.com>
>> On Fri, 5 Jul 2019 14:10:31 +0200, Jiri Olsa wrote:
>>> Michael reported crash with by bpf program in json mode on powerpc:
>>>
>>> # bpftool prog -p dump jited id 14
>>> [{
>>> "name": "0xd00000000a9aa760",
>>> "insns": [{
>>> "pc": "0x0",
>>> "operation": "nop",
>>> "operands": [null
>>> ]
>>> },{
>>> "pc": "0x4",
>>> "operation": "nop",
>>> "operands": [null
>>> ]
>>> },{
>>> "pc": "0x8",
>>> "operation": "mflr",
>>> Segmentation fault (core dumped)
>>>
>>> The code is assuming char pointers in format, which is not always
>>> true at least for powerpc. Fixing this by dumping the whole string
>>> into buffer based on its format.
>>>
>>> Please note that libopcodes code does not check return values from
>>> fprintf callback, but as per Jakub suggestion returning -1 on allocation
>>> failure so we do the best effort to propagate the error.
>>>
>>> Reported-by: Michael Petlan <mpetlan@redhat.com>
>>> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
>>
>> Thanks, let me repost all the tags (Quentin, please shout if you're
>> not ok with this :)):
>
> I confirm it's all good for me, thanks :)
>
>> Fixes: 107f041212c1 ("tools: bpftool: add JSON output for `bpftool prog dump jited *` command")
>> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
>> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Given merge window coming up, I've applied this to bpf-next, thanks everyone!
P.s.: Jiri, please repost full/proper patch next time instead of inline reply.
^ permalink raw reply
* Re: [PATCH bpf-next v2] tools: bpftool: add "prog run" subcommand to test-run programs
From: Daniel Borkmann @ 2019-07-05 21:58 UTC (permalink / raw)
To: Quentin Monnet, Alexei Starovoitov
Cc: bpf, netdev, oss-drivers, Yonghong Song
In-Reply-To: <20190705175433.22511-1-quentin.monnet@netronome.com>
On 07/05/2019 07:54 PM, Quentin Monnet wrote:
> Add a new "bpftool prog run" subcommand to run a loaded program on input
> data (and possibly with input context) passed by the user.
>
> Print output data (and output context if relevant) into a file or into
> the console. Print return value and duration for the test run into the
> console.
>
> A "repeat" argument can be passed to run the program several times in a
> row.
>
> The command does not perform any kind of verification based on program
> type (Is this program type allowed to use an input context?) or on data
> consistency (Can I work with empty input data?), this is left to the
> kernel.
>
> Example invocation:
>
> # perl -e 'print "\x0" x 14' | ./bpftool prog run \
> pinned /sys/fs/bpf/sample_ret0 \
> data_in - data_out - repeat 5
> 0000000 0000 0000 0000 0000 0000 0000 0000 | ........ ......
> Return value: 0, duration (average): 260ns
>
> When one of data_in or ctx_in is "-", bpftool reads from standard input,
> in binary format. Other formats (JSON, hexdump) might be supported (via
> an optional command line keyword like "data_fmt_in") in the future if
> relevant, but this would require doing more parsing in bpftool.
>
> v2:
> - Fix argument names for function check_single_stdin(). (Yonghong)
>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Looks great, thanks for adding, applied!
^ permalink raw reply
* Re: [PATCH net-next 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: Richard Cochran @ 2019-07-05 21:58 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, alexandre.belloni, UNGLinuxDriver, ralf, paul.burton,
jhogan, netdev, linux-mips, thomas.petazzoni, allan.nielsen
In-Reply-To: <20190701100327.6425-9-antoine.tenart@bootlin.com>
On Mon, Jul 01, 2019 at 12:03:27PM +0200, Antoine Tenart wrote:
> +static irqreturn_t ocelot_ptp_rdy_irq_handler(int irq, void *arg)
> +{
> + struct ocelot *ocelot = arg;
> +
> + do {
> + struct skb_shared_hwtstamps shhwtstamps;
> + struct list_head *pos, *tmp;
> + struct ocelot_skb *entry;
> + struct ocelot_port *port;
> + struct timespec64 ts;
> + struct sk_buff *skb = NULL;
> + u32 val, id, txport;
> +
> + val = ocelot_read(ocelot, SYS_PTP_STATUS);
> +
> + /* Check if a timestamp can be retrieved */
> + if (!(val & SYS_PTP_STATUS_PTP_MESS_VLD))
> + break;
Instead of an infinite do/while loop, I suggest a for loop bounded by
number of iterations or by execution time. That would avoid getting
stuck here forever. After all, this code is an ISR.
Thanks,
Richard
> + WARN_ON(val & SYS_PTP_STATUS_PTP_OVFL);
> +
> + /* Retrieve the ts ID and Tx port */
> + id = SYS_PTP_STATUS_PTP_MESS_ID_X(val);
> + txport = SYS_PTP_STATUS_PTP_MESS_TXPORT_X(val);
> +
> + /* Retrieve its associated skb */
> + port = ocelot->ports[txport];
> +
> + list_for_each_safe(pos, tmp, &port->skbs) {
> + entry = list_entry(pos, struct ocelot_skb, head);
> + if (entry->id != id)
> + continue;
> +
> + skb = entry->skb;
> +
> + list_del(pos);
> + kfree(entry);
> + }
> +
> + /* Next ts */
> + ocelot_write(ocelot, SYS_PTP_NXT_PTP_NXT, SYS_PTP_NXT);
> +
> + if (unlikely(!skb))
> + continue;
> +
> + /* Get the h/w timestamp */
> + ocelot_get_hwtimestamp(ocelot, &ts);
> +
> + /* Set the timestamp into the skb */
> + memset(&shhwtstamps, 0, sizeof(shhwtstamps));
> + shhwtstamps.hwtstamp = ktime_set(ts.tv_sec, ts.tv_nsec);
> + skb_tstamp_tx(skb, &shhwtstamps);
> +
> + dev_kfree_skb_any(skb);
> + } while (true);
> +
> + return IRQ_HANDLED;
> +}
^ permalink raw reply
* Re: pull request (net): ipsec 2019-07-05
From: David Miller @ 2019-07-05 21:58 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20190705082700.31107-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 5 Jul 2019 10:26:53 +0200
> 1) Fix xfrm selector prefix length validation for
> inter address family tunneling.
> From Anirudh Gupta.
>
> 2) Fix a memleak in pfkey.
> From Jeremy Sowden.
>
> 3) Fix SA selector validation to allow empty selectors again.
> From Nicolas Dichtel.
>
> 4) Select crypto ciphers for xfrm_algo, this fixes some
> randconfig builds. From Arnd Bergmann.
>
> 5) Remove a duplicated assignment in xfrm_bydst_resize.
> From Cong Wang.
>
> 6) Fix a hlist corruption on hash rebuild.
> From Florian Westphal.
>
> 7) Fix a memory leak when creating xfrm interfaces.
> From Nicolas Dichtel.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ 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