* Re: [RFC PATCH mlx5-next 02/18] net/mlx5: Export modify header alloc/dealloc functions
From: Or Gerlitz @ 2018-07-16 21:27 UTC (permalink / raw)
To: Mark Bloch
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180716082305.11744-3-leon@kernel.org>
On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Mark Bloch <markb@mellanox.com>
>
> Those function will be used by the RDMA side to create modify header
function --> functions
> actions to be attached to flow steering rules via verbs.
^ permalink raw reply
* Re: [RFC PATCH mlx5-next 04/18] net/mlx5: Break encap/decap into two separated flags
From: Or Gerlitz @ 2018-07-16 21:28 UTC (permalink / raw)
To: Mark Bloch
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180716082305.11744-5-leon@kernel.org>
On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Mark Bloch <markb@mellanox.com>
>
> Today we are able to attach encap and decap actions only to the FDB.
> In preparation to enable those actions on the NIC flow tables break
tables break --> tables, break
> the single flag into two.
^ permalink raw reply
* Re: [RFC PATCH mlx5-next 07/18] net/mlx5: Expose new packet reformat capabilities
From: Or Gerlitz @ 2018-07-16 21:33 UTC (permalink / raw)
To: Mark Bloch
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180716082305.11744-8-leon@kernel.org>
On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Mark Bloch <markb@mellanox.com>
>
> Expose new abilities when creating a packet reformat context.
>
> The new types which can be created are:
> MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL: Ability to create generic encap
> opertion to be done by the HW.
opertion -> fix
> MLX5_REFORMAT_TYPE_L3_TUNNEL_TO_L2: Ability to create generic decap
> opertion where the inner packet doesn't contain L2.
opertion -> fix
>
> MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL: Ability to create generic encap
> opertion to be done by the HW. The L2 of the original packet
opertion -> fix
> is dropped.
>
> Signed-off-by: Mark Bloch <markb@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> include/linux/mlx5/mlx5_ifc.h | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
> index 059ec97e7b32..c71d711d4893 100644
> --- a/include/linux/mlx5/mlx5_ifc.h
> +++ b/include/linux/mlx5/mlx5_ifc.h
> @@ -341,8 +341,13 @@ struct mlx5_ifc_flow_table_prop_layout_bits {
> u8 reserved_at_9[0x1];
> u8 pop_vlan[0x1];
> u8 push_vlan[0x1];
> - u8 reserved_at_c[0x14];
> -
> + u8 reserved_at_c[0x3];
> + u8 reformat_and_vlan_action[0x1];
unused in downstream patches
what is this BTW?
> + u8 reserved_at_10[0x2];
> + u8 reformat_l3_tunnel_to_l2[0x1];
> + u8 reformat_l2_to_l3_tunnel[0x1];
> + u8 reformat_and_modify_action[0x1];
unused in downstream patches
what is this BTW?
> + u8 reserved_at_15[0xb];
> u8 reserved_at_20[0x2];
> u8 log_max_ft_size[0x6];
> u8 log_max_modify_header_context[0x8];
> @@ -551,7 +556,13 @@ struct mlx5_ifc_flow_table_nic_cap_bits {
> u8 nic_rx_multi_path_tirs[0x1];
> u8 nic_rx_multi_path_tirs_fts[0x1];
> u8 allow_sniffer_and_nic_rx_shared_tir[0x1];
> - u8 reserved_at_3[0x1fd];
> + u8 reserved_at_3[0x1d];
> + u8 encap_general_header[0x1];
> + u8 reserved_at_21[0xa];
> + u8 log_max_packet_reformat_context[0x5];
> + u8 reserved_at_30[0x6];
> + u8 max_encap_header_size[0xa];
> + u8 reserved_at_40[0x1c0];
we are inconsistent, for some fields the term "encap" remained wheres
for other fields we moved to use "reformat" or "packet reformat" etc
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Fix error recovery on login failure
From: David Miller @ 2018-07-16 21:40 UTC (permalink / raw)
To: jallen; +Cc: tlfalcon, netdev, jallen
In-Reply-To: <20180716152930.22255-1-jallen@linux.ibm.com>
From: John Allen <jallen@linux.ibm.com>
Date: Mon, 16 Jul 2018 10:29:30 -0500
> Testing has uncovered a failure case that is not handled properly. In the
> event that a login fails and we are not able to recover on the spot, we
> return 0 from do_reset, preventing any error recovery code from being
> triggered. Additionally, the state is set to "probed" meaning that when we
> are able to trigger the error recovery, the driver always comes up in the
> probed state. To handle the case properly, we need to return a failure code
> here and set the adapter state to the state that we entered the reset in
> indicating the state that we would like to come out of the recovery reset
> in.
>
> Signed-off-by: John Allen <jallen@linux.vnet.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] tg3: Update copyright and fix for tx timeout with 5762
From: David Miller @ 2018-07-16 21:42 UTC (permalink / raw)
To: siva.kallam
Cc: netdev, michael.chan, prashant.sreedharan, sanjeevb.bansal,
siva.kallam
In-Reply-To: <20180716054332.82009-1-siva.kallam@broadom.com>
From: Siva Reddy Kallam <siva.kallam@broadom.com>
Date: Mon, 16 Jul 2018 11:13:30 +0530
> From: Siva Reddy Kallam <siva.kallam@broadcom.com>
>
> First patch:
> Update copyright
>
> Second patch:
> Add higher cpu clock for 5762
Series applied, thank you.
^ permalink raw reply
* RE: [RFC PATCH rdma-next 13/18] RDMA/mlx5: Enable decap and packet reformat on flow tables
From: Mark Bloch @ 2018-07-16 21:46 UTC (permalink / raw)
To: Or Gerlitz
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMiLrSZMqZTSySB+PwUsXoHfh99QJZ+_WdQQn4sgA2HYNQ@mail.gmail.com>
> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Monday, July 16, 2018 2:24 PM
> To: Mark Bloch <markb@mellanox.com>
> Cc: Doug Ledford <dledford@redhat.com>; Jason Gunthorpe
> <jgg@mellanox.com>; Leon Romanovsky <leonro@mellanox.com>; RDMA
> mailing list <linux-rdma@vger.kernel.org>; Saeed Mahameed
> <saeedm@mellanox.com>; linux-netdev <netdev@vger.kernel.org>
> Subject: Re: [RFC PATCH rdma-next 13/18] RDMA/mlx5: Enable decap and
> packet reformat on flow tables
>
> On Mon, Jul 16, 2018 at 11:23 AM, Leon Romanovsky <leon@kernel.org>
> wrote:
> > From: Mark Bloch <markb@mellanox.com>
> >
> > If NIC RX flow tables support decap opertion, enable it on creation.
>
> opertion --> operation
>
> > If NIC TX flow tables support reformat opertion, enable it on creation.
>
> What is the trigger to use the decap flag on RX table or encap flag on
> TX table?
>
It has no performance penalty to always enable that, so that's what I do if supported.
> Please note that we have a short blanket w.r.t mutual usage by
FDB and NIC steering tables have different limitations, so encap/decap on NIC steering
have nothing to do with the limitations the FDB has with those operations.
> NIC vs e-Switch steering, did you consider to do that on demand?
The flow table needs to be created with those flags set if we want to attach
decap/packet reformat action to it. BTW, there is no modify action for those bits
so that's why I'm doing it on creation.
Mark
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: collect ASIC LA dumps from ULP TX
From: David Miller @ 2018-07-16 21:46 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, surendra, ganeshgr, nirranjan, indranil
In-Reply-To: <1531750254-22390-1-git-send-email-rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Mon, 16 Jul 2018 19:40:54 +0530
> From: Surendra Mobiya <surendra@chelsio.com>
>
> Signed-off-by: Surendra Mobiya <surendra@chelsio.com>
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] sch_cake: Fix tin order when set through skb->priority
From: David Miller @ 2018-07-16 21:48 UTC (permalink / raw)
To: toke; +Cc: netdev, cake
In-Reply-To: <20180716144509.31121-1-toke@toke.dk>
From: Toke Høiland-Jørgensen <toke@toke.dk>
Date: Mon, 16 Jul 2018 16:45:09 +0200
> In diffserv mode, CAKE stores tins in a different order internally than
> the logical order exposed to userspace. The order remapping was missing
> in the handling of 'tc filter' priority mappings through skb->priority,
> resulting in bulk and best effort mappings being reversed relative to
> how they are displayed.
>
> Fix this by adding the missing mapping when reading skb->priority.
>
> Fixes: 83f8fd69af4f ("sch_cake: Add DiffServ handling")
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] datagram: return from __skb_recv_datagram() as soon as possible
From: Willem de Bruijn @ 2018-07-16 22:17 UTC (permalink / raw)
To: baoyou.xie
Cc: David Miller, Willem de Bruijn, Al Viro, Greg Kroah-Hartman,
pombredanne, Tobias Klauser, Matthew Dawson, Network Development,
LKML
In-Reply-To: <1531653191-6456-1-git-send-email-baoyou.xie@gmail.com>
On Sun, Jul 15, 2018 at 4:17 AM Baoyou Xie <baoyou.xie@gmail.com> wrote:
>
> We got a soft lockup in a heavy busy cloud server where RIP is
> at _raw_spin_unlock_irqrestore+0x1b/0x40:
> [] finish_wait+0x56/0x70
> [] __skb_recv_datagram+0x3fb/0x5a0
> [] ? datagram_poll+0x100/0x100
> [] skb_recv_datagram+0x41/0x60
> [] netlink_recvmsg+0x62/0x450
> [] sock_recvmsg+0xbf/0x100
> [] ? futex_wait+0x193/0x280
> [] ? finish_task_switch+0x108/0x170
> [] SYSC_recvfrom+0xe8/0x160
> [] ? __schedule+0x3c8/0x990
> [] SyS_recvfrom+0xe/0x10
> [] system_call_fastpath+0x16/0x1b
>
> In fact, a mistake exists in __skb_recv_datagram(). For example,
> if a datagram come in persistently after go through the socket
> queue, then __skb_wait_for_more_packets() will find out that the
> last peeked skb is not the real last one, so it return 0. this
> results in long time outer loop, and can trigger soft lockup.
Is this with MSG_PEEK?
If the above occurs, that implies that the queue is not empty so the
next iteration of the loop in __skb_recv_datagram should return
the oldest packet on the queue.
This is a netlink socket. Those do not support SO_PEEK_OFF,
simplifying the problem somewhat.
I do not yet see how this can loop until timeout if data is queued.
> So this patch changes the loop condition to prevent soft lockup.
Bounding waiting time in this manner should not be needed, as
__skb_wait_for_more_packets reduces remaining timeo on wake.
^ permalink raw reply
* RE: [RFC PATCH mlx5-next 07/18] net/mlx5: Expose new packet reformat capabilities
From: Mark Bloch @ 2018-07-16 21:57 UTC (permalink / raw)
To: Or Gerlitz
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMgGaptnS+Bgd4QTEq=P7x52p9mUHgiGMX4-f3Bq3cMzhg@mail.gmail.com>
> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Monday, July 16, 2018 2:33 PM
> To: Mark Bloch <markb@mellanox.com>
> Cc: Doug Ledford <dledford@redhat.com>; Jason Gunthorpe
> <jgg@mellanox.com>; Leon Romanovsky <leonro@mellanox.com>; RDMA
> mailing list <linux-rdma@vger.kernel.org>; Saeed Mahameed
> <saeedm@mellanox.com>; linux-netdev <netdev@vger.kernel.org>
> Subject: Re: [RFC PATCH mlx5-next 07/18] net/mlx5: Expose new packet
> reformat capabilities
>
> On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky <leon@kernel.org>
> wrote:
> > From: Mark Bloch <markb@mellanox.com>
> >
> > Expose new abilities when creating a packet reformat context.
> >
> > The new types which can be created are:
> > MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL: Ability to create generic
> encap
> > opertion to be done by the HW.
>
> opertion -> fix
>
> > MLX5_REFORMAT_TYPE_L3_TUNNEL_TO_L2: Ability to create generic
> decap
> > opertion where the inner packet doesn't contain L2.
>
> opertion -> fix
>
> >
> > MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL: Ability to create generic
> encap
> > opertion to be done by the HW. The L2 of the original packet
>
> opertion -> fix
Thx, will be fixed.
>
> > is dropped.
> >
> > Signed-off-by: Mark Bloch <markb@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > include/linux/mlx5/mlx5_ifc.h | 20 +++++++++++++++++---
> > 1 file changed, 17 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
> > index 059ec97e7b32..c71d711d4893 100644
> > --- a/include/linux/mlx5/mlx5_ifc.h
> > +++ b/include/linux/mlx5/mlx5_ifc.h
> > @@ -341,8 +341,13 @@ struct mlx5_ifc_flow_table_prop_layout_bits {
> > u8 reserved_at_9[0x1];
> > u8 pop_vlan[0x1];
> > u8 push_vlan[0x1];
> > - u8 reserved_at_c[0x14];
> > -
> > + u8 reserved_at_c[0x3];
> > + u8 reformat_and_vlan_action[0x1];
>
> unused in downstream patches
> what is this BTW?
It's needed for competence for all the bits that deal with packet reformat.
The bit itself indicates whatever the flow table supports
reformat action with a vlan action (pop/push) in the same rule.
>
> > + u8 reserved_at_10[0x2];
> > + u8 reformat_l3_tunnel_to_l2[0x1];
> > + u8 reformat_l2_to_l3_tunnel[0x1];
> > + u8 reformat_and_modify_action[0x1];
>
> unused in downstream patches
> what is this BTW?
Bits to indicate whatever the flow table support the new packet reformat modes,
and setting reformat action with modify action in the same rule.
Those will be used once a FW which expose them is made available, but as a feature/
cap flags I would like to expose them now.
Mark
>
>
>
> > + u8 reserved_at_15[0xb];
> > u8 reserved_at_20[0x2];
> > u8 log_max_ft_size[0x6];
> > u8 log_max_modify_header_context[0x8];
> > @@ -551,7 +556,13 @@ struct mlx5_ifc_flow_table_nic_cap_bits {
> > u8 nic_rx_multi_path_tirs[0x1];
> > u8 nic_rx_multi_path_tirs_fts[0x1];
> > u8 allow_sniffer_and_nic_rx_shared_tir[0x1];
> > - u8 reserved_at_3[0x1fd];
> > + u8 reserved_at_3[0x1d];
> > + u8 encap_general_header[0x1];
> > + u8 reserved_at_21[0xa];
> > + u8 log_max_packet_reformat_context[0x5];
> > + u8 reserved_at_30[0x6];
> > + u8 max_encap_header_size[0xa];
> > + u8 reserved_at_40[0x1c0];
>
> we are inconsistent, for some fields the term "encap" remained wheres
> for other fields we moved to use "reformat" or "packet reformat" etc
^ permalink raw reply
* Re: [PATCH v2 net-next 01/14] net: Clear skb->tstamp only on the forwarding path
From: Jesus Sanchez-Palencia @ 2018-07-16 21:52 UTC (permalink / raw)
To: Eric Dumazet, netdev
Cc: tglx, jan.altenberg, vinicius.gomes, kurt.kanzenbach, henrik,
richardcochran, ilias.apalodimas, ivan.khoronzhuk, mlichvar,
willemb, jhs, xiyou.wangcong, jiri, jeffrey.t.kirsher
In-Reply-To: <1e52c128-59f4-43ae-3487-059a84ae61c3@gmail.com>
Hi Eric,
On 07/13/2018 10:35 AM, Eric Dumazet wrote:
>
>
> On 07/03/2018 03:42 PM, Jesus Sanchez-Palencia wrote:
>> This is done in preparation for the upcoming time based transmission
>> patchset. Now that skb->tstamp will be used to hold packet's txtime,
>> we must ensure that it is being cleared when traversing namespaces.
>> Also, doing that from skb_scrub_packet() before the early return would
>> break our feature when tunnels are used.
>>
>> Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
>> ---
>> net/core/skbuff.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index 1357f36c8a5e..c4e24ac27464 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -4898,7 +4898,6 @@ EXPORT_SYMBOL(skb_try_coalesce);
>> */
>> void skb_scrub_packet(struct sk_buff *skb, bool xnet)
>> {
>> - skb->tstamp = 0;
>> skb->pkt_type = PACKET_HOST;
>> skb->skb_iif = 0;
>> skb->ignore_df = 0;
>> @@ -4912,6 +4911,7 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet)
>>
>> ipvs_reset(skb);
>> skb->mark = 0;
>> + skb->tstamp = 0;
>> }
>> EXPORT_SYMBOL_GPL(skb_scrub_packet);
>>
>>
>
>
>
> I believe we had some misunderstanding here.
>
> What I meant by forwarding is the following case :
>
> - We receive a packet.
> - netstamp_wanted is >0 (because at least one packet capture is active)
> - __net_timestamp() is called and does :
> skb->tstamp = ktime_get_real();
>
> Then this skb is forwarded into an interface where EDT is taken into
> consideration by either a qdisc or a device.
>
> Since CLOCK_TAI is a different base than CLOCK_REALTIME, we might have a problem.
I'm not sure we have a problem here. For the Tx path I only see
net_timestamp_set() being called from dev_queue_xmit_nit(). And even there, it's
a clone of the skb that gets timestamped.
I believe the original skb, which had the valid txtime copied into skb->tstamp,
is not modified anywhere along that path.
What am I missing, please?
Thanks,
Jesus
>
>
> Solutions for this problem :
>
> 1) Convert all our skb->tstamp usages to CLOCK_TAI base.
>
> or
>
> 2) clear skb->tstamp in forwarding paths, including the ones not scrubbing the packet.
>
> My preference is 1), even if it is a bit more work.
>
^ permalink raw reply
* Re: [PATCH] bpf: allow BPF programs access skb_shared_info->gso_segs field
From: Alexei Starovoitov @ 2018-07-16 22:30 UTC (permalink / raw)
To: Eddie Hao; +Cc: ast, daniel, davem, netdev, linux-kernel
In-Reply-To: <20180715084524.181717-1-eddieh@google.com>
On Sun, Jul 15, 2018 at 01:45:24AM -0700, Eddie Hao wrote:
> This adds the ability to read gso_segs from a BPF program. This is useful
> for user space monitoring systems to get gso_segs statistics for each
> arbitrary group of flows defined by the BPF program.
>
> Signed-off-by: Eddie Hao <eddieh@google.com>
> ---
> include/uapi/linux/bpf.h | 1 +
> net/core/filter.c | 9 +++++++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index b7db3261c62d..282085445616 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -2266,6 +2266,7 @@ struct __sk_buff {
> /* ... here. */
>
> __u32 data_meta;
> + unsigned short gso_segs;
'short' will make it harder to extend due to struct hole.
please use __u32 instead.
> };
>
> struct bpf_tunnel_key {
> diff --git a/net/core/filter.c b/net/core/filter.c
> index b9ec916f4e3a..f17e249f3fbb 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5820,6 +5820,15 @@ static u32 bpf_convert_ctx_access(enum bpf_access_type type,
> bpf_target_off(struct sock_common,
> skc_num, 2, target_size));
> break;
> +
> + case offsetof(struct __sk_buff, gso_segs):
> + BUILD_BUG_ON(FIELD_SIZEOF(struct skb_shared_info, gso_segs) !=
> + sizeof(unsigned short));
> + off = offsetof(struct sk_buff, end);
> + off += offsetof(struct skb_shared_info, gso_segs);
did you test this patch?
Above math doesn't look correct.
NET_SKBUFF_DATA_USES_OFFSET is not handled. At least one more LDX is needed.
> + *insn++ = BPF_LDX_MEM(BPF_SIZEOF(unsigned short), si->dst_reg,
> + si->src_reg, off);
I think BUILD_BUG_ON is a bit of overkill when BPF_LDX_MEM
can use BPF_FIELD_SIZEOF(struct skb_shared_info, gso_segs) instead.
^ permalink raw reply
* Re: [PATCH v2 bpf 3/5] bpf: bpf_prog_array_free() should take a generic non-rcu pointer
From: Daniel Borkmann @ 2018-07-16 22:30 UTC (permalink / raw)
To: Roman Gushchin, netdev; +Cc: linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <20180713194114.2711-3-guro@fb.com>
On 07/13/2018 09:41 PM, Roman Gushchin wrote:
> bpf_prog_array_free() should take a generic non-rcu pointer
> as an argument, as freeing the objects assumes that we're
> holding an exclusive rights on it.
>
> rcu_access_pointer() can be used to convert a __rcu pointer to
> a generic pointer before passing it to bpf_prog_array_free(),
> if necessary.
>
> This patch eliminates the following sparse warning:
> kernel/bpf/core.c:1556:9: warning: incorrect type in argument 1 (different address spaces)
> kernel/bpf/core.c:1556:9: expected struct callback_head *head
> kernel/bpf/core.c:1556:9: got struct callback_head [noderef] <asn:4>*<noident>
>
> Fixes: 324bda9e6c5a ("bpf: multi program support for cgroup+bpf")
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> ---
> drivers/media/rc/bpf-lirc.c | 6 +++---
> include/linux/bpf.h | 2 +-
> kernel/bpf/cgroup.c | 11 ++++++-----
> kernel/bpf/core.c | 5 ++---
> kernel/trace/bpf_trace.c | 8 ++++----
> 5 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/rc/bpf-lirc.c b/drivers/media/rc/bpf-lirc.c
> index fcfab6635f9c..509b262aa0dc 100644
> --- a/drivers/media/rc/bpf-lirc.c
> +++ b/drivers/media/rc/bpf-lirc.c
> @@ -135,7 +135,7 @@ static int lirc_bpf_attach(struct rc_dev *rcdev, struct bpf_prog *prog)
> goto unlock;
>
> rcu_assign_pointer(raw->progs, new_array);
> - bpf_prog_array_free(old_array);
> + bpf_prog_array_free(rcu_access_pointer(old_array));
Taking this one as an example, why can't we already do the rcu_dereference() on the
'old_array = raw->progs' where we fetch the old_array initially? Then we also wouldn't
need the rcu_access_pointer() on bpf_prog_array_free() and yet another rcu_dereference()
inside the bpf_prog_array_copy() from your later patch?
Regarding former, rcu_access_pointer() should also only be used for testing the pointer
value, but deeper in bpf_prog_array_free() we also deref it, etc.
> unlock:
> mutex_unlock(&ir_raw_handler_lock);
> @@ -173,7 +173,7 @@ static int lirc_bpf_detach(struct rc_dev *rcdev, struct bpf_prog *prog)
> goto unlock;
>
> rcu_assign_pointer(raw->progs, new_array);
> - bpf_prog_array_free(old_array);
> + bpf_prog_array_free(rcu_access_pointer(old_array));
> unlock:
> mutex_unlock(&ir_raw_handler_lock);
> return ret;
> @@ -204,7 +204,7 @@ void lirc_bpf_free(struct rc_dev *rcdev)
> while (*progs)
> bpf_prog_put(*progs++);
>
> - bpf_prog_array_free(rcdev->raw->progs);
> + bpf_prog_array_free(rcu_access_pointer(rcdev->raw->progs));
> }
^ permalink raw reply
* Re: [PATCH 2/2] samples/bpf: test_cgrp2_sock2: fix an off by one
From: Alexei Starovoitov @ 2018-07-16 22:07 UTC (permalink / raw)
To: Dan Carpenter
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, kernel-janitors
In-Reply-To: <20180713150301.gdvfu2ejlzlnglii@kili.mountain>
On Fri, Jul 13, 2018 at 06:05:37PM +0300, Dan Carpenter wrote:
> "prog_cnt" is the number of elements which are filled out in prog_fd[]
> so the test should be >= instead of >.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
since this is sample code I've applied both patches to bpf-next tree.
Thanks
^ permalink raw reply
* [PATCH iproute2 net-next] ipneigh: exclude NTF_EXT_LEARNED from default filter
From: Roopa Prabhu @ 2018-07-16 22:19 UTC (permalink / raw)
To: dsahern; +Cc: netdev
From: Roopa Prabhu <roopa@cumulusnetworks.com>
NUD_NOARP entries are filtered out by default by iproute2.
We dont want NUD_NOARP with NTF_EXT_LEARNED flag filtered out.
This patch extends the default filter check for ip neigh show
to include the NTF_EXT_LEARNED flag.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
ip/ipneigh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ip/ipneigh.c b/ip/ipneigh.c
index bd6e5c5..a0af705 100644
--- a/ip/ipneigh.c
+++ b/ip/ipneigh.c
@@ -262,6 +262,7 @@ int print_neigh(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
return 0;
if (!(filter.state&r->ndm_state) &&
!(r->ndm_flags & NTF_PROXY) &&
+ !(r->ndm_flags & NTF_EXT_LEARNED) &&
(r->ndm_state || !(filter.state&0x100)) &&
(r->ndm_family != AF_DECnet))
return 0;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH ipsec-next] xfrm: Allow Set Mark to be Updated Using UPDSA
From: Nathan Harold @ 2018-07-16 22:27 UTC (permalink / raw)
To: Eyal Birger; +Cc: netdev
In-Reply-To: <20180703081416.04c9395f@jimi>
< re-sent with apologies due to incorrect formatting last time... :-( >
Hi Eyal,
> If x1 points to a state previously found using __xfrm_state_locate(x),
> won't __xfrm_state_bump_genids(x1) be equivalent to x1->genid++ in
> this case?
In the vanilla case this is true. IE, if there are no strange/abusive
uses of the API such as the test below where multiple SAs can match
the locate().
> Is it possible that other states will match all of x1 parameters?
Yes. Not sure if it's a bug or a feature, but it's possible for
multiple SAs to match... for a depressing example, check out
https://android-review.googlesource.com/c/kernel/tests/+/680958. There
may be cases where something like this is desired behavior that I'm
not aware of. Since this is control path, it felt to me like the
formalism of using the xfrm_state_bump_genids() was worth not possibly
walking into a different subtle bug later.
> Also, any idea why this isn't needed for other changes in the state?
The set_mark (output_mark) is somewhat special because changing this
mark impacts the routing lookup, which up to now, none of the other
parameters in the update_sa function do. A new output_mark can and
will reroute packets to different interfaces. Thus, when we change
this thing, we want to ensure that we always build a new bundle with a
new bundle with a new route lookup based on the new set_mark. Since we
removed the flow cache, things might *incidentally* seem to work right
now; but, I think that's incidental rather than correct. By bumping
the genid, we get the dst_entry->check() function to correctly return
that the dst is obsolete when we call check(). I'm honestly not sure
what corner cases we could land in if we didn't bump the genid in such
a case.
There's definitely a lot going on behind the scenes in this little
change that I only tenuously grasp, so it's possible that I'm being
overly cautious in this case. Please let me know your further thoughts
on whether we need to bump the genid. FYI once this patch is settled,
I plan to upload a patch to update the xfrm_if_id, which I planned to
nestle in to this same logic (and with similar, albeit possibly
more-straightforward rationale).
-Nathan
On Mon, Jul 2, 2018 at 10:14 PM, Eyal Birger <eyal.birger@gmail.com> wrote:
> Hi Nathan,
>
> On Fri, 29 Jun 2018 15:07:10 -0700
> Nathan Harold <nharold@google.com> wrote:
>
>> Allow UPDSA to change "set mark" to permit
>> policy separation of packet routing decisions from
>> SA keying in systems that use mark-based routing.
>>
>> The set mark, used as a routing and firewall mark
>> for outbound packets, is made update-able which
>> allows routing decisions to be handled independently
>> of keying/SA creation. To maintain consistency with
>> other optional attributes, the set mark is only
>> updated if sent with a non-zero value.
>>
>> The per-SA lock and the xfrm_state_lock are taken in
>> that order to avoid a deadlock with
>> xfrm_timer_handler(), which also takes the locks in
>> that order.
>>
>> Signed-off-by: Nathan Harold <nharold@google.com>
>> Change-Id: Ia05c6733a94c1901cd1e54eb7c7e237704678d71
>> ---
>> net/xfrm/xfrm_state.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
>> index e04a510ec992..c9ffcdfa89f6 100644
>> --- a/net/xfrm/xfrm_state.c
>> +++ b/net/xfrm/xfrm_state.c
>> @@ -1562,6 +1562,15 @@ int xfrm_state_update(struct xfrm_state *x)
>> if (x1->curlft.use_time)
>> xfrm_state_check_expire(x1);
>>
>> + if (x->props.smark.m || x->props.smark.v) {
>> + spin_lock_bh(&net->xfrm.xfrm_state_lock);
>> +
>> + x1->props.smark = x->props.smark;
>> +
>> + __xfrm_state_bump_genids(x1);
>
> So I'm trying to wrap my head around this genid thing :)
>
> If x1 points to a state previously found using __xfrm_state_locate(x),
> won't __xfrm_state_bump_genids(x1) be equivalent to x1->genid++ in
> this case?
>
> Is it possible that other states will match all of x1 parameters?
>
> Also, any idea why this isn't needed for other changes in the state?
>
> Thanks!
> Eyal.
^ permalink raw reply
* Re: [PATCH v2 bpf 3/5] bpf: bpf_prog_array_free() should take a generic non-rcu pointer
From: Roman Gushchin @ 2018-07-16 22:57 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <41b5f919-3155-5bd4-2774-84efd58650e2@iogearbox.net>
On Tue, Jul 17, 2018 at 12:30:18AM +0200, Daniel Borkmann wrote:
> On 07/13/2018 09:41 PM, Roman Gushchin wrote:
> > bpf_prog_array_free() should take a generic non-rcu pointer
> > as an argument, as freeing the objects assumes that we're
> > holding an exclusive rights on it.
> >
> > rcu_access_pointer() can be used to convert a __rcu pointer to
> > a generic pointer before passing it to bpf_prog_array_free(),
> > if necessary.
> >
> > This patch eliminates the following sparse warning:
> > kernel/bpf/core.c:1556:9: warning: incorrect type in argument 1 (different address spaces)
> > kernel/bpf/core.c:1556:9: expected struct callback_head *head
> > kernel/bpf/core.c:1556:9: got struct callback_head [noderef] <asn:4>*<noident>
> >
> > Fixes: 324bda9e6c5a ("bpf: multi program support for cgroup+bpf")
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > ---
> > drivers/media/rc/bpf-lirc.c | 6 +++---
> > include/linux/bpf.h | 2 +-
> > kernel/bpf/cgroup.c | 11 ++++++-----
> > kernel/bpf/core.c | 5 ++---
> > kernel/trace/bpf_trace.c | 8 ++++----
> > 5 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/media/rc/bpf-lirc.c b/drivers/media/rc/bpf-lirc.c
> > index fcfab6635f9c..509b262aa0dc 100644
> > --- a/drivers/media/rc/bpf-lirc.c
> > +++ b/drivers/media/rc/bpf-lirc.c
> > @@ -135,7 +135,7 @@ static int lirc_bpf_attach(struct rc_dev *rcdev, struct bpf_prog *prog)
> > goto unlock;
> >
> > rcu_assign_pointer(raw->progs, new_array);
> > - bpf_prog_array_free(old_array);
> > + bpf_prog_array_free(rcu_access_pointer(old_array));
>
> Taking this one as an example, why can't we already do the rcu_dereference() on the
> 'old_array = raw->progs' where we fetch the old_array initially? Then we also wouldn't
> need the rcu_access_pointer() on bpf_prog_array_free() and yet another rcu_dereference()
> inside the bpf_prog_array_copy() from your later patch?
We can, but then we have to change bpf_prog_array_copy() args annotation,
and also all places, where it's called.
IMO, basically all local variables and function args marked as __rcu
should be not marked as RCU, but fixing them all is beyond this patchset.
>
> Regarding former, rcu_access_pointer() should also only be used for testing the pointer
> value, but deeper in bpf_prog_array_free() we also deref it, etc.
Hm, but at this moment it's a not "real" rcu pointer.
We're sure that we're owning this pointer.
Btw, we probably have to use rcu_swap_protected() in this place.
Thanks!
^ permalink raw reply
* [PATCH] net: usb: rtl8150: demote allmulti message to dev_dbg()
From: David Lechner @ 2018-07-16 22:58 UTC (permalink / raw)
To: Petko Manolov
Cc: David Lechner, David S. Miller, linux-usb, netdev, linux-kernel
This driver can spam the kernel log with multiple messages of:
net eth0: eth0: allmulti set
Usually 4 or 8 at a time (probably because of using ConnMan).
This message doesn't seem useful, so let's demote it from dev_info()
to dev_dbg().
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/net/usb/rtl8150.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 0e81d4c441d9..80373a9171dd 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -682,7 +682,7 @@ static void rtl8150_set_multicast(struct net_device *netdev)
(netdev->flags & IFF_ALLMULTI)) {
rx_creg &= 0xfffe;
rx_creg |= 0x0002;
- dev_info(&netdev->dev, "%s: allmulti set\n", netdev->name);
+ dev_dbg(&netdev->dev, "%s: allmulti set\n", netdev->name);
} else {
/* ~RX_MULTICAST, ~RX_PROMISCUOUS */
rx_creg &= 0x00fc;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs
From: Andrew Lunn @ 2018-07-16 22:31 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
openwrt-devel, LEDE Development List, Antti Seppälä,
Roman Yeryomin, Colin Leitner, Gabor Juhos, devicetree
In-Reply-To: <20180716204535.GA22125@rob-hp-laptop>
> > +Realtek SMI-based Switches
> > +==========================
> > +
> > +The SMI "Simple Management Interface" is a two-wire protocol using
>
> At least for some other Realtek chips, the documentation I find says the
> S stands for Serial. And Wikipedia says SMI is the same thing as MDIO.
>
> Just want to make sure we don't define GPIOs directly when there should
> be a layer of abstraction like mdio-gpio.
Hi Rob
There was a bit of discussion about this with the RFC patches. The bit
stream protocol used here is not that used by SMI in MDIO. It is
something proprietary to Realtek. I don't expect we will be re-using
the code with other vendors. The only real reason to abstract this out
is if there happens to be other Realtek switches which uses the same
SMI bitstream, but have completely different registers, meaning a
separate DSA driver would be needed. The SMI code is well structured,
so it should not be too hard to turn it into a library which drivers
can share.
So i personally don't see a problem with this.
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next 0/2] tools: bpf: build cleanups
From: Daniel Borkmann @ 2018-07-16 22:34 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: oss-drivers, netdev
In-Reply-To: <20180716175716.6475-1-jakub.kicinski@netronome.com>
On 07/16/2018 07:57 PM, Jakub Kicinski wrote:
> Hi!
>
> While tracking down the perf vs libbpf vs reallocarray build issue
> I noticed libbpf is checking for a feature it never uses and that
> bpftool's makefile attempt to reuse feature dump doesn't really
> make sense.
>
> Jakub Kicinski (2):
> tools: libbpf: remove libelf-getphdrnum feature detection
> tools: bpftool: don't pass FEATURES_DUMP to libbpf
>
> tools/bpf/bpftool/Makefile | 2 +-
> tools/lib/bpf/Makefile | 6 +-----
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Proposal
From: Miss Victoria Mehmet @ 2018-07-16 22:34 UTC (permalink / raw)
To: Recipients
Hello
I have a business proposal of mutual benefits i would like to discuss with you,i asked before and i still await your positive response thanks.
^ permalink raw reply
* Re: [net-next, 3/3] tcp: convert icsk_user_timeout from jiffies to msecs
From: Jonathan Maxwell @ 2018-07-16 23:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Eric Dumazet, Neal Cardwell, David Laight, kuznet,
yoshfuji, Netdev, LKML, Jon Maxwell
In-Reply-To: <9a96cc7d-e7bd-5be2-9ce4-e74918773560@gmail.com>
Sorry Eric, my bad. I'll do another version with the indentation fixed and
reformatting of min_t() and resubmit.
On Tue, Jul 17, 2018 at 2:00 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 07/12/2018 05:49 PM, Jon Maxwell wrote:
>> The final patch in this series. Create the tcp_clamp_rto_to_user_timeout()
>> helper routine. To calculate the correct rto, so that the TCP_USER_TIMEOUT
>> socket option is more accurate. Taking suggestions and feedback into account
>> from Eric Dumazet, Neal Cardwell and David Laight. Due to the 1st commit we
>> can avoid the msecs_to_jiffies() and jiffies_to_msecs() dance.
>>
>> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
>> ---
>> net/ipv4/tcp_timer.c | 19 ++++++++++++++++++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
>> index 8ab8c9645294..d4d4b30a6bec 100644
>> --- a/net/ipv4/tcp_timer.c
>> +++ b/net/ipv4/tcp_timer.c
>> @@ -36,6 +36,22 @@ u32 tcp_retransmit_stamp(const struct sock *sk)
>> return start_ts;
>> }
>>
>> +static u32 tcp_clamp_rto_to_user_timeout(const struct sock *sk)
>> +{
>> + struct inet_connection_sock *icsk = inet_csk(sk);
>> + u32 elapsed, start_ts;
>> +
>> + start_ts = tcp_retransmit_stamp(sk);
>> + if (!icsk->icsk_user_timeout || !start_ts)
>> + return icsk->icsk_rto;
>> + elapsed = tcp_time_stamp(tcp_sk(sk)) - start_ts;
>> + if (elapsed >= icsk->icsk_user_timeout)
>> + return 1; /* user timeout has passed; fire ASAP */
>> + else
>> + return min_t(u32, icsk->icsk_rto, msecs_to_jiffies(icsk->icsk_user_timeout -
>> + elapsed));
>
> if (elapsed >= icsk->icsk_user_timeout)
> return 1; /* user timeout has passed; fire ASAP */
>
> return min_t(u32, icsk->icsk_rto, msecs_to_jiffies(icsk->icsk_user_timeout - elapsed));
>
> Thanks !
^ permalink raw reply
* Re: [PATCH v2 net-next 01/14] net: Clear skb->tstamp only on the forwarding path
From: Eric Dumazet @ 2018-07-16 23:15 UTC (permalink / raw)
To: Jesus Sanchez-Palencia, Eric Dumazet, netdev
Cc: tglx, jan.altenberg, vinicius.gomes, kurt.kanzenbach, henrik,
richardcochran, ilias.apalodimas, ivan.khoronzhuk, mlichvar,
willemb, jhs, xiyou.wangcong, jiri, jeffrey.t.kirsher
In-Reply-To: <aab83276-c58b-4cfe-d44d-5271cd5163a6@intel.com>
On 07/16/2018 02:52 PM, Jesus Sanchez-Palencia wrote:
> Hi Eric,
>
>
>
> On 07/13/2018 10:35 AM, Eric Dumazet wrote:
>>
>>
>> On 07/03/2018 03:42 PM, Jesus Sanchez-Palencia wrote:
>>> This is done in preparation for the upcoming time based transmission
>>> patchset. Now that skb->tstamp will be used to hold packet's txtime,
>>> we must ensure that it is being cleared when traversing namespaces.
>>> Also, doing that from skb_scrub_packet() before the early return would
>>> break our feature when tunnels are used.
>>>
>>> Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
>>> ---
>>> net/core/skbuff.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>>> index 1357f36c8a5e..c4e24ac27464 100644
>>> --- a/net/core/skbuff.c
>>> +++ b/net/core/skbuff.c
>>> @@ -4898,7 +4898,6 @@ EXPORT_SYMBOL(skb_try_coalesce);
>>> */
>>> void skb_scrub_packet(struct sk_buff *skb, bool xnet)
>>> {
>>> - skb->tstamp = 0;
>>> skb->pkt_type = PACKET_HOST;
>>> skb->skb_iif = 0;
>>> skb->ignore_df = 0;
>>> @@ -4912,6 +4911,7 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet)
>>>
>>> ipvs_reset(skb);
>>> skb->mark = 0;
>>> + skb->tstamp = 0;
>>> }
>>> EXPORT_SYMBOL_GPL(skb_scrub_packet);
>>>
>>>
>>
>>
>>
>> I believe we had some misunderstanding here.
>>
>> What I meant by forwarding is the following case :
>>
>> - We receive a packet.
>> - netstamp_wanted is >0 (because at least one packet capture is active)
>> - __net_timestamp() is called and does :
>> skb->tstamp = ktime_get_real();
>>
>> Then this skb is forwarded into an interface where EDT is taken into
>> consideration by either a qdisc or a device.
>>
>> Since CLOCK_TAI is a different base than CLOCK_REALTIME, we might have a problem.
>
>
> I'm not sure we have a problem here. For the Tx path I only see
> net_timestamp_set() being called from dev_queue_xmit_nit(). And even there, it's
> a clone of the skb that gets timestamped.
>
> I believe the original skb, which had the valid txtime copied into skb->tstamp,
> is not modified anywhere along that path.
>
> What am I missing, please?
>
> Thanks,
> Jesus
>
I am simply stating that a linux router, receiving packet on ethX and forwarding
them on ethY, could have a problem if ethY has a qdisc looking at skb->tstamp
assuming a timestamp in CLOCK_TAI base.
In this case, skb->tstamp would have been set at ingress (not using CLOCK_TAI
but CLOCK_REALTIME), and would be read at egress (assuming CLOCK_TAI)
Normal IPV4 routing path would be in net/ipv4/ip_forward.c, no scrubbing ever happens,
and no cloning either.
Your patch (Clear skb->tstamp only on the forwarding path) is not handling the
typical forward path, only the cases where 'scrubbing' is used.
>
>
>>
>>
>> Solutions for this problem :
>>
>> 1) Convert all our skb->tstamp usages to CLOCK_TAI base.
>>
>> or
>>
>> 2) clear skb->tstamp in forwarding paths, including the ones not scrubbing the packet.
>>
>> My preference is 1), even if it is a bit more work.
>>
^ permalink raw reply
* Re: [PATCH next] bonding: pass link-local packets to bonding master also.
From: Stephen Hemminger @ 2018-07-16 23:33 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Jay Vosburgh, Andy Gospodarek, Veaceslav Falico, David Miller,
Netdev, Michal Soltys, Mahesh Bandewar
In-Reply-To: <20180716011246.225647-1-mahesh@bandewar.net>
On Sun, 15 Jul 2018 18:12:46 -0700
Mahesh Bandewar <mahesh@bandewar.net> wrote:
> From: Mahesh Bandewar <maheshb@google.com>
>
> Commit b89f04c61efe ("bonding: deliver link-local packets with
> skb->dev set to link that packets arrived on") changed the behavior
> of how link-local-multicast packets are processed. The change in
> the behavior broke some legacy use cases where these packets are
> expected to arrive on bonding master device also.
>
> This patch passes the packet to the stack with the link it arrived
> on as well as passes to the bonding-master device to preserve the
> legacy use case.
>
> Reported-by: Michal Soltys <soltys@ziu.info>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Thanks for fixing this.
Why not add a Fixes: tag instead of just talking about the commit?
That helps the stable maintainers know which versions of the kernel
need the patch.
^ permalink raw reply
* Re: [PATCH bpf-next 0/2] tools: bpf: build cleanups
From: Alexei Starovoitov @ 2018-07-16 23:39 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Jakub Kicinski, oss-drivers, netdev
In-Reply-To: <323b0000-56eb-617b-4755-d1d8a8e84116@iogearbox.net>
On Tue, Jul 17, 2018 at 12:34:03AM +0200, Daniel Borkmann wrote:
> On 07/16/2018 07:57 PM, Jakub Kicinski wrote:
> > Hi!
> >
> > While tracking down the perf vs libbpf vs reallocarray build issue
> > I noticed libbpf is checking for a feature it never uses and that
> > bpftool's makefile attempt to reuse feature dump doesn't really
> > make sense.
> >
> > Jakub Kicinski (2):
> > tools: libbpf: remove libelf-getphdrnum feature detection
> > tools: bpftool: don't pass FEATURES_DUMP to libbpf
> >
> > tools/bpf/bpftool/Makefile | 2 +-
> > tools/lib/bpf/Makefile | 6 +-----
> > 2 files changed, 2 insertions(+), 6 deletions(-)
> >
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
somehow cover letter didn't make it into patchworks,
so I applied both patches manually to bpf-next and propagated Daniel's Ack.
Thanks!
^ 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